Site icon IT World Canada

The problem with metrics

ARE PROJECT METRICS REALLY THE GOOD THING THEY’RE CRACKED UP TO BE? Not according to a new report from Forrester Research entitled Debunking IT Project Failure Myths. It says that the metrics which 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.

Organizations use these metrics because they’re easy for business people to understand, according to Lewis Cardin, the report’s principal author. But these metrics are problematic for IT departments. In a way, Cardin suggests, they set up IT departments for failure.

The problem with these metrics, Forrester noted, 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, 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,” asserted Cardin. “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.

As problematic as these metrics are for IT departments, Cardin doesn’t advocate changing them. Instead, he recommends that project management offices play a more active role in managing the perceptions of project success and failure with respect to sponsors and business stakeholders.

Exit mobile version