IT justice: Weighing the scales of failure
This post was written by guest blogger, Steve Romero, IT Governance Evangelist with CA. Steve emphasizes the importance of ending projects to prevent full-blown failures. He blogs on IT governance issues.
A recent ISACA (Information Systems Audit and Control Association) survey found 43 percent of respondents have killed in-process IT projects. This encouraging news suggests a surprising number of organizations have successfully faced the impartial scales of IT justice.
Terminating IT projects prematurely can be a difficult and emotionally charged subject. In discussing project portfolio management (PPM), I often ask audiences, “Does your team meet regularly to identify projects that should be killed?” As you might expect, the answer is usually "no."
- See also: 7 tips to safely kill zombie projects
Nonetheless, under-performing projects represent a significant waste of time and resources:
"Unfortunately, many under-performing IT-related projects continue on longer than they should because management does not constantly assess projects and ensure they generate appropriate value and benefits," said Marios Damianides, CISM, CISA, CPA, CA, a past international president of ISACA and the IT Governance Institute. "Business requirements change rapidly. It is a good management practice and a sign of appropriate governance to evaluate and take action on under-performing IT projects as they progress, rather than suffer the financial and reputational consequences further down the road."
Organizations should terminate ongoing projects meeting any of three conditions:
- Flawed approvals. Sometimes it becomes clear the original decision process ignored important issues when approving the project. In such cases, the approval decision was likely wrong and the project should be killed.
- Changing needs. Some lengthy projects outlive the basic business justification on which they were originally established. Although the approval decision may have been sound, changing business requirements make these projects obsolete before completion. When an organization can’t adjust the project to align with new requirements, the project should be killed.
- Poor execution. Some projects become screwed up beyond repaid despite being based on sound business logic. These projects represent classic IT failure and should be killed.
Defining failure. I consider projects failures when they take longer than scheduled, cost more than budgeted, or do not deliver promised value. The Butler Group completed a study finding that 50 percent of IT projects fail, an extraordinarily high number!
There are many reasons for this high failure rate:
- Poor time and cost estimates
- Not enough time to plan
- High project complexity, size, or length
- Ambiguous customer requirements
- Poor internal requirements process
- Insufficient resources
- Production emergencies adversely affected project progress
- Insufficient executive sponsorship
- Scope creep (see kitchen sink syndrome)
Even though failing projects waste resources and reduce team morale, many organizations find it challenging to pull the plug. To identify “failing” projects before they become “failed” projects, consider the following questions:
- Is the project performing below expectations?
- Is the project still aligned to business objectives?
From a governance perspective, killing failures is a critical requirement for successful IT.
[Thanks to Joan Levy from Blanc & Otus for arranging this guest post. Image via gleesonlaw.com]