What can be tailored in PRINCE2? 

What can be tailored in PRINCE2

PRINCE2 methodology can be tailored to the project environment.

The PRINCE2 definition of tailoring is “Adapting a method or process to suit the situation in which it will be used” You should apply a level of project management that does not overburden the project management team

PRINCE2 Principles

These are universal – they will always apply and are never tailored

PRINCE2 should be tailored for a project’s particular circumstances. All Process activities must be done – but tailoring may cause role responsibilities to change

The Five Key PRINCE2 Tailoring Areas

• Adapting the Themes
• Use specific terminology or language
• Revise management Product Descriptions
• Revise Role Descriptions of PRINCE2 project roles
• Adjusting the seven processes to suit the above

When considering an agile project, how might you tailor stages, management by exception, and Tolerance.

Adopting PRINCE2

To provide an appropriate level of governance and control for an acceptable level of risk, tailoring can be applied to processes, themes, roles, management products and terminology

What is embedding?

The act of making something an integral part of a bigger whole. What an organization needs to do to adopt PRINCE2 as its corporate project management method and encourage its widespread use:

• Processes may be combined or adapted by adding or combining activities
• Themes can be applied using techniques that are appropriate to the project
• Management products may be combined or split into any number of documents or data sources. They can be slides, wall charts or data held on IT systems
• Roles may be combined will split, provided that accountability is maintained and no conflicts of interest
• Terminology may be changed to suit other standards or policies, provided it is applied consistently

Multiple owning and Programmes

Tailoring PRINCE2 in a multi-owned project uses the commercial customer/supplier context, except in multi-organization projects, where tailoring can become extremely complicated. Large Project boards with many members make effective decisions very difficult

If the parties have equal authority, a consensus must be built on each decision, which can be time-consuming

To maintain momentum, project managers may begin to make decisions that are beyond their remit

For complicated situations, consideration should be given to adopting programme management as a more effective means of governance

For projects being sponsored by several separate organizations, governance must be unambiguously defined

• who can make which decisions?
• how is risk allocated?
• what happens in the case of non-performance?

Projects within programmes

If the project is part of a programme, people undertaking programme management roles may also define, influence or constrain tailoring. A project within the programme may have different contexts, including any combination of a simple project, agile and commercial, where all the guidance for those situations may apply to that project

You must ensure that the management products and other documentation are clearly labelled to identify the related project and avoid confusion with programme level documents

Effective use of PRINCE2 in an organization

Training is likely to be generic and less effective if it is not focused on the organizations challenges, as in large organizations, there can be hundreds of projects

Building the information support systems can be a problem if there is no common approach, and lessons may not be easily exploited on other projects and so teams will continually invent different ways of doing the same thing

Creating a PRINCE2 management approach per project wastes tailoring, senior management, stakeholders and project management teams learning time

Tailoring The PRINCE2 Organization

Organizations often find it more effective and efficient to develop their own project management method, based on PRINCE2 and tailored to suit their needs and circumstances

The increase in business performance from effective use of project management methods across an organization is more likely to be effective for organizations of higher maturity

Adopting PRINCE2 in an organization involves two key activities:

• Tailoring PRINCE2 to create the organization’s own project management method
• Embedding the tailored methods by ensuring that people in the organization understand and use it appropriately

Tailoring PRINCE2 to create an organization’s project management method

An organization’s project management method should form a seamless part of the organization’s overall governance and management system

Tailoring PRINCE2 for an individual project

Consideration should be given to the external and internal constraints and influences when applying and tailoring PRINCE2. An organization’s PM method is based on PRINCE2.

This is in effect, two steps, first to understand the tailoring model that has been embedded within your organization, and then consider what extra tailoring is needed to take full advantage of your specific project:

Organizational PRINCE2 Method

All the projects that the organization typically undertakes need to be considered, together with any other organizations, or externally adopted, policies, processes and practices.

The way in which a method is drafted influences the extent to which it will be used, as a method that has a consistent look and feel with a logical structure is likely to promote more confidence in its users than one which is documented in a variety of formats, styles and media

The Project Manager would normally only have to deal with those aspects which are unique to the project being managed, and the greater the consistency between the content parts, the easier it will be for people to understand

Applying PRINCE2 Tailoring

Tailoring, as a PRINCE2 principle, is mandatory, so if an organization does not consider tailoring, it is NOT using PRINCE2

