Topic 6 Transcript PDF

Skillsoft Course Transcript https://cdnlibrary.skillport.com/courseware/Content/cca/apj_29_a06_bs_...
Course Transcript
Course Overview
Read the Course Overview .
Tailoring PRINCE2® for Project Environments

1. Understanding Tailoring
2. Influences on Tailoring Projects
3. PRINCE2® Projects and Programmes
4. PRINCE2® Management Products
5. Project Ranges of Scale
6. Considerations for Tailoring Simple Projects
7. Commercial Customer/Supplier Considerations
8. Considerations for Multi-organization Projects
1 of 14 14/05/2019, 10:27
[Course title: Adopting PRINCE2® for your Project Environment (2017 Update). The presenter is Sue
Hopgood | MA (Hons), PGCE, Prince2, MSP, & APM Accredited Trainer. PRINCE2® is a registered
trade mark of AXELOS Ltd. Used under permission of AXELOS Ltd. All rights reserved.] Every
project, no matter how similar to others, is unique in its own way. And just as you unique are the
organizations and environment in which they are being conducted. In this course, you'll learn about
the ways that the PRINCE2® project management methodology can be adapted to suit both your
organization environment and the project type you are managing.
2 of 14 14/05/2019, 10:27
Learning Objective
After completing this topic, you should be able to
recognize characteristics of tailoring
1.
[Topic title: Understanding Tailoring.] Tailoring involves adapting the PRINCE2® methodology to both
external and project factors. External factors to consider could be any corporate standards that need
to be applied. While project factors would include items such as the scale of the project. For example,
if you had two projects, one simple and the other to build the world's tallest tower, you'd still follow
corporate standards in each case. But those for the tower could involve more in-depth work. And in
terms of themes, the risk theme would still be applied in the simple project. Just not to the same
extent or depth as with building the world's tallest tower.
PRINCE2® defines tailoring as "adapting a method or process to suit the situation in which it will be
used." (Quoted text Source is Managing Successful Projects with PRINCE2®. Copyright © AXELOS
Limited 2017. Reproduced under license from AXELOS. All rights reserved.) Tailoring is concerned
with the appropriate use of PRINCE2® on any given project. Ensuring that there is the correct amount
of planning, control, governance, and use of processes and themes. To put it simply, tailoring is done
by the project management team to adapt the method to the context of a specific project.
When tailoring, the project management team should focus on adapting themes through strategies
and controls. Incorporating context-appropriate terms and language. Revising product descriptions for
the management product. Revising role descriptions for PRINCE2® project roles, and adjusting
processes to match the focus.
A benefit to the PRINCE2® method of managing projects is that regardless of the project's scale,
complexity, geography, or culture. Or whether it is part of a program or is being managed as a stand-
alone project, the PRINCE2® methodology can be applied each and every time. You don't pick and
choose which elements of PRINCE2® to apply to your project. PRINCE2® is applied fully to help
ensure consistency and standardize your project's management. You can tailor how you apply certain
elements, though, based on the requirements of your project or environment.
Embedding is another element of adopting PRINCE2®. PRINCE2® describes embedding as "what

