The metrics organizations commonly use to determine whether an IT project is a success or a failure—whether the project is completed on time, on budget, and delivered the initial requirements—do more harm than good for IT departments, according to a new report from Forrester Research.
MORE ON PROJECT MANAGEMENT
Organizations use these metrics because they're easy for business people to understand, writes principal author Lewis Cardin in the report, Debunking IT Project Failure Myths. But these metrics are problematic for IT departments. In a way, Cardin suggests, they set up IT departments for failure.
For more information on project management, see Three Keys to Getting Your Projects Under Control.
The problem with these metrics, according to Forrester, is that they perpetuate the idea that a project is only successful when it is completed according to the initial schedule, budget and requirements—and therefore, that anything less is a failure.
Another problem with these metrics is that they don't take into account the mercurial nature of project management and project delivery.
"Project requirements change for a variety of reasons, and schedules and budgets change during the lifetime of the project based on better information as to effort, complexity and interdependencies," writes Cardin in the report, published July 28. "This would not be an issue except that project sponsors judge project success in terms of schedule-budget-meet requirements."
In other words, project sponsors latch on to the initial estimates project managers propose for the schedule and cost of a project. And because project sponsors don't understand project complexity and other factors influencing cost and timeline when requirements change, they may see the project as a failure if costs increased, even if the changes improved the value delivered to the business. Unfortunately, business executives' lack of understanding about project management influences their perception of IT project success and failure.
For a list of project management pitfalls to avoid, see The 14 Most Common Project Management Mistakes IT Departments Make.
Finally, the cost-schedule-requirements metrics don't reflect the fundamental issues that cause projects to fail, such as unresponsive project governance, unrealistic project plans and business executives' very limited understanding of project management.
As problematic as these metrics are for IT departments, Cardin doesn't suggest changing them. Instead, he recommends that project management offices (PMOs) play a more active role in managing project sponsors' and business stakeholders' perceptions of project success and failure. Here are four measures Forrester advises PMOs to take.
4 Ways PMOs Can Improve the Perception of IT Project Success
1. They can keep project steering committees on task.
Cardin notes that projects often stall when the steering committee providing governance for the project fails to make decisions or solve problems. "The PMO is better positioned than the individual project manager to keep project decisions and the necessity of these decisions visible to business and IT management," he writes.
2. They can improve communication with project sponsors about changes in requirements and the impact of those changes on the budget and timeline.
This will prevent project sponsors from viewing projects as failures when project requirements changed and resulted in higher costs.
3. They can improve the reliability of project plans.
Cardin recommends that PMOs establish best practices for developing plans for projects that involve "significant unknowns." Such established best practices help the PMO set business sponsors' expectations for reasonable project performance and reasonable actions for a project manager to take under different conditions.
4. They can better communicate estimates of cost, schedule and resources.
PMOs need to more clearly articulate to project sponsors how they come up with estimates for a project's cost, schedule and the resources it will require, how those estimates are based on certain business conditions, and how changes to those business conditions can impact the cost of and timeline for the project.