I’ve been using Prince2 as a methodology at the University of Manitoba for almost a year now and I’m quite impressed. As a methodology it is quite good and focuses on the right things. Prince2 recognizes that a project initiated well sets a project up to succeed. There three things Prince2 does during initiation that I feel set it apart from other methodologies.
Project Initiation Document – PID
The PID or the Project Initiation Document is the main initiation document in Prince2. We commonly refer to the PID as a Project Charter on steroids. The table of contents for a typical PID contains the following
- Business Case
- Project Definition
- Product Based Planning
- Project Approach
- Project Governance and principles
- Quality Management Strategy
- Risk Management Strategy
- Organizational Change Management Strategy
- Organizational Capacity Management Strategy
- Project Plan
As you can see from the table of contents, the PID is a much more in-depth document and agreement than the typical project charter. It also more of a strategy document than project charter by getting the project team to discuss and document strategies for Quality Management, Risk Management, Issue Management, Communication Strategy, Change Management Strategy, and Capacity Management Strategy.
There are two sections of the PID that go right to the strength of Prince2
One of the main strengths of Prince2 is the Project Governance and formal Project Board structure. In Prince2, the Project Boards makes all the decisions for the project and is made up of the following three roles:
- Executive – Main sponsor or project champion – typically provides the budget
- Senior Supplier – typically provides the resources for the projects
- Senior User – typically will use the solution operationally when complete
These three roles are unique compared to other methodologies and it really serves the project well to ensure that all decisions are made in a balanced and thoughtful way. The really unique part of the Project Board structure is allowing for a seat at the table for the Senior User. Typically the users of the solutions don’t have a leadership role and only get involved for requirements definition and testing. By getting involved earlier, the Senior User has the ability to guide the vision of the solution. In my experience, this really allows for great value being delivered and fewer subsequent enhancement requests that are required to make the product useable. 🙂
Product Based Planning
Perhaps one of the most valuable Prince2 concepts is the Product based planning. This term refers to the Prince2 focus on what products the project is going to produce. Prince2 has a deliverable named Project Product Description. The Project Product Description is intended to describe the ultimate product that the project will produce. This deliverable helps to focus the project team to describe what project success will accomplish before defining detailed requirements. This process is very helpful and helps to create a shared vision across the project team. Prince2 then tasks the project team to define the interim product descriptions that are needed to ultimately create the Project Product Description. These Product Descriptions could be documents, demos, prototypes, or anything that is created during the project. A Product Breakdown Structure is then created to define the order the products and sub-products are created in. This Product Breakdown Structure is an excellent vehicle to uncover dependencies without having to create a detailed work breakdown structure.
By creating these three descriptions/documents, a lot of clarity is provided to the project team on what will be accomplished, what interim steps and documents are needed, and what order the project team will create them in.
Right now, I bet you are wondering just how top-heavy and cumbersome Prince2 is. The real benefit of Prince2 is that these deliverables can be detailed separate documents or a few paragraphs in the Project Initiation Document.
Prince2 has two principles that align it with Agile:
- If you don’t customize Prince2 methodology then you are doing it wrong. The customization of Prince2 is one of the 8 foundational principles of Prince2
- Prince2 is perhaps the only Manage-by-Exception methodology I have seen. There is a section in the Project Initiation Document that defines the acceptable tolerances for the project. Only when the project goes outside these tolerances, does the Project Board need to be involved.
So Prince2 formalizes space for the project team to work and not be micro-managed.
Sounds more Agile than Scrum if you ask me…