PRINCE2 Resources

The 2009 PRINCE2 progress theme is the 2005 Controls component 'lite'. Two major systems of project control are described: Stages and Tolerance.

The sub-division of a project into Management Stages is a principle of a PRINCE2 project, and the theme expands the principle by explaining what stages are, how they might be defined and how they might relate to the technical work of the project.

Tolerances are described in detail to support the Manage by Exception principle.

Two separate but closely linked disciplines are covered in the PRINCE2 Change theme - Configuration Management and Issue & Change Control. Any project manager will soon learn that keeping track of the status of products and the relationships between them is a crucial element of the project team's work, and that keeping change under control is similarly vital. This theme provides some basic advice on how to implement a system with which the baseline can be maintained and protected against the effects of uncontrolled change. 'Scope creep' doesn't happen on a PRINCE2 project!

Configuration Management follows the same pattern as the 2005 version, with advice on planning, identification, control, status accounting, verification and audit. Records about project products are kept using Configuration Item Records, and the whole system is defined in a Configuration Management Strategy specific to the project.

Once the products are under control, the Issue and Change Control procedure can be deployed to make sure that they aren't changed recklessly or without regard to the effects on the business case, the plan, risks and the other products. The change control procedure of capture-examine-propose-decide-implement is used to manage the three types of issue familiar to PRINCE2 practitioners - the Request for Change, the Off-Specification and the Problem/Concern.

The PRINCE2 approach to the management of risk is firmly based upon the OGC guidance on this subject. Risks must be identified, assessed and controlled to support effective decision during the project, and to protect the viability of the business case.  A Risk Management Strategy is required, which will set out the procedures to be followed during the project and set the context for risk tolerances.

PRINCE2 recommends a risk management procedure comprising a number of steps to identify the context and risks of the project, assess the individual and aggregate effects of risk, plan risk responses and then implement them. It explains also the importance of communications in effective risk management. The risk register, of course, also makes an appearance, and there is a good deal of detail about the potential responses to risk, both threats and opportunities.

 

 

Three levels of plan are used in PRINCE2.

The project plan is a high level 'helicopter' view of the whole project, used by the Project Board to keep on eye on the total project and to provide the figures (costs and timescales) on which the business case is based. This plan is created at the beginning of the project and then maintained and adjusted as the stages are completed.

The stage plan is the day-to-day management plan used by the project manager. The stage plan for the next stage is planned in detail as the current stage nears its end, thus ensuring that a stage plan is as accurate as it can be and the effects of the planning horizon are minimised.

The team plan is a subdivision of the stage plan and relates to the work package - the unit of work a project manager allocates to a team manager (who might be a subcontractor). Team plans contain the most detail. Team plans can be integrated into stage plans, so they are in effect optional.

Exception plans replace plans which have gone pear-shaped, normally after an exception has been raised and the exception plan option has been taken.

The Plans theme includes much detailed advice about a plannning process which in the 2005 version of PRINCE2 was a process in its own right. It's not clear what the logic is in integrating this detail into the plans theme, since, like it or not, planning is a process which all projects should go through.

The PRINCE2 Quality theme describes three aspects of quality which the project management team must address.

Quality Planning means understanding what the customer requires and defining the acceptance criteria for the overall project, setting out a strategy for achieving this, defining the individual products of the project, and detailing the methods of showing that they meet acceptance criteria. This quality planning is documented in a Project Product Description, Quality Management Strategy and individual Product Descriptions.

PRINCE2 avoids any discussion of how a set of acceptance criteria can actually be developed in practice through processes of analysis and requirements engineering.

Quality Assurance refers to activities independent of the project management team which check that the project has systems in place for Quality Planning and Quality Control. The project team does not do Quality Assurance itself. (There is argument about this aspect of PRINCE2, of course, since even the word 'quality' tends to throw up differing opinions about what is meant. Some would say that a project team is fully responsible for quality assurance by adopting or modifying a system of processes, procedures tools and techniques to meet the need to demonstrate that a 'good' product is being produced. PRINCE2. It all depends what is meant by the term 'Quality Assurance').

Quality Control covers all the activities of checking the conformance of a product to its quality criteria, and also process improvement (more usually in practice associated with Quality Assurance - some practitioners may have to 'unlearn' some concepts to fit the PRINCE2 language). Two categories of quality control activities are described - In-process methods and Appraisal methods.

The theme also covers a Quality Review technique, describing a formal structure to a review process for quality control suited to documents. Other quality control techniques are, of course, available!

 

The Organisation theme of PRINCE2 responds to the principle that a project must have defined roles and responsibilities.

An effective project team must have representation of the three interests of the business, the user and the supplier. This isn't just true for PRINCE2 projects, of course. It's fundamental to any project organisation that the right people ar involved. The method provides a framework for the organisation of a project management team which supports both the need for accountability and authority to be in the right hands and the need to implement a management by exception approach. PRINCE2 provides placeholders for a number of defined roles in the project management team aligned to the project needs of directing, managing and delivering.

