CIO New Zealand
By Hemant Kogekar
05 December, 2013 11:46
You have probably read about the Queensland Department of Health payroll project, which ended in debacle with costs estimated at $1.2 billion. In the US, the Expeditionary Combat Support System project was cancelled after the US Air Force spent $1bn on its development.
The sad fact is these failures are not isolated instances; they’re just the most visible. Based on industry norms, less than 50 per cent of IT projects finish on time and on budget.
Discussions with experienced CIOs, consultants and project managers indicate there are many reasons for the failure of IT projects. If you step back from the individual causes, common themes emerge. A few are obvious; others are not well recognised.
Fuzzy goals: Many large projects fail because what they are trying to achieve isn’t made clear enough. There is no clear problem definition or clarity about the requirements, and the full scope of the project is not understood. One executive has an objective, but as the project moves forward new people, such as other executives, risk managers, and architects are introduced, adding their ideas of what would be best. The net result is unclear goals, expanding project scope and poor project design, all of which lead to unending debates and sliding timelines.
Over-optimism: Salespeople and internal project champions both want their proposal to succeed. However, in their desire to make the ‘sell’, they often underestimate the costs and over-emphasise the benef its. While preparing business cases, there is a tendency to maximise benefits and reduce costs to achieve the right return on investment (ROI). At times, this under-estimation is not intentional, but a result of the CIO having a poor understanding of the current situation and requirements. The CIO does not consider, or budget for, the effort to move from installing a system to actually achieving the benefits (new products, customers, capability).
Over-optimism results in unrealistic schedules. There is often an unjustified faith in technology (product, vendor or internal capability). Solution complexity is not evaluated either.
Complexity: Major IT projects have a high degree of complexity due to new technology, the myriad interfaces with other systems, data conversion, or because project teams have to compete for resources with other projects. Legacy processes also have to be replicated or supported in the new system, which adds to the complexity.
What project managers (PMs) and executives do not understand is that the project risks and effort involved increase exponentially as complexity increases. Systems and processes become brittle as people try to cater for this complexity in a tight timeframe and with workarounds. The complexity eventually overwhelms the PMs, and the projects go out of control.
Weak ‘ownership’: Large projects often have multiple executives, each with slight ly dif ferent agendas as stakeholders. The executives have different expectations of the project’s benefits and options, which are at times incompatible. None of the executives fully support the project, and many projects lack an effective sponsor accountable for the project goals and benefits and who can arbitrate conflicting demands.
Weak sponsorship also indicates poor accountability across the project. When dates slip, tasks are not completed or roadblocks emerge, and no one is held accountable, which results in the project becoming unmanageable. Weak ownership often results in poor project control resulting in an increased chance of the project failing.
Governance: People accept that lack of governance is a major reason for the failure of a project. However, most large projects have the exact opposite problem; there is too much bureaucracy. In one IT project example I’ve seen, 80 per cent of budgeted costs were non-productive costs or red tape. In another organisation, a three-day change request needed justification papers and the approval of the executive steering committee, which cost more than 10 days of effort.
In large organisations, stakeholders such as risk managers, compliance staff, methodology experts and architects all have their own governance demands, which greatly increase the demands on project staff.
Over-engineered thinking
More recently, project management has succumbed to the modern fetish for valuing form over substance. Below is a quote from a CIO regarding this over engineering:
“In the past, we spent time working out how to solve a problem. We explored different avenues of approach, different ways of meeting a target. We focused on the customer’s needs and expectations. We focused on what was to be delivered.
“Nowadays, it seems that the focus is more on planning how you are to do it, coupled with a determination to adopt methodologies and standards. The result is that we spend more time planning the methodology and approach to the project rather than working on the technical requirements of the solution and how we can deliver it. The body of documentation has greatly increased. Now we have the plan, plus risk analyses, process f lows, summary timelines, and all sorts of forms showing who did what, with and to whom and when.
“That gives rise to a much greater number of formally documented meetings, implying a new breed of project administrators who manage the documentation and schedule the meetings, adding to the project overhead, both in time and cost. A second consequence is that the poor people at the coal face have, in addition to actually doing the work, a welter of forms to complete.”
The management factor
The major success factor for projects – large or small – is the PM. Having certification as a PM is one thing, but having the ability and know-how is another. The PM has to understand how to balance the needs of the project with the needs of good governance. The PM has to use the right methodology, apply it at the right time and in the amounts that are really needed.
A PM must also have knowledge of the subject matter. The notion that a qualified PM can manage any sort and size of project is twaddle.
The other thing to point out is that projects never go from being well managed, on-budget and on-schedule to outright failure overnight. There is always a transition period during which time the project is ‘troubled’.
If you can cut through the noise to see the real issues, you have a window of opportunity in which the project can potentially be rescued. Since people involved in a project generally want it to succeed, they unintentionally start ignoring or dismissing the warning signs. Using external reviewers to detect these early signs and help the sponsor take decisive action can often help rescue a troubled project.
Think big, act small
Large IT projects fail for a variety of reasons, and while there are a host of ways to mitigate these failures, one last fact is worth mentioning here.
The Standish Group research indicates smaller projects (whether based on Agile or Waterfall methods) have a much higher success rate (76 per cent) than larger projects (10 per cent). Many industry pundits agree delivering product in small doses produces positive results.
You can think big, but you need to act small by making every big project a group of small projects.