It is important to ensure any tailoring of PRINCE2 adds value in terms of familiar roles, terminology and processes, as this clarifies project governance and facilitates team working with crossed organization corporation

When tailoring individual elements of PRINCE2, check the impact on any other elements to ensure they are all consistent. Effective tailoring and requires skills, experience and judgment and there is no single ‘right’ tailoring solution for a project

People in organizations with a high level of project management capability or maturities are likely to find tailoring easier than those in less mature organizations

PRINCE2 is a web of interlinking parts; themes are used in processes; techniques bring themes to life; individuals fulfil project roles and create management products

Management Products can be split or combined into as many documents or information sources as needed. Each Product Description includes wide-ranging quality criteria, hence they need to be tailored to suit the project circumstances

A project manager may need to use a product naming terminology such as PMI’s ‘project management plan’ instead of PRINCE2’s ‘PID’, and the use of ‘project closure report’ instead of ‘End Project Report’

The Project Manager is responsible for identifying and documenting the level of tailoring for the project – this is documented in the PID, reviewed by the stakeholders and approved by the Project Board

Both the Project Board and the Project Manager may be advised by Project Assurance, project support roles or a centre of excellence (if one exists)

Team Managers may suggest to the Project Manager any tailoring which would help them manage their Work Packages more effectively

Tailoring PRINCE2 Roles

The trade-offs of project board size are Communication, attendance, decision-making, and when combining or sharing roles, the following are NOT allowed:

• Executive and Project Manager may not be combined
• There can be only one executive and project manager
• The project board Executive’s accountability can’t be delegated
• Project assurance can’t be given to the project manager, team manager, or project support. This is due to a conflict of interest
• The Executive and Senior User roles can be filled by the same person
• Project Assurance and Project Support can’t be filled by the same people due to a conflict of interest
• The Project Manager and the Team Manager roles be filled by the same person

REMEMBER: roles can be combined – but not eliminated

Project Environmental factors

These may include:

• Importance of the project
• Geographical location
• Multi-organization project
• Corporate standards
• External customer or supplier
• Organizational maturity
• Language or terminology
• The project is within a programme
• Cultural factors
• Local business practices

First, consider the PRINCE2 principle, then adapt the PRINCE2 Theme in an appropriate manner

PRINCE2 Principles

• Consider the principle – then adapt the theme
• Adjust role descriptions
• Revise terminology and language
• Edit management products Product Descriptions

Also, consider Project Factors

• Team maturity
• Team knowledge skills and experience
• Applying Bodies of Knowledge
• Project and solution complexity
• Type and size of project
• Risk factors

Project Scale considerations

A programme

This is defined as “A vision of some future state – but no clearly-defined path
of getting there” this is usually a business transformation.

A Methodology for managing a programme is needed, and PRINCE2 should be used to manage the projects within such a programme

A challenging project

High risk, cost, size, complexity, important and highly visible, strategic in nature, have multiple organizations and disciplines, it has multiple stages and extended Project Board, with separate roles for Team Managers and Project Support. It will use individual Management Products (stand-alone)

An Average Project

This will have one or more project stages, a standard Project Board, with Team Managers and Project Support as separate roles. Some Management products may be combined.

A Simple Project

This will be within a single organization/site, with low risk, cost and complexity. It will have a single delivery stage and likely shared Project Board roles. It will have combined and simplified management products

The Project Manager fulfils Team Manager and Project Support roles

A task or assignment

This may have a single-person Project Board, with the Project Manager may also be doing the work. The business justification may be “Just Do It”!

The project budget may be funded from the operational budget, where the project may be treated as a single Work Package delivering one or products.

It may only need Work Packages, Product Descriptions, simplified Logs/Registers and Checkpoint Reports, with verbal instructions rather than written.

Tailoring Simplified Projects

PRINCE2 helps you plan and control projects better, faster and easier

Remember: Activity arrows within each Process show a suggested sequence –
not a mandatory one. Each Activity is like a checklist – think about each, but you do not have to do each of them!
Ask yourself “is this change sensible for my project?”

It may make sense to shift some activities (or parts of them) from one process to another. But, you will want to do most activities – just decide the degree …

You could overlap the Initiation stage with the first delivery stage, and for a single delivery stage, the Project Plan will also be the Stage Plan