the organization needs to do to adopt PRINCE2® as its corporate project management method."
(Quoted text Source is Managing Successful Projects with PRINCE2®. Copyright © AXELOS Limited
2017. Reproduced under license from AXELOS. All rights reserved.) It's not a project-to-project
initiative. PRINCE2® becomes part of the organization's process for managing projects. When
embedding PRINCE2® at the organizational level, the focus should be on process responsibilities,
scaling roles, and guidance. For example, scorecards, standards such as templates and definitions,
training and development, integration with business processes, tools, and process assurance. It's
important to note that tailoring is different from embedding. It's done by the project management team
to adapt the method to the context of a specific project. The differences between embedding and
tailoring are further clarified by their contrasting focal points. When tailoring, the focus is on adapting
themes through the strategies and controls, incorporating specific terms and language. Revising the
product descriptions for the management products. Revising the role descriptions for the PRINCE2®
project roles. And adjusting the processes to match the adaptations.
3 of 14 14/05/2019, 10:27
4 of 14 14/05/2019, 10:27
Learning Objective
distinguish between environmental and project factors that influence PRINCE2®
tailoring
1.
[Topic title: Influences on Tailoring Projects.] Tailoring involves adapting the PRINCE2® project
management method to take into account both the unique external factors and project factors. The
goal is to apply the right level of project management. Various environmental and project factors affect
how PRINCE2® is tailored. PRINCE2® gives some examples of each of these types of factors,
though these are not exhaustive.
Environmental factors that affect PRINCE2® tailoring include the project environment, such as
whether it is multiorganization. Whether there is an external customer or supplier relationship. Existing
corporate standards to comply with. If the project is being managed within a program or stand alone.
And organization maturity. Other environmental factors that can have an effect on tailoring, include
terms and language that are being used already, geography, organization culture, and project priority.
Project factors that influence tailoring on the other hand include the project scale, solution complexity,
team maturity and the specific project type and life cycle. Keep in mind that you can tailor a project up
or down. Tailoring up refer to adding detailed documentation and strengthen process discipline for a
complex or high-risk project. In a simple low risk project, it may be sufficient to tailor down by offering
concise bullet point reporting formats and using a less formal process. PRINCE2® may also involve
tailoring in terms of language, management products, and processes. The method may need to be
adapted to incorporate the terms and language of the corporate or program organization that might be
different from your own. For example, if the corporate or program organization uses the term
investment case rather than business case. It might be appropriate to substitute the term within all of
the project's documentation to ensure a common and improved understanding.
The management products can and may need to be modified. You may also need to modify their
product descriptions, or provide a template for them. Everybody involved in the project should know
the purpose of each management product, its composition, and the quality criteria. For example, in a
commercial environment, the work package may need to include purchase order details and
accompanying terms and conditions. The PRINCE2® process activities may be combined or adapted.
For example, even in the case of a simple project, you still need to perform the starting up a project
process. But it can usually be handled in a less formal manner than in a complex project.
In summary, tailoring involves adapting the method to take into account both the unique external
factors and project factors. The goal is to apply the right level of project management. Environmental
factors can include multiorganization, external customer or supplier, corporate standards, if the project
is within a program, organization maturity, terms and language, geography, organization culture, and
the project priority. Project factors can include the project scale, solution complexity, team maturity,
and the specific project type and life cycle.
5 of 14 14/05/2019, 10:27
Learning Objective
distinguish between PRINCE2® projects and programmes
1.
[Topic title: PRINCE2® Projects and Programmes.] It's important to understand the difference
between a PRINCE2® project and a program.
A program is a temporary, flexible organization structure created to coordinate, direct, and oversee the
implementation of a set of related projects and activities. In order to deliver outcomes and benefits
related to the organization's strategic objectives. A program may have a life that spans several years.
A project, on the other hand, is a temporary organization created for the purpose of delivering one or
more business products according to an agreed upon business case. Projects are the means by
which we introduce change. They're temporary and typically involve a cross-functional team. They're
unique and can be risky because of the uncertainty they introduce.
So the distinction between projects and programs is that projects typically produce or change
something. Once they have achieved the objective, they are disbanded. The benefits of the
undertaking are likely to be accrued after the project is completed. Programs are broader, and their
goal is typically to help transform the organization as a whole. A program tends to have a lifespan that
covers the realization of the benefits of multiple projects, which could span many years. For example,
a car manufacturer may have a strategic goal to increase profits by 10% over the next five years. To
do this, they might start a program. This program could contain several projects. One might be to
design a new car that will hopefully result in more sales. Another project might be to improve the
marketing of their existing cars via new social media channels. Another project might be to reduce
head office costs by outsourcing their IT function. Each project will create different outputs. The car,
new marketing processes, and an outsourced IT function. Giving the organization new capability to
realize the benefit of increased profits. Projects don't have to be part of a program. They could be, and
often are, standalone. For example, a project to refurbish the meeting rooms at the car manufacturer's
head office. This project will deliver an output, refurbished meeting rooms. But they will not directly
contribute to the goal of increased profits. So it won't fit into the existing program.
In summary, a program is a temporary, flexible organization structure created to coordinate, direct,

