OK, I have to admit it. When it comes to project methodologies I have a special place in my heart for PRINCE2. PRojects IN Controlled Environment, as its full name goes, fascinates me because it combines the structured approach to managing projects with the flexibility usually found in Agile methodologies. In this article I will present a few key points about this method and I will focus on how project managers can benefit from it by adapting it to their project needs.
The philosophy
The main thing about PRINCE2 is that it focuses on the product and its justification. If you think about it, that makes sense; after all, we do go into the trouble running projects because we intend to achieve an outcome. Therefore, what this outcome will be should shape the planning of the entire endeavour and is certainly relevant across all the phases. Equally questioning the reasons we should have this product is critical and PRINCE2 encourages checking the validity of the business justification at all stages, thus saving us from wasting resources and time.
The key to success for PRINCE2 is, as its name suggests, running projects in a controlled manner. Therefore it dissects the project into phases, which are more manageable to run, or in other words Divides and Conquers. In this way the running of the project becomes smoother and the impacts of risks are minimised. Furthermore, executing the project in an iterational fashion gives the flexibilities and the added benefits that we usually see in Agile methodologies.
The best part? PRINCE2, as stated in its official documentation, should NOT be followed religiously but rather applied in a way that adjusts the circumstances of the project. Simply put, the project manager, based on their experience, can shape this methodology in such a way that the delivery of the product is carried out taking into account the client circumstances, the complexity, urgent deadlines (oh yeah, even when unrealistic!) etc. At the end of the day, the client will not check our aptitude in the PRINCE2 manual but rather assess us on whether the product they’ve paid for (or not sometimes…) is delivered on time and at the expected quality ! Exactly this point is the inspiration for this article.
How it works
So now that we’ve seen its principles, let’s have a brief overview on how PRINCE2 works. As we mentioned the methodology is divided into phases. In each phase, or process to use the terminology of PRINCE2, a number of deliverables are produced which serve as input for the next one. The processes, which are given a two-letter coding, are:
Starting Up a Project (SU):
Upon receiving a mandate for a product, in this phase, 2 main things happen
- the project management team is formed and
- the project brief is composed which includes info about the project and preliminary planning
The deliverables of this stage are passed to management in a process called Directing a Project as we will see below
Directing a Project (DP)
This process reflects the decision taking of management and project sponsors. It has 5 distinct functions:
- Authorises the initiation of the project (takes input from SU)
- Authorises a project (takes input from the Initiating a Project stage IP that we will see in a minute)
- Authorises a stage or Exception plan (takes input from the various stages)
- Confirms Project closure
- Gives ad hoc direction as the project evolves.
Initiating a Project (IP):
This is where the preparation of the project takes place once the go ahead is given from the previous process. Below are some of the things that take place here:
- Quality Planning
- Project Planning (takes input from the stage called Planning PL)
- Refining the business case and its risks
- Setting Up Project Controls
- Set the Project Files
- Put everything together into a PID
At the end of this process we do a preparation for our first of the subsequent project stages (can be 1 or many) in Managing Stage Boundaries (SB) the output of which along with the PID are forwarded for review to the project execs in the DP process we’ve seen a minute ago to get the go ahead to proceed.
Managing Stage Boundaries (SB)
At the end of each Stage and before the beginning of the next, we need to take a breath and see the big picture. This is the purpose of this process. Here we do:
- Plan the next stage or in case of an exception, produce an Exception Plan (again going through the PL in either case)
- Update the project plan
- Update the Business Case and the Risk Log
- Draft a reporting for the previous stage and forward to DP
Planning (PL)
As seen in the previous stages, planning is required to move forward and in this process, through an iterational process, the project plan is produced or updated.
- Design the plan
- Define what are the various end products
- Identify what activities need to be done to produce them
- Estimate each activity
- make a schedule for each activity
- review the Risks based on the planning produced and if required revise following the previous steps
- Complete the plan
Controlling a Stage (CS)
With the plan in place we are ready to start the management of each phase of the construction.
- Authorise the Work Package (the set of actions to be done) and pass it to the Managing Product Delivery process (where construction takes place)
- Assess the progress of the construction project
- Capture and Examine project issues
- Review the overall stage status
- Report stage highlights to management AND / OR Escalate any project issues
- Receive completed work package
Managing Product Delivery (MP)
This process is where the real work happens. For the product construction there are 3 distinct things that take place:
- Accepting a work package
- Executing the work package
- Deliver the work package
Interestingly this phase can run with a different project management methodology e.g. a contractor might use Extreme Programming to develop a software. They will still have to interface though with PRINCE2 based on the above. Myself, I have used Scrum to deliver a particular functionality of an application which in turn was in the process of being built using PRINCE2.
Closing the Project (CP)
At any point, the project might need to be closed down.PRINCE2 gives emphasis to a graceful termination that involves 3 steps
- Decommissioning the project
- Identify follow on actions
- Evaluating the overall project
This way the outcome is properly handed over to the business owners and any lessons learned serve as guidance for future projects.
Artefacts
Aside from the various processes, central role in PRINCE2 play the various artefacts. These can be grouped as follows (the main artefacts are shown and their titles are self-explanatory):
- Organisation
- PM Team Structure
- Job descriptions of PM Team
- Documents
- Business Case: Effectively this is the specs of the product and reason for its importance
- Work Package: The set of actions need to be done at each stage
- Project Approach: Explains what methods will be followed in construction and quality
- Plans
- Project Plan (and can be Exception Plan or Stage Plan)
- Communication Plan
- Quality Plan
- Logs
- Daily Log
- Risk Log
- Quality Log
- Issue Log
- Lists
- Product Checklist
- Product Descriptions
- Reports
- Highlight report
- End Stage Report
- Exception Report
- Notifications (related to the project executives)
- Authorisation to proceed
- Guidance
- Exception Plan Request
- Concession
- Project Initiation Document
- Combines a number of documents, logs and plans.
The various project processes are outlined in the below diagram:
Optimising PRINCE2 for your Project
As mentioned earlier, a major benefit of this methodology is that it can be tailored to match the particular circumstances around the project. Let’s see this through a real example from a project I worked on:
————————–
The mandate was to build a new corporate website for a company and the main info provided has been a referral to the existing site.
Stages:
– SU
The Project Executive was the requestor and the Project Manager myself. Two developers has been deemed that will be required and they would collaborate with an external contractor to provide the images and multimedia for the site and an Infrastructure team to prepare the servers. The IT Analyst would also be myself.
I prepared the Project Brief with an overview of the functional requirements. The project was decided to run into 2 stages (1st: prepare core site with a content management system and 2nd: integrate the graphics). The info went into the Project Approach doc and I planned for the actions to take place in IP. I also started my risk log.
– DP
The Project Brief was incorporated into a management information package and passed to the executive and the IT Sponsor for review and approval. This was given so I proceeded to initiating the project.
– IP
Along with the Project Executive we reviewed the site’s expected features and decided on the quality criteria. As expected he wanted all the same features of the existing site but the layout should be based another company’s site. With this in place I started the planning of the project
– PL
I made a list of all the functional bits of the site and along with the development team we reviewed what are the activities. Taking into account their availability of the developers I combined all dependencies and activities and calculated work estimates. Finally I put everything on a GANTT and created my plan. At this stage I assessed the risks and I identified that possible delays in the external provider could bring the project completely off-track since the development team would not be available after a certain time. So I worked with all involved to get minimise this risk and after agreeing on certain delivery dates I redrew my plan to adjust to this.
– IP
Back in IP, I continued working on details of various features of the site and reviewing any associated Risks. At the same time, I started filling the PID with the various documentation (the quality plan, configuration management plan, the communication Plan etc.) and drafting the business case. After various iterations of review with everyone involved the PID was ready for submission.
– SB
The first stage of the site was planned and the activities refined with the development team. Since they had already expertise on building websites an they had a ready made solution, the planning was straight forward and no major risks were identified. No updates were required to any of the docments and a management report was passed to the project execs.
– DP
The executives and sponsors, which I already kept informed at every stage, signed off all the documents and we proceeded immediately to construction
– CS / MP (Stage 1)
I drafted a brief Work Package for the developers (mainly bullet points). As it happens I was also the Team Leader of the developers so that removed the “middle man”. Everyday, I run status update meetings, filling in my daily log, issue log and risk log and noted the progress. At the end of each week I was drafting a Highlights report. I have also been inviting the Business Owner to review the evolving site and provide comments so that we capture early in the game any deviations.
At some point, it has been identified that there were some incompatibilities between the software used for the site CMS and the underlying operating system. After examination of the issue it was deemed that the problem could be fixed with patching but it would require a 2 day deviation in the plan This was escalated to the Sponsors and the executive who conceded this and allowed for the corrective action to be taken.
Once the product of this stage was completed it was deployed in a test environment and once the quality was checked against the quality plan for correctness. Everything turned out to be ok aside from minor problems resolved immediately
– SB
Following the successful completion of the stage, I proceeded with drafting the overall reporting of this closing phase and the planning of the next one. The external contractor providing the graphics, informed that there would be a delay of 4 days which was within tolerable limits set earlier on my risk log. I revised the plan and send everything to the Project Executive and Business Owner for review.
– DP
The authorising for the next stage has been approved
– CS / MP (Stage 2)
Once the graphics were provided, the development team started the integration. It was however identified that there were problems integrating certain styles and images as they were creating “conflicts” with the layout already prepared in stage 1. Therefore there was a need to redesign partially the application to fix this. The problem has been escalated to DP
– DP
Upon review of the situation, it was decided to approve running an emergency plan for this.
– SB
An exception stage was planned whereby a partial redesign of the site would occur. After further review it was deemed it would take 5 extra days. To save time Stage 2 and the Exception Stage were combined since some activities could run in parallel with the same resources. The overall plan had to be updated with this information. All the information was submitted to DP for approval
– DP
The executive and business owner approved.
– CS / MP (Exception Stage & Stage 2)
The work started to realign the layout and at the same time process some of the received images. Once the problem was resolved, no further issues were noted and the final product was compared against the quality plan. The product was handed over to the users for checks. Minor problems were remediated immediately affecting the overall project by 2 days in total. This was communicated to DP who made this concession to the plan
-SB
The overall progress was noted and the plan was updated. The executive and the sponsors accepted the product and authorised the project closure
– CP
I ensured all project info was archived (used MS Sharepoint, great tool by the way) and since there were no follow on activities I communicated to all involved the lessons learned, mainly focusing on the management of external providers.
——————-
As you can see from the above example I ran the project by combining certain elements (e.g. roles of PM and Team Leader) and Processes (CS and MP). These reflected exactly the situation of this project whereby the same people we holding multiple roles and as such certain processes could be combined.
Conclusion
PRINCE2 is in my opinion a diverse methodology that can be scaled to any type and size of project. The Project Manager needs to have, though, the necessary experience to assess how this will be done, since omitting certain components of this methodology or focusing too much on others could in the end be counter-productive. Among all these extremities, the duty of the Project Manager is to know what is the final product and the current circumstances and then align PRINCE2 to all this.
Enjoy !
Leave a Reply