PRINCE2 Processes

The PRINCE2 process is most affected by working in a program will be starting up a project. This process can be undertaken almost entirely by the program. The program will:

• Appoint the executive and project manager

• Review previous lessons

• Design and appoint the project management team

• Probably prepare the project brief

Management products :

There are numerous management products that exist for both the project and program, for example a quality management strategy. When in a program environment in may be desirable to prefix the management product with project and program to distinguish the difference. Another option is to make the project and program document templates look very different in style. Consideration should be given whether the projects looks and registers will be maintained locally to the project or century by the program. The first of which is for projects in a program environment.

PRINCE2 to the Project environment.

Approach to tailoring PRINCE2 dependent on project's scale:

Let’s start with a simple project

The scale of a project is actually relative to the organization and context. However there are some pointers that are useful to consider for a project that an organization consider as simple. Question often asked is: which elements of PRINCE2 can be relaxed on simple projects? There is no easy answer to this. Even simple projects vary enormously in type and style remember that even simple projects should adhere to the seven PRINCE2 principles if the project is to be managed using PRINCE2. It is in the way the themes, processes and management products are used that PRINCE2 is tailored. Overall the purpose of PRINCE2 can be regarded as reducing the risk of project failure. Thus, whenever any element of PRINCE2 is relaxed, this should be regarded as taking a risk.

Simple project- Themes

The theme most affected by simple projects is the organization theme. Scaling the project management team is primarily about role and function consolidation. Roles can be combined but should not be eliminated. As the executive and senior user roles are from the customer environment, these can often be combined. As the project manager is likely to be much closer to the project board and on more complex projects, members of the project board are often in a better position to carry out their own project assurance. The project manager may undertake the role of project support and be a team member in this case, project manager must balance the effort of managing the project against the effort of doing any project work.

Continuing with themes of the other themes the minimum requirements are:

Business case

It must always be some form of business justification, no matter how this is documented.

Plans

Product descriptions for the key deliverables and a simple plan in the form of a schedule of who is involved in producing reviewing and approving products (this is often referred as a product checklist).

Quality

An understanding of levels of quality required in the project, and of the project products

Risk

Just need an analysis of the risk facing the project, actions that will be taken to implement risk responses and communicating risk status via checkpoint and highlight reports.

Change

You need a simple method of controlling changes to the project and managing the configuration of the products being delivered - for example simple product identification and version control standards with secure arrangements for the storage of work products.

Processes

All process remains relevant even in simple projects. However, the starting of a project process can usually be handled in a less formal manner. The executive and project manager should however avoid the temptation to bypass it all together. In some cases it may be appropriate to combine the starting up a project and initiating a project processes. That it may also be appropriate to go straight from the mandate to the project initiation document skipping out the production of a project brief

Management Products

The choice of format of the management product can help in reducing the project management effort for a small project, for example the project board may decide to receive few, reports orally or have a verbal exchange of information and decisions instead of formal meetings. Reports could be in the form of an e-mail. In such cases the project manager should, as a minimum document the exchange in the daily log. The project initiation document includes elements like:

• Project brief

• Business case

• Risk quality configuration and communication management strategy.

• A project plan and a benefits review plan.

• Highlight reports which include product status accounts.

• The daily log which includes issues, risks, lessons, planned actual quality management activities and configuration item records

• The end project report which will include a lessons report

The following management products may not be needed :

Stage plan: If there is only one delivery stage, then the stage plan details can be included in the project plan.

Checkpoint reports: If there are no team managers, the project manager is doing the specialist work that may be no need for checkpoint reports.

Work packages: Work packages may only be appropriate when the project has team managers. When there is only the project manager, then the stage plan may suffice. However, even in such cases, the project manager may choose to use work packages as a control for individual team members.

End stage report: If there is only one delivery stage, then the end of that stage is also the end of the project and only an end project report is required.

Issue report: If the details of the issue are adequately captured in the issue register (or daily log), there may be no need for an issue report.

PRINCE2 is based on a customer supply environment itself. 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 the result. If the relationship between the customer and the supplier is a commercial one then additional considerations apply. The main consideration is to recognize that there are at least two sets of:

• Reasons for undertaking the project

•  Management systems (including project management methods)

• Governance structures (possibly requiring disclosure of different sorts of project data at different points in the projects life)

•  Corporate cultures (for examples formality wrist taking etc.

Note:

Any of these considerations may lead to clashes

Tailoring in relation to management products:

How do the project initiation documentation and work packages relate to the contract? One aspect of a contract is to describe who is liable if either party fails to fulfill its contractual obligations. The content of the project initiation documentation should focus on how to make sure that each parties obligations are fulfilled.

Multi-organization projects:

Increasingly the organizational context of projects is becoming more complex. Rather than a simple customer/supplier relationship involving two organizations, projects are being instigated that involve multiple organizations. Examples include:

• Joint ventures

• Collaborative research

• Inter-departmental projects

• Inter-governmental projects (for example projects in the European Union),

•  Inter-agency projects (such as projects in the United Nations development program)

• Alliance contracting

• Bidding consortium

• Partnerships

There may be one main commissioning authority (or one main customer) but there may be several customers. Likewise there may be several supplier organizations. One consequence of involvement of multiple organizations is that a project may be 'multi-owned', in that more than one organization shares ultimate control over the decision-making process. Failure to agree the basis for this 'multi-ownership' puts the project at risk and increases the chance of project failure. The guidance to use PRINCE2 in a multi-owned project is similar to the commercial customer/supplier contexts with respect to tailoring the themes with any reference to 'contract' being substituted for 'agreement'. However, arrangements catering for multi-organization projects can become extremely complex. Project boards, for example, can have more members than can practically make effective decisions. If no single party holds sway over the others, a consensus has to be built on each decision. Large consensual project boards work very slowly and the place of their projects is likely to suffer. Alternatively project managers begin to take decisions that are beyond their remit.