Last week I stumbled across an interesting article on the web that helps us answer the question as to why IT projects fail. Citing long-standing research performed by the Standish Group, the article provides a list of reasons given during a survey of some 365 different organizations. These are listed in the table below:

What is Organizational Culture anyway?

A little while back, a coworker asked if I could write up a brief description of Sagitec’s organizational culture to help some new-hires get oriented to the company. Sure, I said, I’d be glad to. Just one problem: how do we define our culture?

Today’s pace of technological advancement is fast. Scary fast. For the IT professional driving the technological equivalent of a Ford Pinto, every road is an entrance to the freeway and one look in the mirror is enough to send shivers down the spine. Obsolescence has a lead foot. It's got the pedal to the metal (so to speak) and it's bearing down on your legacy system like a Mack truck with the high beams on.

Earlier this year, in an article for Digital Software Magazine called Building Corporate IT Systems That Remain Relevant, Bruce Ballengee of Pariveda Solutions makes a strong case for agile software development as a means to foster perpetual value (i.e., strong ROI) in an IT system. We couldn’t agree more with Mr. Ballengee’s conclusions. But there are several other important benefits of an agile (or iterative/incremental) methodology that are worth mentioning and which potential customers should be aware of.

When it comes to major IT initiatives like pension system replacement projects, creating a comprehensive change management plan that involves non-IT executives is usually not at the top of the priorities list.  But as a recent tip from Harvard Business Review notes, the cause of failed IT initiatives more often than not exists outside of IT: 

Don’t Fence Them In! Write Functional Requirements that won’t Sabotage your IT Vendor’s Ability to Deliver an innovative Pension Administration Solution

Following up a previous article on creating great functional requirements for your RFP, this post further examines what a functional requirement is and—just as important—what it isn’t. Understanding this key distinction can make all the difference when you’re trying to compose an RFP that accurately identifies your unique business requirements but which doesn’t compromise the IT vendor’s ability to deliver an innovative pension administration system that truly empowers your organization.

Anyone who has had the responsibility of writing or reading an RFP for a pension administration system replacement project understands the importance of clearly written requirements. For the writer, the challenge is to commit to paper hundreds—if not thousands—of requirements from across the organization. For the it vendor, the challenge comes from understanding these requirements with little contextual information about the prospective client or their pension system. Because the RFP is often the only legal means customers and vendors have for relating to, and partnering with, each other early in the procurement process, clear, purposeful requirements are absolutely critical to both parties.  

Replacing pension administration systems in the public sector differs in a number of ways from private sector projects.  These differences are important to keep in mind both when embarking on a systems replacement project and when selecting a pension system replacement vendor.