For “open-end” projects such as R&D, creating a Project Plan may not add any value – you may just need Stage Plans!

PRINCE2 Two Simple Stages

Do not overcomplicate things here! An example of such a project may just be:

There will be more focus on scope tolerances than time tolerances, and so measuring progress is done for scope since timeboxes will be fixed for time, and also cost.

Using Commercial Suppliers

A balance is needed to ensure that both the customer and suppliers Business Cases are supported, so consider the following:

• Plan up front in detail what contracts you need and the detail in each
• Use the WBS to divide the product deliverables into contract groups
• Involve legal/purchasing early so they understand the project contract tailoring
• Ensure all key documents are visible to all parties – use a nondisclosure agreement if needed
• Project Board-level discussions may need to take place without the Senior Supplier present, possibly for commercial-in-confidence matters
• Integrate your suppliers’ working practices with your own and embed in PRINCE2 Approach documents

Remember that PRINCE2 is based on a Customer/Supplier environment

Change budgets and contracts

Consider the following aspects:

• Using Lifecycle Models
• First, align these with PRINCE2 management stages
• Then adjust tolerances to suit model such as wide, narrow for time, cost, quality, scope, etc,
• Next, integrate any lifecycle specialist roles into the project management team structure
• Then use PRINCE2 for the management products, and create any appropriate specialist management Product Descriptions
• Finally, provide linkages to any specialist product development processes into the Managing Product Delivery processes

Evolving Projects

There are many instances where evolving projects are needed. Examples here would be a research and development project or carrying out a feasibility study.

Be aware, that for such projects, the specifications, business case and plans will need to evolve. Getting management buy-in for this is vital.

Tailoring the Starting Up a Project process

Some examples are:

• The mandate is an email
• There maybe no need for a project manager yet
• A single document project brief is all that is needed – simply refined from project mandate
• Just an outline business case explaining why the project is needed
• The project product description may just contain desired outcomes
• All deliverables and initiation stage plan, may be discussed and agreed in a single meeting

When using agile, if the project is run by the supplier, starting up a project may take place pre-contract, and if the project is part of a programme, then starting up a project, and the mandate, mainly driven by the program manager

The Key PRINCE2 tailoring areas

These are:

• Processes may be combined or adapted
• Application of themes are done using appropriate additional techniques
• Roles can be combined or split, accountability must be maintained with no conflict of interest
• Management products may be combined or split
• The management products can be documents, slide decks, wall charts, or data held on IT systems
• Terminology may be changed to serve your operational and support policies

Tailoring The Project Initiation Documentation

• The sections can be combined into a single document
• The PID may be a slide deck for simple project
• All the PID Approach documents may be combined into one
• You could combine risk and issue registers, or even add a change register
• You could have different names for documents
• You may need extra checks and inspections in some industries for example a large change register
• The Project Initiation documentation may be split into separate documents
• You may include the use of software tools, with industry or organizational methods
• Your project may be part of a programme – use/combine/modify their documentation?

Use of Agile

Product descriptions could be user stories, and you will use prototypes. There will be a higher level of uncertainty, so high-level planning only.

Third parties

Contracts must be signed before the Initiating a Project process is completed.

Tailoring the Risk Theme

As a minimum, you must use the five steps, and state how the project management team will identify and assess the risks, and all roles and responsibilities for risk management. The product management team needs to maintain some form of the risk register.

Scaling the Risk Theme

In agile or simple projects, the Risk Register might be a list on a whiteboard. The project manager could carry out most of the risk management activities in a small project. Commercial customer/supplier environments might not be appropriate to share commercially sensitive information

Different delivery approaches

Different delivery approaches could be waterfall and agile, and these may be used in a hybrid manner.

The number of management stages is flexible and depends on the scale, duration, and risk of a project.

How might the managing stage boundary process be adapted to different project contexts?

Consider:

• Different approaches for Small project
• Projects with external third party organisations
• A project operating within a programme environment

Tailoring products in managing a stage boundary

The stage plan could be included with the project plan for a single delivery stage.

Product descriptions. The project manager may not create these as others may have the requisite skills. In which case the project manager role would be to see that the product descriptions are defined and reviewed rigorously enough to make more planning to be undertaken with confidence.

The end-stage report. For a single delivery stage, an end-stage report is not needed as it will be covered within the end project report

Lessons log – this may be combined with the end-stage report

