So how does PRINCE2 work in the REAL WORLD?

It's an interesting comment/question that comes from every class either literally or by the looks on their faces as the descriptions of the management products keep piling up.  Particularly for smaller projects where it could take longer to read the PRINCE2 manual than to do the project itself.

Tailoring is a critical part of PRINCE2 and the questions start early. Here are a few examples.

1 - Organization theme - there are 9 separate roles plus team managers in the project management team. "We could never get that many people to agree to take part in the project!" "We can't afford that many people on the project management team!"   There may be 9 separate roles plus the team managers but only a minimum of 2 people need fulfil these roles. There must be a separation between the Executive (key decision maker) and the project manager (the day to day get it done person). The key is to ensure that all the appropriate interests (business, user and supplier) are represented and that a separation of duties. 

2 - Starting up and Initiating a Project processes:  "Why have 2 decisions on getting the project started, that takes too much time especially if we have just won a contract, we have to start detailed planning right away?"  For smaller projects or those that have had a recent feasibility study, incoming contract that has been awarded or business case work done, the Starting up a project and Initiating a Project processes can be combined.  All the information created in the project brief is contained in the Project Initiation Documentation. Due to the recent conversations on the initial viability of the project, splitting the discussions into two will not be needed. Rather than have two half conversations, one full conversation to create the PID.

3 - Product Description, Quality Register, Configuration Item Records: ”Why have so many separate sets of information related to products? So much paperwork!"   When I am teaching PRINCE2 I remind people of the message that says if you are abiding by the PRINCE2 principles, you can say you are managing a project in a PRINCE2 way.  I talk about the essence of PRINCE2 and the need for documentation. The need for documentation is unarguable. The lack of documentation increases risk. How you go about recording that documentation is up to you. PRINCE2 gives suggestions on why types of baselines, records and report, but is not so prescriptive as to say you must do it their way.  If it makes sense to create on large PRODUCT "record" with all the attributes from the product description (describing scope & quality), the quality register (describing the timing and results of the quality checking) and the configuration item record (describing version, status and relationships with other products), then do it. 

4 - Issue & Change Control Procedure:  "All those reports, it will take forever to get decisions made!"  Again, remember the essence of the procedure. Escalate when needed.  How the escalation happens would have been determined early and documented in the Configuration Management Strategy.  Also, the previous comment on the need for documentation is still valid.  The escalation of an issue might be done with a simple and short phone call to the Executive (or their delegate). The pre-work necessary to quickly discuss options, impacts and recommendations still must happen.  The decision can be made on the phone and then documented as part of the project records. A quick email to the decision maker  to confirm the conversation and the decision made will suffice.

5 - Exception handling: "I have no authority to proceed when the stage/project exceeds tolerance! What about when the Executive & Corporate want the project to continue without fixing the exception?"  All exceptions start out as an issue that will be recorded in the Issue Register and the details in an Issue Report. If the issue does not get resolved, then it will stay open.  A common version of this story relates to the need for more funding for change requests in excess of the change budget, paying to fix risk events when the risk budget runs out, significant changes in commodity pricing or just poor estimating.  If the Executive and/or Corporate want you to continue the project without the additional funding, then the issue stays open and should constantly be reported on the Highlight reports.  Eventually, the project budget will run out. At that point, the Executive/Corporate have a decision to make. Find extra funding or cancel the project. As a Project Manager, you have acted with due diligence and professional responsibility by raising the issue and keeping it part of the communication.