A PRINCE2 project has defined and agreed roles and responsibilities with an organization structure that engages the business, user and supplier stakeholder interests.

PRINCE2 is based on a customer/supplier environment. It assumes that there will be a customer who will specify the desired result and probably pay for the project, and a supplier who will provide the resources and skills to deliver that result. Every project needs effective direction, management, control and communication.

Establishing an effective project management team structure and strategy for communication at the beginning of a project, and maintaining these throughout the project’s life, are essential elements of a project’s success.

One of the principles of PRINCE2 is that all projects must have a defined organizational structure to unite the various parties in the common aims of the project and to enable effective project governance and decision making.

A successful project management team should:
a) Have business, user and supplier stakeholder representation
b) Ensure appropriate governance by defining responsibilities for directing, managing and delivering the project and clearly defining accountability at each level
c) Have reviews of the project roles throughout the project to ensure that they continue to be effective
d) Have an effective strategy to manage communication flows to and from stakeholders.

"How does a project get to be a year behind schedule? One day at a time" is a famous quote from Fred Brooks, chief designer of the IBM 360.

When most of us create a plan we think about the activities required to achieve our goal. For example, if our project was to redecorate a room our plan might be to choose new wallpaper, choose new paint, strip the old wallpaper, prepare the woodwork, hang the new wallpaper and paint the woodwork.

Product Based Planning is a technique that focuses on identifying what we intend to create or modify before we think about how to produce it. In this way we would focus on the outcomes first, wallpaper options, chosen wallpaper, paint options, chosen paint, stripped walls, prepared woodwork, hung wallpaper, painted woodwork. Once we know what we are to produce we can start thinking about how to produce it.

Product Based Planning is a Prince2 technique that can be applied to all project planning activities.

Harvey Mackay said, "Sometimes it's risky not to take a risk - if you walk backward you never stub your toe"

To succeed in business you have to be prepared to take risks, but they should be calculated risks. I never cease to be amazed by the number of companies who barely pay lip-service to risk. Many will have a brainstorm session at the beginning of a project to establish the risks they face, however they fail to realise that this is just a snap-shot in time. Risk is ever present, and everyone in the organisation has a responsibility when dealing with risk.

Risk can be defined as an uncertain event or set of events that, should it occur, will have an effect on
the achievement of objectives. Risk management activities should be a scheduled regularly where the status of all risks is updated and new risks can be identified, assessed, categorised and responses prepared.

Anything less is really taking a chance!

All project management methodologies have one thing in common, the need for a viable business case.  If a viable business case does not exist then the project should not be started.  Similarly, if that justification becomes invalid during the course of the project, the project should be stopped.

In a Prince2 project the business case provides:

·         The driving force behind project

·         Justification for the start and continuation of the project

·         Focus on totality of business change

A Business Case is a description of the reasons for the project and the justification for undertaking the project, based on the estimated costs of the project, the risks and the expected business benefits and savings.

Prince2 doesn't define the exact format of the business case - this will be a standard within organisations, although Appendix A of the manual gives a suggested outline. Any business case should contain at least the following sections:

·         The reasons for the project, which should include some supporting background information, both historical and operational

·         An appraisal of the different options to achieve the business benefit, and the reasons for the preferred option

·         In almost all projects the option of doing nothing should be included with the costs and risks of inactivity included along with the differences (costs, risks, outcomes etc) between doing nothing and the proposed project.

·         The preferred option should always be last on the list

·         All options should be given equal billing; however some additional justification can be given for the preferred option if required.  For example, the preferred option is $5000 more expensive than any of the others, but does include 3 years on site maintenance.

·         Identification of the tangible and intangible benefits

·         Identification of the tangible and intangible dis-benefits

·         An appraisal of the risks involved

·         An analysis of the expected costs and timescales

·         An Investment Appraisal.

If there is no outline business case in the project mandate there needs to be one included with the project brief.  The business case is refined as part of Initiating a Project and becomes part of the Project Initiation Document (PID).

The business case is a dynamic element of the PID because just like plans and risks it is going to change.  After project start up and initiation the business case needs to be reviewed and updated during Managing Stage Boundaries, during Controlling a Stage when analysing the impact of issues, and during Closing a Project to help with the post-project review planning.

The key question to ask when reviewing or updating the business case is always ' Do we still have a viable and worthwhile project?' As a result of this regular review and updating the project may be terminated or future parts modified. The business case may also be subject to amendment if the review concludes that the business need has decreased or changed.