The Exception Plan might be held totally or partially within a planning tool

Using an agile approach

The managing stage boundaries process should not interrupt the natural flow of work using agile with releases and sprints synchronised within each management stage. In such a case managing stage boundaries provides an opportunity to assess the ongoing viability of the project as a whole and to decide what the priorities are for the next management stage

Stage boundary decisions particularly when funds are released may be taken at the role higher than the executive – in which case the Authorize a Stage or Exception Plan activity may be treated as a separate process
In a one delivery stage project will be no decisions requested for managing stage boundaries except if an exception plan is needed

Decisions need to happen quickly particularly when applying management by exception.
Reports and information flows are frequent and informal, with the project board possibly attending reviews and demonstrations to make decisions rather than waiting for a report

Tailoring the Controlling a Stage and Managing Product Delivery processes

Work packages. These may include specialist techniques and consider internal versus third party. The work package may just be used as a checklist.

The Highlight report. The frequency may change to the amount of stage risk, the need for additional information such as KPI’s and use in the form of wall charts or Kanban boards

The Issue report – may be combined with the issue register. Or you may want a customer risk register and a supplier risk register.

The Exception report may be configured in any acceptable format

The project manager may not have skills for creating work packages and so the role would be to ensure they are defined and reviewed.

The project manager may also act as a team manager and use work packages as a control for individual team members.

The Project manager may take on the project support role

Agile. There is a need for a more collaborative and facilitation role from the project manager.

Regular reviews and retrospectives and setting tolerances around scope and quality need to be considered.

A work package may contain several sprints. Progress information may be using daily stand-up with the project manager invited. Wall charts or information radiators can be used to show progress

From the supplier perspective, a work package may be a legally binding contract

The Team plan may be a subset of the stage plan. The team plan should be developed at the same time as the stage plan and not wait for the work package to be issued

The Checkpoint Report. Can be formal or informal or even done verbally. Could be captured in the Daily Log
The project manager may also undertake a team manager role, in which case there may be no need for checkpoint reports.

For agile projects, the interface would need to be collaborative and transparent. Progress information would be verbal or on an information radiator

Tailoring the closing a project process

For a simple project, the closing can be done quickly and informally, for example, all the above steps could take place in a single meeting. There may be no need to prepare for an end project report, rather, circulate the meeting minutes from the above meeting.

Even so, the project manager must ensure that all stakeholders are informed that the project is ending, and they are aware of any follow-on-actions. Sometimes the project team may retain responsibility for operating the products for a trial or warranty period before passing them to the client.

Closing an Agile project

Many of the activities described above may have already occurred by the time the project reaches its end, as the agile approach delivers the products into their operational environment over several iterations, also, benefits may have already been realised, and so planning post-project benefit reviews may not be needed.

Agile teams often carry out retrospectives at the end of each release so there is no need to write a lessons report – just some sort of formal project closure event.

If the project is part of a programme for the programme board will take responsibility for the Benefits Management Approach after the project. This role is typically called my business change manager. In cases of confidentiality, the end project report is mainly to be adapted with certain sections sent to a restricted audience

Change authority

There could be several levels of change authority if the project board delegates authority to approve changes and off-specifications. This may be due to the project board not having sufficient time or the knowledge and skills.

Change authorities are set up if needed within the initiation stage and the decision is documented in the change control approach.

Tailoring the PRINCE2 Change Theme

As a minimum, there must be a change control approach and define the roles and responsibilities for managing change. These must define how product baselines are created, maintained, and controlled. They should maintain some form of issue register and use any relevant lessons.

The change control approach will the to line with any organization change or issue related policies and procedures.

PRINCE2 Agile environments

The project management team should avoid over exactness when creating product descriptions, as this decreases the number of requests for change to the treaty formally. They should try to baseline only quality criteria that encapsulate the purpose of the product.

Any requests for change raised during a sprint must be dealt with speedily.

PRINCE2 Tailoring Managing a Stage Boundary

You may combine documents such as the end-stage report the end project report and the lessons report.
The work package and its product description may be a simple checklist Work Packages will change considerably depending upon whether using third party suppliers or internal resources.

For projects within programmes, they will probably be a programme wide approach to controlling the progress of the project

Do you want to pass your PRINCE2 Foundation and Practitioner Exams on the first try? Then check out our PRINCE2 Foundation and Practitioner Masterclass!