Wednesday 12 March 2008

PRINCE2 Cost v. Benefit

Prince2 is a Project Mgt. method used internationally.

But what's the cost v. benefit? It's mandated in UK govt. projects, but this has not prevented some recent, classsic failures.

Which of these statements do you lean toward?

  • Prince2 assures the discipline, governance, quality & risk control, alignment with business goals, documentation and guaranteed deliverables needed in an IT project, without which there would be anarchy and failure.

  • Prince2 is a fat, heavy-handed method that goes back to the 1970s, before the world became the fast-changing global village, Internet-enabled place that it is today, and it is a source of competitive disadvantage in preventing IT from meeting customer business needs in the time needed, and getting product & service to market.
The primary advantage of Prince2 is the Business Case, and the business analysis and IT governance that goes with it. It seeks to ensure that the project is rigorously aligned with business aims, and is likely to add value to the business.

The rest of Prince2 is all about the management & control of each stage of the project so as bring about expected deliverables and benefits, as promised in the Business Case.

The issue is that you don't necessarily need Prince2 - and perhaps the bureaucracy that goes with it - to have a good Business Case.

So Prince2 is a double-edged sword; required rigour on the one hand, and bestial bureaucracy on the other.

For example, there is a great deal of documentation, formal approvals, inspections and co-ordination needed in a Prince2 project. Is all of this really needed? Will the documentation actually serve any real purpose?

Arguably, this all adds time to the project. And yet, IT customers may be needing the deliverables - or at least the core component of them - sooner than later; much sooner, owing to business environment and/or competitive pressures.

A second issue is the old chestnut of paralysis by analysis which, arguably, a Prince2 culture fosters. When you have to allow for your business and systems analysis being subjected to severe scrutiny, with no errors allowed, you tend to make sure that it's iron-clad.

Whereas, supposing IT were working in a closer, more iterative, less formal, ego-less mode with its customers, what would happen then?

A third issue is that Prince2 virtually assumes no change, whereas this is one thing you can depend on: change. Consequently, one of the major problems in systems development and its project management is Requirements Creep. After all, it's often impossible for IT customers to know up front what's really needed.

A fourth issue is that Prince2 arguably dis-empowers IT people, and controls rather than trusts. What would happen if IT people became much more in the business picture, really and truly part of it, and were empowered with the (1) business knowledge, (2) tools, (3) business guidelines, and (4) trust as to what's needed and when, albeit with frequent interaction between customers and IT?

In other words, would it be possible to have our cake and eat it?

Might we adhere to Prince2 as a model,
and use its principles as guidelines,
while avoiding the bureaucracy?

No comments: