Part 3 – Real Causes
In this third part of our series on why public sector IT projects fail we’re going to discuss the real reasons we believe public sector IT projects fail.
Information technology projects encounter serious problems not as a result of deficiencies in technology, support, methodology or technology staff (note: these problems do occur but they are typically quickly identified and remedied by competent project teams). Looking at IT projects that ran into serious problems (failure, long delays, significant cost overruns), they almost always include most or all of the following:
Users drive development
Ask a user what he or she wants in a system and the response will invariably be some version of: “Everything.” In public sector IT project, users don’t pay for the system. They don’t see that every feature and function they request adds cost, time (reflected in the schedule), and complexity to the system. Because they have no way to associate scope (features and functionality) with cost, they ask for everything. Users when asked will tend to include everything they’ve ever wanted.
Initial and continuing estimates of cost and size are inaccurate
Systems often start with inaccurate estimates of size, which translate into inaccurate budget, return on investment (ROI), and schedule estimates. Once reality strikes, in the form of increased estimates of size and work, budgets and schedules have to be revised, and the project is “late and over budget, again!” Return on investment goes out the window (“we’re too far along to stop now!”). However, even revisions to initial estimates are often skewed by expediency (“senior management won’t accept a 6 month delay, we’ll do it in 3!”) and place the project right back in the same boat it started in: with no real idea of cost, ROI, or timelines.
Measurements used provide the illusion of control
An IT project generates an enormous amounts of data from staff time cards, hours per task, hours of work completed, percent of work completed and so on. This data is transformed to project metrics that provide a tremendous “feel good” factor (“we are 80% complete on the task”). However it is of little value if you can’t use it to predict what’s coming for the project (“the remaining 20% will take as much time to complete as the first 80% did”). Most measurements are worse than no measurement because they tend to placate individuals who don’t know better (“Wow – we’re 80% done – that’s great!”).
Reporting focuses on completed work, not remaining work
Related to the above, projects often focus on what’s been done, and find amazingly accurate ways to measure completed work. What is done is in the past doesn’t give you a very good idea of what the future looks like. Data about how far you’ve come is a bit like driving a car by looking in the rear-view mirror; “We haven’t hit anything so far, so we’re okay.”
Scope is not really managed
The scope of an IT project will change. The business of the organization can change, parameters of the project might change (e.g. funding), and on nearly every systems project the further we get into it the more we learn about the problem we are trying to solve. Early estimates may have over or under-stated (typically under-stated) the real effort required to design, develop, test and implement the system. However, typically only the largest scope changes are acknowledged and accounted for on the schedule. The little things add up.
Historic information is used to place blame and avoid responsibility
Historic information unfortunately serves one predominant purpose on too many projects: providing the facts needed to place blame when things go wrong. Failing projects abound with sponsors, staff, vendors, managers and users pointing the finger at each other and producing reams of reports showing that it’s not their fault. The project took twice as long and cost twice as much as planned, doesn’t fully do what we need, and the users hate it. But it wasn’t our fault!
The decision making culture is inappropriate
In anything but the smallest project (one or two staff members) decision-making by micro-management or consensus won’t work. Project managers can’t make all the decisions for all the staff; he or she hasn’t the time, skills, or the needed information. At the same time, consensus management won’t work, either; soon everyone spends all of his or her time in meetings trying to reach consensus. Decisions have to be made by the people with the necessary information, and the responsibility to make them.
Staff work hard, but not necessarily on the right things
IT projects don’t have staff members sitting around with their feet on their desks, working crossword puzzles. Generally, staff members work hard on their projects. However, we regularly find staff are working hard on things that don’t matter much. Staff have been focused on things that don’t keep the project moving forward. This is not a problem with the staff but rather with project management.
Next we’ll examine some of the “symptoms” that show up on projects that have these problems.
This is the third in a multi-part series of posts analyzing the causes of failures in public sector IT projects and proposing some pragmatic solutions
Part 1 – Overview
Part 2 – Apparent Causes
The graph shows most of the effort in large system development goes into removing defects. Defects can occur in the feasibility, requirements, analysis, design, and coding phases of a project. The sooner a defect is detected in the development life cycle the less expensive it is to correct. So, defects detected in requirements are relatively inexpensive to correct whereas a defect in code is significantly more expensive to correct. Once a system is in operation defects are very expensive to correct. Think about it: not only do you have to fix the code but potentially you fix documentation, retrain users, etc.
The graph points out some interesting things: