Hazards
True there are hazards for the project manager of an IT project along the way.
- What if the business or commercial environment changes?
- What if the technology platform changes?
- What if related software from other sources changes, necessitating a change in configuration?
- What if the Business Case conditions change?
- Or there is excessive "scope creep" to the point the product projection is no longer viable?
- What if there are safety concerns?
- Or "political" opposition, i.e. resistance to change that has nothing to do with the product itself?
It seems to us that all of these are beyond the realms of the project manager's control. What the project manager can do is to have his or her risk management sensors out, and if the conditions are sufficiently severe, then cancel the project. Wouldn't that be the smart business thing to do? And in so acting, shouldn't that be considered a project management success and not a project failure?
There is another compelling reason. In these days of a highly competitive global market, time-to-market is crucial. You can have a better product, but if it is behind a competitor, the chances are that it will have missed the "window of opportunity". Consequently, the product won't "sell" and the project will indeed be a failure.
The best way of finishing a project early is to start early. This may well mean starting not just with incomplete information - project information is never complete - but with substantial uncertainty. So, in many cases, starting early but on the understanding that experience learned along the way may cause us to cancel at some point is simply good project risk management. People who take risks may win only, say, 10% of the time, but people who don't take risks don't win any percent of the time. In fact, they probably don't even survive!
The problem is that senior management, and project managers for that matter, get hooked on an idea and become reluctant to give it up. Worse yet, they look at the effort and money invested thus far and say to themselves: "Only just a little bit more and we should be home free." That could be true, but it is the wrong premise for a decision. In making such a decision, never count what has already been spent. What has been spent to date is already "sunk cost". Always look to the future and estimate what has still to be spent and whether the benefits justify continuing.
And if it does appear to be worth continuing, what is the updated Business Case now telling us, and what are now our most important goals? The chances are that the answer to that question is to be found somewhere in the product quality dimension. And that, in turn, depends on having the competence and skills available to bring the product to a successful conclusion.
|
Product
Success