It is a principle of PRINCE2 that the method should be tailored to suit the project environment, so the organisation structure should be modified to suit. In fact, the entire set of PRINCE2 roles can be filled with just two people.

The 2009 version of the method introduces more guidance on working with stakeholders, and proposes that each project develops a Communications Management Strategy.

 

The Business Case theme responds to the principle that a PRINCE2 project should have continued business justification.

The purpose of a Business Case is to justify the investment in the output of a project - the products which will be delivered by the project team. This justification is generally made in the form of an investment appraisal setting out the predictions of cost, benefits and associated risks over the life of the product (not just the project). This picture will be changing through the course of the project as costs are committed, changes are made and opportunities or threats impact on progress. The business case is therefore re-assessed at each stage boundary.

Outputs of projects are used to deliver some form of change into the customer organisation. Outcomes are the results of these changes which may (or may not) result in benefits. It isthe delivery of these benefits which, in general, is the purpose of a project.

The organisation should measure whether or not benefits are delivered from its projects (its investments). PRINCE2 suggests that a Benefits Review Plan is created, setting out the predicted pattern of benefits delivery in the future and arranging for the monitoring anfd measurement of these benefits.

Many project managers have raised objections to using PRINCE2 because of the widely held belief that it's too complicated, with too many documents and too much administrative overhead for their 'lean, mean and always successful' projects to use.

Well, if you were to implement every word in the PRINCE2 manual, that's probably what you would get. That's why the manual devotes a whole chapter to explaining why the method should be (note: should be) tailored to fit the project environment. PRINCE2 can and does work successfully in many different industries, many different sized projects, in many different countries all over the world. The places where it doesn't work so well is where no consideration is given to how to tune it up for the specific project environment.

Tailoring is therefore fundamental to the method.

All projects produce products, mostly tangible (things you can kick) and some intangible (things you shouldn't). It makes sense therefore to base a project plan on the idea that products will be produced.

The PRINCE2 focus on products is one of its most powerful features (in this authors opinion). Many project managers will have suffered the problems caused by inadequate defintion of the scope of the project, and pitiful attempts at specification of acceptance criteria which lead to scope creep, argument and blame allocation as projects fail to deliver what users 'expected'.

PRINCE2 starts the planning process at exactly the right point - the definition of the products to be produced and agreement of the acceptance criteria. This is an immeasurably better starting place than sketching out a sequence of activities on a bar chart and calling it 'planning'.

The principle of 'Manage by Exception' essentially translates as 'when you delegate authority to someone, be very clear on the limits of that authority'.  In PRINCE2, limits of authority are set by means of 'tolerances' (on time, cost, risk and so on). Predictions by managers that they will exceed their tolerance are flagged up as an 'exception', of Management by Exception fame. Exceptions trigger pre-programmed PRINCE2 responses in the project management team or in corporate or programme management, dependent on where in the fchain of command the exception occurs.

This is a great idea, which should be welcomed by every manager in the project management team.

Projects which start with grand ideas, complex plans and huge budgets will quickly spiral out of control if checks and balances aren't applied at appropriate intervals by the right decision makers. This is necessary because of many factors, not least because we (all of us) aren't that good at putting together long complex plans and also because we (all of us) like to change our minds a lot.

PRINCE2 therefore demands that we plan and execute our projects in stages which represent a reasonable balance between the need to move forward and the realities of uncertainty, planning horizons and inevitable change. The method is therefore based on the use of management stages.

Many of us who've ever been involved with a more-than-trivial project will have despaired at the waste of resources as the same lessons are learnt and forgotten over and over again.  A crucial  principle is one which should be attached to every project, PRINCE2 or not. This is the simple idea that the organisation should learn the lessons of previous projects and apply them, and also record and promulgate the lessons from the current project.

Project teams which aren't doing this can't really be said to be running a PRINCE2 project.

Every project needs some sort of organisational structure, and a PRINCE2 project is no different. The method points out, somewhat redundantly since there is entire Organisation theme which covers the subject, that there should be a project management team with defined roles and responsibilities representing the three interests (universal in projects) of the Business, the Users and the Suppliers.

Every project should have a business justification, in most cases demonstrating a favourable balance between investment of resources and the anticipated (or at least expected) returns.

It is a principle of a PRINCE2 project that this justification remains valid throughout the life of the project, not simply used to trigger the project and then forgotten about. The progress of a project will therefore be heavily dependent upon the continuing maintenance of the business case and its continuing demonstration of a worthwhile project. This is explored in the Business Case theme.

In PRINCE2, the business case can be documented in the Business Case document, and supported by a Benefits Review Plan.

In PRINCE2, no business case = no justification = no project.

 This page is the starting point for a hyperlinked tour of the PRINCE2:2009 method.