and oversee the implementation of a set of related projects and activities. In order to deliver outcomes
and benefits related to the organization's strategic objectives. A program may have a life that spans
several years. A project, on the other hand, is a temporary organization created for the purpose of
delivering one or more business products according to an agreed upon business case. Projects are
the means by which we introduce change. They're temporary and typically involve a cross-functional
team.
6 of 14 14/05/2019, 10:27
Learning Objective
distinguish between the three types of management products in PRINCE2®
1.
[Topic title: PRINCE2® Management Products.] Management products are important tools used to
assist the project manager in a PRINCE2® project. Management products are those that are required
as part of managing the project and establishing and maintaining quality. The three types of
management products are baselines, records and reports. Within each category of management
products, there are many different types of products. Even though records and reports are not subject
to change control, they are subject to other aspects of control such as version control, safe storage,
and access rights. It's important to note that management products need not necessarily be
documents. They can be sets of information used and produced in PRINCE2® processes. They give
certain roles guidelines of operation so they can take action and/or make decisions based on the
information in management products.
Some types of management products exist at both the project and the program level, while others are
more specific to projects. For example, you need to decide whether there's going to be a single risk
register administered by the program for both the program level risks and all the risks for each project
within the program. Or whether each project should maintain its own risk register. This decision can
have important implications. If, for example, you decide that a project should maintain its own risk
register, its risk management approach should define how program level risks that are identified and
captured during the project work are promoted to the program risk register. Likewise, the program's
risk management approach should have a defined mechanism for project risks that are identified and
captured at the program level to be sent down to the project risk register.
Baseline management products are those that describe the nature of aspects of the project, and once
approved, are subject to change control. The majority of the baseline management products evolve in
the pre-project and initiation stage activities, then they're reviewed and possibly updated at the end of
each stage they progress through.
There are several baseline management products that could exist at both the project and program
level. These include the risk, change control, quality, and communication management approaches,
and the benefits management approach. Baseline management products that contain project specific
information, product descriptions, outline business case, project brief, project initiation documentation,
the project product description and work package.
Records of the ever changing management products that maintain information regarding project
progress such as configuration item records, daily log, issue register, lessons log, quality register and
risk register.
Within a program environment, it is very likely you would have program level records as well as
project level records. For example, each project manager would keep a daily log of issues and events
related to a specific project, but the program manager may well keep a daily log to capture significant
events for all the projects within the program.
And the third type of management product, reports, are the management products that provide a
7 of 14 14/05/2019, 10:27
snapshot of the status of certain aspects of the project such as the checkpoint report and stage report
and project report, lessons report and product status account.
In summary, management products are those that are required as part of managing the project and
establishing and maintaining quality. The three types of management product are baselines, records
and reports.
8 of 14 14/05/2019, 10:27
Learning Objective
distinguish between the three ranges of scale for projects
1.
[Topic title: Project Ranges of Scale.] It's all relative is a common saying. And it's an appropriate
saying when referring to the scale of projects, too. The scale of a project is relative to the size and
experience of the organization that's taking on the project. For example, for one organization, a
project with a budget of 10 million could be relatively simple and commonplace, based on their
experience. Whereas for another organization, it may be incredibly daunting. Scale isn't just about the
size of the project measured in terms of time, money, and people. It's also set in the context of the
project's complexity, risk, and importance. PRINCE2® provides some guidance on the different ranges
of scale for projects. The categories that PRINCE2® suggest include daunting, normal, and simple.
Daunting projects are high risk, costly, important, and highly visible. They can include multiple
organizations and use multi-disciplinary teams. They may also involve an international scale of work.
In daunting projects, PRINCE2®'s applied via multiple delivery stages. And there's typically an
extended project board with user and supplier groups reporting into the project board. Having team
managers and project support as unique and separate roles is likely in projects with this scale. The
project produces each of the individual management products recommended by PRINCE2®.
In comparison, a normal project could be expected to be medium risk, cost, importance, and visibility.
It's likely the project would involve a commercial customer supplier relationship, and work could be
performed at multiple sites. In projects with a normal scale, PRINCE2® would typically be applied in
one or more delivery stages. There would be a standard project board. Team managers and project
support would optionally operate as separate roles. Some the management products could be
combined. For example, there could be a project approaches management product. Instead of one
each for risk, change control, quality, and communication, or one register to hold issues and risks.
Finally, simple projects are low risk, cost, importance, and visibility. They usually include just a single
organization and are performed at a single site. PRINCE2® could be applied to simple projects in a
single delivery stage. And there's usually a simple project board with only one senior user and senior
supplier. The project manager would typically perform the team manager and maybe even project
support roles. Management products are usually combined. If an organization had a task to complete
that was of low risk, cost, and importance, and within one discipline on a single site. Then this would
not be considered a project by PRINCE2®. However, it could be delivered within the business as
usual operations using the PRINCE2® managing product delivery process. The task could be split
into work packages. Use product descriptions, logs, registers, and checkpoint reports. The person
creating the products in the task would act as a team manager. And report not to a project manager,
but to another manager in the organization, probably their line manager.
In summary, there are three ranges of scales for projects according to PRINCE2®. They are daunting,
normal, and simple.
9 of 14 14/05/2019, 10:27
Learning Objective
recognize best practices for tailoring simple projects for PRINCE2®
1.
[Topic title: Considerations for Tailoring Simple Projects.] If a company is working on a project they
consider simple based on their experience and the context of the project, PRINCE2® provides some
useful recommendations for consideration. It is important to look at the various elements of
PRINCE2® and examine the nature of the project. There is no fixed formula that tells you which
project elements can be relaxed in a simple project. Projects are unique, and vary infinitely in type and
style. With that said, though, even simple projects must adhere to the PRINCE2® principles, and all
things must still be applied if they're to be managed in alignment with PRINCE2®. It's in the manner
that themes, processes, and management products are used that PRINCE2® is tailored.
Of the seven PRINCE2® themes, the one most affected by simple projects is the organization theme.
Scaling the project management team is primarily about roles and function consolidation. Roles can
be combined, but shouldn't be eliminated. For example, as the executive and senior user roles are
both typically from the customer environment, these roles can often be combined. And because the
project manager is likely to be much closer to the project board than on larger, more complex projects.
Members of the project board are often in a better position to carry out their own project assurance,
rather than appointing another individual to fill that role. Also, with small teams, it may not be
necessary to appoint separate team managers. The project manager can take care of these
responsibilities. The project manager may also undertake the role of project support and be a team
member. In any situations where roles are being combined, though, the project manager should take
care to balance the effort of managing the project with the effort of doing any project work.
There are some minimum requirements for the other themes when tailoring simple projects as well.
Firstly, the business case. There must be some form of documented business justification. In addition,
for the plans theme, there should be product checklist documentation. The documentation should
include product descriptions, the key deliverables, and the simple plan of who is involved in producing,
reviewing, and approving products, together with the schedule of key milestones.
Another minimum requirement involves the quality theme. Quality levels required in the project and of
the products should be made clear. For the risk theme, there should be an analysis of the risks facing
the projects, actions that will be taken to implement risk responses, and communicating risk status via
checkpoints and highlight reports.
For the change theme, there should be a simple method of controlling changes to the project, and
managing the configuration of the products being delivered.
And finally, for the progress theme, some form of agreed controls and reporting requirements need to
be put in place, whether they're written or oral.
Though it may be tempting, don't skip the starting up a project process. All processes remain relevant
in simple projects. However, the starting up a project process can usually be handled in a less formal
manner. The executive and project manager should avoid the temptation to bypass it altogether. In
some cases, it may be appropriate to combine the starting up a project and initiating a project
10 of 14 14/05/2019, 10:27
processes. When combining these two processes, you could create the project initiation
documentation straight from the mandate, and skip the production of a project brief. Selecting a format
that reduces project management effort is a way in which management products can be tailored for
small projects. For example, making a decision to have some or all reports orally or have a verbal
exchange of information and decisions instead of formal documents. Another suggestion for tailoring a
simple project is to create documents that include multiple management products. It's possible to
manage a small PRINCE2® project with just three sets of documentation, project initiation
documentation, daily logs, and end project reports.
In addition to altering and combining, there are a few management products that you could, if it makes
sense, eliminate from your small project. If there is only one delivery stage in your project, then the
stage plan details can be included in the project plan. If there are no team managers, there may be no
need for checkpoint reports. Or the project manager may request individual team members to provide
them. 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. It's up to the discretion of the project
manager, though, because work packages can act as a control for individual team members, even in
the case of simple projects. 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 typically necessary, rather than end-stage reports.
And finally, if details of the issue are adequately captured in the issue register or the daily log, there
may be no need for an issue report.
In summary, while there is no fixed formula that tells you which project elements can be relaxed in a
simple project, it is important to look at the various elements of PRINCE2® and examine the nature of
the project. While there are many elements you can adapt to your needs, the PRINCE2® principles
and themes must still be applied. Of the seven PRINCE2® themes, the one most affected by simple
projects is the organization theme. When you tailor simple projects, there are some minimum
requirements that are altering other themes as well. You can also tailor a simple project by creating
documents that include multiple management products. You can manage a small PRINCE2® project
with the project initiation documentation, daily log, and end project report. Some of the management
products that you may not need in small projects are checkpoint reports, work packages, and stage
reports and issue reports.
11 of 14 14/05/2019, 10:27
Learning Objective
identify considerations to make when tailoring projects in which the
customer/supplier relationship is commercial
1.
[Topic title: Commercial Customer/Supplier Considerations.] PRINCE2® is based on a
customer/supplier environment. It assumes that there will be a customer who will specify the desired
result. That customer is, in fact, paying for the appropriate end result. There's also a supplier who will
provide the resources and skills to deliver that result. But what about a project where the relationship
is a commercial one? For example, a project in which a school pays a building contractor to build a
new gymnasium ready for the next academic year. If the relationship between the customer and
suppliers 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 a project. Two management
systems, including project management methods. Two governance structures and two corporate
cultures.
In the commercial context, there are at least two business cases. The customer's business case and
the supplier's business case. To ensure project success, both must demonstrate continued business
justification. On the road to completion, if the project is no longer viable, desirable, or achievable for
one party, then the project will likely encounter serious difficulty. And the potential for failure is
dramatically increased. Both parties must be engaged to ensure success.
One of the key decisions to make in a commercial customer/supplier relationship is roles. Who should
take the role of a senior supplier? And the project manager role also has to be considered. In
PRINCE2®, the project manager will normally come from the customer organization. With the
supplier's project managers fulfilling the role of team managers for the project. Remember, there can
only be one project manager. Even though the team managers may be called project managers in the
supplier's organization, the role titles and job titles should not be confused. The quality management
approach will define whether the project will conform to either the customer's or supplier's quality
management systems or a combination of them.
Another consideration is that in a commercial context, there may be a need for more than one risk
register. As some project risks could be unique to only one party, and one organization may not want
to share their risk information with the other. This makes using the joint risk register a good idea. But
care should be taken as to whose risk it really is and the risk owner appointed accordingly. The
change control procedure in the change control approach, and any provisions for changes in the
contract, must also be aligned. If a change budget is used, it will need to be aligned to the customer's
purchasing procedures and the supplier's business approval procedures. From a supplier's
perspective, the key changes to the processes will be starting up a project process and the initiating a
project process.
The starting up a project process will take place pre-contract and is typically initiated in response to
the customer's request for a proposal. Some of the initiating a project process activities will be pre-
contract. As the supplier needs to formulate the strategies, plans, and controls in order to assess the
viability and desirability of the sale. They also need to consider the associated costs and prices of the
12 of 14 14/05/2019, 10:27
solution being proposed. Completion of the initiating a project process doesn't happen until contract
negotiation has concluded and the customer's project board authorizes the project. Contract
negotiation should be managed under change control.
Another requirement is the aligning of the supplier's business approval processes with the starting up
a project process qualifying the opportunity. And the initiating the project process approving the
proposal. There are a lot of questions that need answers ahead of time. Or at least guidelines for
resolving such questions that are agreeable to all parties. The frequency, format, and formality of
reviewing and reporting must be aligned to the needs of both organizations' governance requirements.
For example, team managers may need to produce two checkpoint reports. One for the customer's
project manager and one for the supplier's management. When working with an internal supplier, a
work package is an instructional document that's passed from the project manager to the internal
team manager who then carries out the work. In this context, the work package is a control document.
However, when the work is being done by an outside source, external to the project manager's
company. Then the work package takes on a legal nature as it becomes part of the body of the
contract between the supplier and customer organizations.
In summary, some of the key decisions in the commercial customer/supplier relationship are who will
be the senior supplier and who will be the project manager. The customer/supplier environment
affects tailoring PRINCE2® processes and management products. The supplier has to consider
various aspects and perform various activities during the starting up a project and initiating a project
processes. During the project, you can work with internal or external suppliers. If you are working with
internal suppliers, a work package, which is a control document, is passed from the project manager
to the internal team manager who carries out the work. If you are working with external suppliers, a
work package may take the form of a legally binding contract.
13 of 14 14/05/2019, 10:27
Learning Objective
identify considerations to make for multi-organization projects
1.
[Topic title: Considerations for Multi-organization Projects.] Increasingly, the organizational context of
projects is becoming more complex. Rather than simple customer/supplier relationships involving two
organizations, projects are being instigated that involve multiple organizations. There may be one
main commissioning authority or one main customer. Or there may be several customers. Likewise,
there may be several supplier organizations. Some examples of multi-organization projects include
joint ventures, collaborative research, inter-departmental projects, and partnerships.
In the multi-organization environment, there is increased risk. And a greater chance of project failure.
One potential reason for greater risk in multi-organization projects is the fact that there are likely
several owners in such a project scenario. And 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. There are also many more lines of communication
and potential for misunderstanding when more people are involved in a project. It takes a thorough
and common understanding of the goals of the project to be successful. Everybody needs to be
working towards a common goal.
Be prepared to deal with complexity when using PRINCE2® in multi-organizational projects. And
when making arrangements for working with them. A case in point is the project board role. Project
boards can have too many members than is practical for making effective decisions. If no one party
has authority over the others, a consensus has to be built on each decision. Large project boards that
must get a consensus on issues work slowly. And the pace of the project is slowed accordingly.
Project managers may be tempted to overstep their authority when making decisions so as to bypass
the slow decision process. If it gets too difficult to manage, and decisions can't be made effectively,
consideration should be given to running such projects as programs. That way, it will be possible to
adopt the organizational structures of program management to assist with benefits management and
stakeholder engagement.
In summary, increasingly, the organizational context of projects is becoming more complex. And
involves several organizations. These are called multi-organization projects. In such an environment,
risks are greater. And the chances of project failure rise as well. It is, therefore, important to have a
common understanding of the goals of the project to ensure that everybody works towards that
common goal.
© 2017 Skillsoft Ireland Limited
14 of 14 14/05/2019, 10:27

Topic 6 Transcript PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Topic 6 Transcript PDF

Uploaded by

Copyright:

Available Formats

Skillsoft Course Transcript https://cdnlibrary.skillport.com/courseware/Content/cca/apj_29_a06_bs_...

Tailoring PRINCE2® for Project Environments

2. Influences on Tailoring Projects

3. PRINCE2® Projects and Programmes

4. PRINCE2® Management Products

5. Project Ranges of Scale

6. Considerations for Tailoring Simple Projects

7. Commercial Customer/Supplier Considerations

8. Considerations for Multi-organization Projects

Embedding is another element of adopting PRINCE2®. PRINCE2® describes embedding as "what

In summary, a program is a temporary, flexible organization structure created to coordinate, direct,

© 2017 Skillsoft Ireland Limited

You might also like