Features

As companies become wiser about recognizing and adopting successful project management approaches, they face the challenge of creating an environment that fosters success — but that means first defining what success means to the organization

If the project manager says a project will take a year, and it takes two instead, should we see that as a project management failure? If a project was supposed to cost $2 million, and ends up costing $4 million, is the project a dead duck?

These might sound as ethereal as other philosophical conundrums like whether a tree falling in a deserted forest still makes a sound, or the number of angels that can dance on the head of a pin.

However, Cutter Consortium Fellow and project management guru Tom DeMarco believes it is time many organizations rethought their definitions of project success to acknowledge that plenty of so-called "failed" projects have led to development of successful products. And anyway, he asks, when we talk about a project failing when it cost more than somebody said it would cost, or takes twice as long, how can we be sure those estimates were anywhere near the right ball park in the first place?

"If I say this project will be done in a year and you run the project and it takes two years, is that a failed project?" he asks. "I think you could argue very reasonably that it was just as likely to have been a failed estimate: I set out to tell when I wanted it done, not set a goal for you. In addition, the projects that fail in that respect are the ones that have the relatively large number of unknowns in them, and they are typically projects that are trying to do something which is worth doing.

"So you have this quandary: projects that are failures in that sense very often deliver something which is very useful." DeMarco says in assessing the relative success of a project, many organizations omit this most important part of the equation: consideration of whether the resultant product is a success or failure.

If a project fails on two criteria — it cost a lot more than you thought, and also ends up being useless — few would argue the project was a failure and it should be labelled as such. But DeMarco points to a middle ground, where a project raises the ire of management and the frustration levels of staff by taking longer than expected, or where cost overruns are rife, but where the product ultimately delivered is useful and highly esteemed by the people that receive it. Are we going to call that project a success or a failure? DeMarco has no doubt that we should call it a success.

What is missing from many assessments, he says, is a reluctance to acknowledge the unpredictability of software development, and the fact that projects intended to produce something worthwhile are inherently hard to predict. "We hear these studies all the time about how many projects are failures," he says. "I've never seen a study about how many products are failures, have you?"

It is normal for project managers to focus on generating data and delivering projects on time and on cost, Valense managing partner Michel Thiry says. But since IT is a fairly turbulent environment, dynamic and fast moving, it is just as normal for the goalposts to change. Obviously if we focus on time and on cost, we will be seen to miss the target, but that may well be to miss the point. Better to focus on benefits to the organization, Thiry says.

"If instead of focusing on time, costs and the technical aspects of the project, they could focus on the benefits that the project will provide to the organization, it would then be much easier to say there might be changes in cost, there might be delays, but as long as we achieve our expected benefits we will call that a success. Take the example of the Sydney Opera House, which 40 years ago was absolutely over cost but today is a major landmark of Sydney. As a project if you consider it only in terms of time and cost, it was a failure, but as a benefit to Sydney it was a success, although it took more time than planned to get there," Thiry says.

Dimension Data Group executive: services Scott Petty thinks part of the difficulty lies with the way many organizations measure their projects. Typically when a team wants to do an IT project they write a business case and define desired business outcomes. But in many organizations, once the project is under way those outcomes, while not forgotten, get little consideration. Most project managers are "goaled" on whether they get the project done on time and on budget, he says. As any good project manager will tell you, the focus is on keeping the scope well-defined, looking for variations and pushing back on any changes around those areas that would help keep the project running on time and on budget.

"But because they lose that link to the business outcome, often the end result that's delivered doesn't actually achieve the business goals that were originally intended in the business case when they started that project," Petty says. "So I tend to think that there's a missing link created in that area because those business outcomes aren't driven into the fabric of the way the project is run, so pretty much everyone working on the project focuses on the way the project is going to be measured, which is on time, on budget."