Interesting isn’t it, how what would have been success for the project, only becomes clear to us as we survey the wreckage of its failure.
The project should have done this; it should have done that. Confronted with the wreckage, it’s all so obvious and clear now.
This seems to apply to business change projects, computerisation (eg. the UK’s National Health IT programme), system development projects, the list goes on.
But why wasn’t this new-found clarity available at the start of the project? Why did no one insist on clarity in what would constitute success; and even, what would constitute failure?
- everyone in the early days, assumes it’s obvious what success would be and everyone shares that view
- perhaps the precise form success must take is something that has to be discovered en route; it’s just too hard to know beforehand
- and have you noticed how much easier it is to talk about activity; of what projects must do, rather than what they must achieve?
Maybe, it’s a combination of all of those?
Or the unthinkable: maybe corporations, businesses and public sector organisations find it so onerous and uncomfortable to define project objectives with clarity, they simply prefer to go ahead and explain away the failures (a 60-80% risk according to some, but probably much higher)…
…due again to unforeseeable circumstances to speak the “we must learn the lessons” line again, to swallow the ballooned costs of the mis-investment, and airbrush the entire sorry episode out of history, again.
Does it have to be that way? No.
The answers are available, but they involve insisting on a shared clarity in project objectives. Are managers ready to insist on that clarity? Or in a choice between clarity and mis- investment, is mis-investment the lesser of two evils?
One thing I’d add is lack of vision . Too many tpcjeors either have no vision of where the team will go or someone has a vision but does a poor job of communicating it. A good vision statement gives the team something to unite around.