Lifting the Game

There is always plenty of talk about improving the software process, but Thorp thinks it is the project chartering process that most needs re-engineering. There are also other areas where project teams must lift their game. We all understand we do not know how to predict how long a piece of software will take to develop, he says; any company will tell you so. What almost none of them do then is to take the obvious next step of trying to figure out how to get better at it.

"Some companies have really solved the problem: they build metric databases, they measure each piece using some level of function metric before they build it, they predict from the estimates of the function metrics and extrapolate from the database to say how long it will take to build, how much effort and so on. That is something that the best companies do, and interestingly, the companies that are called systems integrators, because they have to deal directly with the market are very good at that — the Lockheed Martins, the Computer Sciences. The systems integrators in general have solved that problem the way the whole world would have, I thought by this time. Other companies just put a wet finger in the wind but do not really do their homework. They are not able to predict how long software will take, because they haven't built the metric databases, they haven't built the skills," Thorp says.

"Now that's the surface analysis of the problem. The deeper analysis of the problem is they don't want to do that because they believe that it isn't really germane. What they do is they pick some date that clearly is not doable, and announce that to be the schedule, and they think that is good enough because that guarantees the project will be under a lot of pressure.

"But they're not dealing with the damage you can do to your project by starting it off on an unrealistic schedule. And that is so damaging. If you set out to build a project in one year and it takes two, then I want to hold your nose to the awful fact that if you'd started out on a more realistic schedule, you might have built it in a lot less than two. If you had scheduled 16 months you might well have finished it in 16 months. And you set people up as losers. So there is an area where most companies aren't on their game."

Going back to benefits realization, Capability Management's Simms puts it this way: "A benefits realization approach is about making the right decisions about the right things, and then managing the decisions you make. A client of mine once said: 'A lot of consultants say the same thing — start with the end in mind'. A benefits realization approach does not just start with the end in mind, it manages value continually with the end in mind. It's a process that goes right through to the full realization of value, that is 'from concept to cash'."

Adopting a benefits realization approach involves a long-term, sustained change effort in how organizations think, manage and act. New processes and organizational structures will be needed to operationalize the new mind-set. Major changes will be required in the areas of accountability, measurement and the process of change itself. Project managers can and must play a leadership role in driving and implementing this change.

Until most organizations get there, we might as well debate whether falling trees make a sound if no one is around to hear them as whether or not any particular project succeededor failed.