Notes from PDF Flashcards
1
Q
Who is Prince 2 relevant to?
A
The PRINCE2® qualification is intended for project managers and aspiring project
managers.
It is also relevant to other key staff involved in the design, development and delivery of
projects, including project board members, team managers, project assurance, project support, and
operational line managers/staff.
2
Q
The definition and characteristics of a project
Project: \
A
A temporary organization that is created for the purpose of delivering one or more business
products according to an agreed business case.
3
Q
Characteristics of a project that distinguish project work from business as usual:
A
- Change Projects are the means by which we introduce change.
- Temporary As the definition of a project states, projects are temporary in nature.
- Cross-functional A project involves a team of people with different skills working together (on a
temporary basis) to introduce a change that will impact others outside the team. - Unique Every project is unique.
4
Q
The six aspects of project performance to be managed
A
- Costs The degree of permissible overspend or underspend against an agreed budget.
- Timescales The degree to which a project is permitted to deliver later or earlier than an agreed
target completion date. - Quality How much something can vary from agreed quality criteria.
- Scope Permissible variation of the plan’s products.
- Benefits The degree to which it is permissible to under-deliver or over-deliver benefits (realized
or estimated). - Risk Limits on the plan’s aggregated risks.
5
Q
- PRINCE2 principles: The principles are the guiding obligations and good practices which
determine whether the project is genuinely being managed using PRINCE2 business case:
A
- continued business justification
- learn from experience
- defined roles and responsibilities
- manage by stages
- manage by exception
- focus on products
- tailor to suit the project.
6
Q
- PRINCE2 themes: The themes describe aspects of project management that must be
addressed continually and in parallel throughout the project.
A
- organization
- quality
- plans
- risk
- change
- progress.
7
Q
- PRINCE2 processes: The seven processes describe a progression from the pre-project activity
of getting started, through the stages of the project life cycle, to the final act of project closure:
A
- starting up a project
- directing a project
- initiating a project
- controlling a project
- managing product delivery
- managing a stage boundary
- closing a project.
8
Q
- The project environment:
A
Organizations often want a consistent approach to managing projects and tailor
PRINCE2 to create their own project management method.
9
Q
What makes a project a PRINCE2 project?
For a project to be a ‘PRINCE2 project’, as a minimum it must be possible to demonstrate that it:
A
- is applying PRINCE2 principles
- is meeting the minimum requirements set out in the PRINCE2 themes
- has project processes that satisfy the purpose and objectives of the PRINCE2 processes
- is either using PRINCE2 recommended techniques or using alternative, equivalent techniques.
10
Q
The benefits of PRINCE2 for an individual is that the individual will:
A
- gain a globally recognized certification
- know how to start, manage the steps, and close a project
- learn common project management terminology
- know how to structure a project
- improve career prospects
- improve standing within their organization
- clearly understand their role as project manager
11
Q
The customer/supplier context on which PRINCE2 is based
A
PRINCE2 assumes that there will be a customer who will specify the desired result and (usually) pay
for the project, and a supplier who will provide the resources and skills to deliver that result.
Projects can exist within many contexts; they may be stand-alone (with their own business case and
justification) or they may be part of a programme or wider portfolio. Figure 2.2 shows how projects
may fit within a programme and portfolio context. In addition, projects may be wholly managed within the commissioning organization or be part of a commercial relationship.
12
Q
The PRINCE2 principle of continued business justification is that for all projects:
A
- there is a justifiable reason for starting the project.
- that justification is recorded and approved.
- the justification remains valid, and is revalidated, throughout the life of the project.
13
Q
The PRINCE2 principle of learn from experience is that learning from experience takes place
throughout a PRINCE2 project, including:
A
- when starting a project
- as the project progresses
- as the project closes.
14
Q
The PRINCE2 principle of defined roles and responsibilities is that all projects have the
following primary stakeholders:
A
- ‘business’ sponsors who endorse the objectives and ensure that the business investment
- provides value for money.
- ‘users’ who, after the project is completed, will use the products to enable the organization to
- gain the expected benefits
- ‘suppliers’ who provide the resources and expertise required by the project (these may be
- internal or external)
15
Q
The PRINCE2 principle of manage by stages is that a
A
PRINCE2 project is planned, monitored
and controlled, management stage by management stage.
16
Q
The PRINCE2 principle of manage by exception is that
A
a PRINCE2 project has defined
tolerances for each project objective, to establish limits of delegated authority.
17
Q
The PRINCE2 principle of focus on products is that a
A
PRINCE2 project focuses on the definition
and delivery of products, in particular their quality requirements.
18
Q
The PRINCE2 principle of tailor to suit the project is that
A
PRINCE2 is tailored to suit the project
environment, size, complexity, importance, team capability and risk.
19
Q
The following aspects of PRINCE2 may be tailored:
\
A
- processes may be combined or adapted (e.g. by adding or combining activities
- themes can be applied using techniques that are appropriate to the project may be combined or split,
provided that accountability is maintained and there are no conflicts of interest - management products may be combined or split into any number of documents or data sources
- terminology may be changed to suit other standards or policies, provided it is applied consistently
20
Q
The purpose of the business case theme is to…
A
establish mechanisms to judge whether the
project is (and remains) desirable, viable and achievable as a means to support decision-making in its
(continued) Investment.
21
Q
Benefits management approach…
A
Defines the management actions that will be put in place to
ensure that the project’s outcomes are achieved and confirm that the project’s benefits are realized.
22
Q
PRINCE2’s requirements for the business case theme is that to be following PRINCE2, a
project must, as a minimum:
A
Desirable and viable? Does it outweigh the risks of doing so?
- create and maintain a business justification for the project; usually a business case
- review and update the business justification in response to decisions and events that might impact
desirability, viability or achievability of the project - define the management actions that will be put in place to ensure that the project’s outcomes are
achieved and confirm that the project’s benefits are realized - define and document the roles and responsibilities for the business case and benefits management.
23
Q
Output
A
Tangible or intangible specialist products
24
Q
Key concepts related to business justification:
A
- Output A specialist product that is handed over to a user (or users). Note that management products
are not outputs but are created solely for the purpose of managing the project. - Outcome The result of change, normally affecting real-world behaviour and/or circumstances.
Outcomes are desired when a change is conceived. They are achieved as a result of the activities
undertaken to effect the change. - Benefit The measurable improvement resulting from an outcome perceived as an
- advantage by one or more stakeholders.
- Dis-benefit A measurable decline resulting from an outcome perceived as negative by one
- or more stakeholders, which reduces one or more organizational objective(s).
25
Organization theme
The purpose of the organization theme is to define and establish the project’s structure of
accountability and responsibilities.
26
Levels of management
Corporate or Programme Management
Directing: Project Board
Managing: Project Manager
Delivering: Team Manager
27
Communication management approach
The purpose of the communication management approach is to facilitate engagement with
stakeholders through the establishment of a controlled and bidirectional flow of information.
28
For applying the organization theme, PRINCE2 requires that a project must, at a
minimum:
* define its organization structure and roles. This must minimally ensure that all of the responsibilities
in PRINCE2 role descriptions are fulfilled (PRINCE2 defined roles and responsibilities principle)
* document the rules for delegating change authority responsibilities, if required
* define its approach to communicating and engaging with stakeholders.
29
The roles and responsibilities of the project board are:
* being accountable to business, user and supplier interests for the success or failure of the project
* providing unified direction to the project
* delegating, using the PRINCE2 organizational structure and controls designed for this purpose
* facilitating integration of the project management team with the functional units of the participating
* corporate, programme management, or customer organizations
* providing the resources and authorizing the funds needed for successful completion of the project
* effective decision-making
* providing visible and sustained support for the project manager
* ensuring effective communication both within the project team and with external stakeholders
30
Stakeholders?
Anyone with an interest in the overall success of the project.
- Investors
- Members of an organization
31
External Stakeholders
Vendors
Suppliers
Customers
Community
32
The role and responsibilities of the executive.
The executive, supported by the senior user(s)
and senior supplier(s), is ultimately accountable for the project’s success and is the key decision
maker. The executive’s role is to ensure that the project is focused throughout its life on achieving
its objectives and delivering a product that will achieve the fore casted benefits. The executive has
to ensure that the project gives value for money, ensuring a cost-conscious approach to the project,
balancing the demands of the business, user, and supplier.
33
The role and responsibilities of the senior user.
To specify the needs of those (including
operations and maintenance services) who will use the project product for user liaison with the
project management team and for monitoring that the solution will meet those needs within the
constraints of the business case in terms of quality, functionality, and ease of use.
34
The role and responsibilities of the senior supplier.
To represent the interests of those
designing, developing, facilitating, procuring, and implementing the project product.
35
The role and responsibilities of project assurance
To monitor all aspects of the project’s
performance and products independently of the project manager. Project board members are
responsible for the aspects of the project assurance role aligned with their respective areas of
concern (business, user or supplier).
36
The role and responsibilities of the senior supplier.
To represent the interests of those
designing, developing, facilitating, procuring, and implementing the project product.
37
The role and responsibilities of the change authority.
Τo authorize requests for change or
off specifications. It is the project board’s responsibility to agree to each potential change before it
is implemented. The project board needs to decide, before the project moves out of the initiating
a project process, if it wishes to delegate some authority for approving or rejecting requests for
change or off-specifications. These delegated authorities must be written into the appropriate role
descriptions.
38
The role and responsibilities of the project manager.
The project manager is the single focus
for the day-to-day management of a project. This person has the authority to run the project on behalf
of the project board within the constraints laid down by the project board. The role of the project
manager must not be shared.
39
The role and responsibilities of the team manager:
The team manager’s primary responsibility
is to ensure production of those products allocated by the project manager. The team manager reports to, and takes direction from, the project manager. The team manager role may be assigned.
to the project manager or a separate person.
40
The role and responsibilities of project support:
Project support is the responsibility of the
project manager. If required, the project manager can delegate some of this work to a project
support role: this may include providing administrative services or advice and guidance on the use of
project management tools. It could also provide specialist functions to a project such as planning or
risk management. Unless performed by a corporate, programme management or customer function,
project support is typically responsible for administering change control. The role of project support
is not optional, but the allocation of a separate individual or group to carry out the required tasks is.
This role is the responsibility of the project manager. The project manager can delegate some of this
work.
41
Combining of roles
PRINCE2 allows roles to be combined within the following constraints:
* the executive and project manager roles cannot be combined
* there cannot be more than one executive or project manager
* the executive’s accountability for project success cannot be delegated
* the project board should not assign any project assurance roles to the project manager, team manager, or
project support.
When combining roles, the project board should consider any conflicts of responsibilities, whether
one person has the capacity to undertake the combined responsibilities, and whether any
bottlenecks might be created as a result. Also, it is not recommended to combine the roles of senior
user and senior supplier as this can create conflicts of interest for an individual.
42
Stakeholder
Stakeholder: Any individual, group, or organization that can affect, be affected by, or perceive itself
to be affected by an initiative (i.e. a programme, project, activity or risk).
43
The three principle project interests are:
1. Business The products of the project should meet a business need that justifies the
investment in the project. The project should also provide value for money. The business
viewpoint therefore should be represented to ensure that these two prerequisites exist before a
the project commences and remains in existence throughout the project.
2. User Individuals or groups for whom some or all of the following will apply:
* they will use the outputs of the project to realize the benefits
* they will operate, maintain or support the project’s outputs
* the outputs of the project will impact them
The user presence is needed to specify the desired outputs and ensure that the project
delivers them through the supplier.
3. Supplier Those who will provide the necessary skills and produce the project product. The
The supplier needs to understand all the relevant standards with which the output
(product) needs to comply, and the project may need to use both in-house and external supplier
teams to construct the project product.
44
Quality Theme
The purpose of the quality theme is to define and implement the means by which the project
will verify that products are fit for purpose.
The quality management approach is an approach defining the quality techniques and
standards to be applied, and the various responsibilities for achieving the required quality levels,during a project.
The quality register is a register containing summary details of all planned and completed quality
activities. The quality register is used by the project manager and project assurance as part of
reviewing progress.
45
PRINCE2 minimum requirements for applying the quality theme
To follow PRINCE2, a project must, as a minimum:
* define its quality management approach. This approach must minimally cover:
– the project’s approach to quality control
– the project’s approach to project assurance
– how the management of quality is communicated throughout the project lifecycle
– the roles and responsibilities for quality management (PRINCE2 defined roles and
responsibilities principle)
* specify explicit quality criteria for products in their product descriptions (PRINCE2 focus on
products principle)
* maintain records to provide evidence that the planned quality activities have been carried
out, and summarize those activities that are planned or have taken place in some form of
quality register
* specify the customer’s expectations and prioritized criteria for their project in the project
production description
* use lessons to inform quality planning, the definition of quality expectations and quality
criteria (PRINCE2 learn from experience principle).
46
Quality Planning
Quality planning is defining the project product and its components, with the respective quality
criteria, quality methods (including effort required for quality control and product approval) and
quality responsibilities of those involved. The purpose of quality planning is to provide a secure basis:
* to obtain agreement by the project board on the overall quality expectations, the products required
with their associated quality criteria (including corporate and other standards to
be observed), the means by which quality will be achieved and assessed and, ultimately, the
acceptance criteria by which the project product will be judged
* to communicate these agreements unambiguously so that all the project stakeholders have a
common understanding of what the project is setting out to achieve
* for control (i.e. establishing an effective baseline for the project’s quality controls, including the
quality tolerances) and a secure means of achieving products that are fit for purpose.
47
Quality Control
Quality control is the process of monitoring specific project results to determine whether
they comply with relevant standards and of identifying ways to eliminate causes of unsatisfactory
performance.
48
Quality Assurance
Quality assurance is a planned and systematic process which provides confidence that outputs will
meet their defined quality criteria when tested under quality control. It is carried out independently
of the project team. The process must comply with relevant corporate, programme management, or
customer standards and policies.
49
Project Assurance
Project assurance is the project board’s responsibility to assure itself that the project is being
conducted correctly. The project board members each have a specific area of focus for project
assurance, namely business assurance for the executive, user assurance for the senior user(s) and
supplier assurance for the senior supplier(s). Project assurance is therefore independent of the
project manager but not independent of the project.
50
Customers Quality expectations
Customer’s quality expectations is a statement about the quality expected from the project
product, captured in the project product description.
51
Acceptance Criteria
Acceptance criteria is a prioritized list of criteria that the project product must meet before the
customer will accept it (such as measurable definitions of the attributes required for the set of
products to be acceptable to key stakeholders).
52
The purpose of the plans theme is to...
...facilitate communication and control by defining the
means of delivering the products (the where and how, by whom, and estimating the when and how
much).
53
Plan
A detailed proposal for doing or achieving something which specifies the what, when, how, and
by whom it will be achieved.
54
Project Plan
A high level plan showing the major products of the project, when they will be
delivered, and at what cost. An initial project plan is presented as part of the PID. This is revised as
information on actual progress appears. It is a major control document for the project board to
measure actual progress against expectations.
55
PID
Project Initiation Document
56
Stage Plan
Stage plan: A detailed plan used as the basis for project management control throughout a
management stage.
57
Exception Plan
Exception plan: A plan that often follows an exception report. For a stage plan exception, it covers
the period from the present to the end of the current management stage. If the exception is at
project level, the project plan will be replaced.
58
Team Plan
Team plan: An optional level of plan used as the basis for team management control when
executing work packages.
59
PRINCE2 minimum requirements for applying the plans theme
To the following PRINCE2, a project must, as a minimum:
* ensure that plans enable the business case to be realized (PRINCE2 continued business justification
principle)
* have at least two management stages: an initiation stage and at least one further management stage.
The more complex and riskier a project, the more management stages that will be required (PRINCE2
manage by stages principle)
* produce a project plan for the project as a whole and a stage plan for each management
* stage (PRINCE2s manage by stages principle)
* use product-based planning for the project plan, stage plans, and exception plans.
It may be optionally used for team plans. PRINCE2 recommends the steps shown in Figure
9.2 for product-based planning although alternative approaches may be used. PRINCE2
recommends the steps shown in Figure 9.6 for defining and analysing the products to produce
a product breakdown structure, although alternative approaches may be used
* produce specific plans for managing exceptions (PRINCE2 manage by exception principle)
* define the roles and responsibilities for planning (PRINCE2 defined roles and responsibilities
principle)
* use lessons to inform planning (PRINCE2 learn from experience principle).
60
Risk
The purpose of the risk theme is to identify, assess, and control uncertainty and, as a result,
improve the ability of the project to succeed.
Risk is an uncertain event or set of events that, should it occur, will have an effect on the
achievement of objectives. A risk is measured by a combination of the probability of a perceived
threat or opportunity occurring, and the magnitude of its impact on objectives.
Risk budget is a sum of money to fund specific management responses to the project’s threats and
opportunities (for example to cover the costs of any contingent plans should a risk materialize).
The risk budget is based on the aggregate cost of all the project’s planned risk responses.
61
The risk management approach
The risk management approach describes how risk will be managed on the project. This
includes the specific processes, procedures, techniques, standards and responsibilities to be applied.
62
The Risk Register
The risk register provides a record of identified risks relating to the project, including their
status and history. It is used to capture and maintain information on all the identified threats and
opportunities relating to the project.
63
PRINCE2 minimum requirements for applying the risk theme
To be following PRINCE2, a project must, as a minimum:
* define its risk management approach, which must minimally cover
o how risks are identified and assessed, how risk management responses are planned and
implemented, and how the management of risk is communicated throughout the project life-cycle
o assessing whether identified risks might have a material impact on the business justification of the
project (PRINCE2 continued business justification principle)
o the roles and responsibilities for risk management (PRINCE2 defined roles and responsibilities
principle)
* maintain some form of risk register to record identified risks and decisions relating to their analysis,
management, and review
* ensure that project risks are identified, assessed, managed, and reviewed throughout the project life
cycle
* use lessons to inform risk identification and management (PRINCE2 learn from experience principle).
64
Threat
An uncertain event that could have a negative impact on objectives or benefits.
65
Oppurtunity
For uncertain events that would have a positive impact on objectives.
66
Risk Response
Risk response: Actions that may be taken to bring a situation to a level where exposure to risk is
acceptable to the organization.
* Avoid a threat/exploit an opportunity.
* Reduce a threat/enhance an opportunity.
* Transfer the risk (threat or opportunity).
* Share the risk (threat or opportunity).
* Accept the risk (threat or opportunity).
* Prepare contingent plans (threat or opportunity).
67
Risk owner
A named individual who is responsible for the management, monitoring, and control
of all aspects of a particular risk assigned to them, including the implementation of the selected
responses to address the threats or to maximize the opportunities.
e.g....
Technical Risk Owner
Market Risk Owner
Financial Risk Owner
Stakeholder Risk Owner
Safety Officer
Human Resource Manager
68
Risk actionee
A nominated owner of an action to address a risk. Some actions may not be within
the remit of the risk owner to control explicitly; in that situation there should be a nominated owner
of the action to address the risk. He or she will need to keep the risk owner apprised of the situation.
In many cases, the risk owner and risk actionee are likely to be the same person. The risk owner
should be the person most capable of managing the risk. Allocating too many risks to any one
individual should be avoided.
69
Risk Cause
The source of the risk (the event or situation that gives rise to the risk). These are often
referred to as risk drivers. They are not risks in themselves, but the potential trigger points for risk.
These may be either internal or external to the project.
70
Risk Event
The area of uncertainty in terms of the threat or the opportunity.
71
Risk Effect
The effect the risk can have on the project/organization.
72
Risk Impact
The impact(s) that the risk would have on the project objectives should the risk
materialize.
73
Risk Probability
How likely the risk is to happen.
74
Risk Proximity
The time factor of risk (i.e. when the risk may occur). The impact of a risk may vary in
severity depending on when the risk occurs.
75
The recommended risk management procedure
1. Identify Context and risks
2. Assess Estimate and evaluate
3. Plan
4. Implement
5. Communicate The outputs of any of the other steps may need to be communicated to stakeholders at any
point in the process.
76
Change
The purpose of the change theme is to identify, assess, and control any potential and approved
changes to the project baselines.
A change budget is a sum of money that the customer and supplier agree will be used to fund the
cost of requests for change, and possibly also their analysis costs.
The change control approach identifies how and by whom the project’s products will be
controlled and protected.
Configuration item record A record that describes the status, version, and variant of a
configuration item and any details of important relationships between them.
Issue report Contains the description, impact assessment, and recommendations for a request for
change, off-specification, or a problem/concern.
Product status account Provides a snapshot of the status of products within the project,
management stage or a particular area of the project
77
PRINCE2 minimum requirements for applying the change theme
To be following PRINCE2, a project must, as a minimum:
* define its change control approach. This approach must minimally cover:
– how issues are identified and managed
– assessing whether identified issues might have a material impact on the business
justification of the project (PRINCE2 continued business justification principle)
– the roles and responsibilities for change control (PRINCE2 defined roles and
responsibilities principle), including a defined change authority
* define how product baselines are created, maintained, and controlled
* maintain some form of issue register to record identified issues and decisions relating to their
analysis, management, and review
* ensure that project issues are captured, assessed, managed, and reviewed throughout the
project life cycle
* use lessons to inform issue identification and management (PRINCE2 learn from experience
principle).
78
The recommended issue and change control procedure
* Capture Determine issue type and severity/priority, register/log the issue.
* Assess Assess issue’s impact on project objectives/business case and project risk profile,
check severity/priority.
* Propose Identify, evaluate, and recommend options.
* Decide Escalate issue beyond delegated authority, approve, reject, or defer recommended
option
* Implement Take corrective action, update records and plans.
79
The purpose of the progress theme is to...
* establish mechanisms to monitor and compare actual achievements against those planned
* provide a forecast for the project’s objectives and continued viability
* control any unacceptable deviations.
80
Progress theme
Daily Log
Daily log Used to record informal issues, required actions, or significant events not captured by
other PRINCE2 registers or logs. It can act as a project diary for the project manager. It can also
be used as a repository for issues and risks during the starting up of a project process if the other
registers have not been set up.
81
Progress
Lesson Log
Lessons log Used as a project repository for lessons that apply to this project or future projects.
82
Lesson Report
Lessons report Used to support the lessons log if more information is required. It can be used to
pass on any lessons that can be usefully applied to other projects.
83
Progress
Work Package
The set of information relevant to the creation of one or more products. It will
contain a description of the work, the product description(s), details of any constraints on production,
and confirmation of the agreement between the project manager and the person or team manager
who is to implement the work package that the work can be done within the constraints.
84
End stage report
A report given by the project manager to the project board at the end of each
management stage of the project. This provides information about the project’s performance during
the management stage and the project status at the management stage end.
85
End project report
A report given by the project manager to the project board, confirming the
handover of all products. It provides an updated business case and an assessment of how well the
project has done against the original PID.
86
Checkpoint report
A progress report of the information gathered at a checkpoint, which is given
by a team to the project manager and which provides reporting data as defined in the work package.
87
Highlight reportss.
A time-driven report from the project manager to the project board on
management stage progress
88
Exception report
A description of the exception situation, its impact, options, recommendation,
and impact of the recommendation. This report is prepared by the project manager for the project
board.
89
PRINCE2 requirements for the progress theme
To be following PRINCE2, a project must, as a minimum:
* define its approach to controlling progress in the PID
* be managed by stages (PRINCE2 manage by stages principle)
* set tolerances and be managed by exception against them (PRINCE2 manage by exception
principle)
* review the business justification when exceptions are raised (PRINCE2 continued business
justification principle)
* learn lessons (PRINCE2 learn from experience principle).
90
Tollerances
Tolerances are the permissible deviation above and below a plan’s target for cost and time without
escalating the deviation to the next level of management. There may also be tolerances for quality,
scope, benefits, and risk.
91
Tolerances are set against six aspects of performance for the respective level of the plan:
* Cost The degree of permissible overspending or underspend against an agreed budget
* Time The degree to which a project is permitted to deliver later or earlier than an agreed
target completion date
* Quality How much something can vary from agreed quality criteria.
* Scope Permissible variation of the plan’s products. For example, a project might be required
to deliver all of the must do, ‘mandatory’ requirements but be permitted to deliver only 50 per
cent or more of its should do, ‘desirable’ requirements
* Benefits The degree to which it is permissible to under-deliver or over-deliver benefits
(realized or estimated).
* Risk Limits on the plan’s aggregated risks.
92
Exceptions
Exceptions are situations where it can be forecast that there will be a deviation beyond the
tolerance levels agreed between the project manager and the project board (or between the project
board and corporate, programme management, or the customer).
93
Project Processes
The purpose of the starting up a project process is to ensure that the prerequisites for
initiating a project are in place by answering the question: Do we have a viable and worthwhile
project? The decision to start the project must be explicit; the activities from starting up a project
happen before this decision.
94
Project Breif
Used to provide a full and firm foundation for the initiation of the project and is
created in the starting up a project process.
95
The objective of the starting up a project process is...
* there is a business justification for initiating the project (documented in an outline business case)
* all the necessary authorities exist for initiating the project
* sufficient information is available to define and confirm the scope of the project (in the project brief)
* the various ways the project can be delivered are evaluated and a project approach selected
* individuals are appointed who will undertake the work required in project initiation and/or will take
significant project management roles in the project.
* the work required for project initiation is planned (documented in a stage plan)
* time is not wasted initiating a project based on unsound assumptions regarding the project’s scope,
timescales, acceptance criteria, and constraints.
96
PID
Project initiation documentation A compilation of all the documentation developed during the
The initiation that will be used to gain project board approval to proceed.
97
The purpose of directing a project process
The purpose of directing a project process is to enable the project board to be
accountable for the project’s success by making key decisions and exercising overall control while
delegating day-to-day management of the project to the project manager.
98
The objective of directing a project process is to ensure that:
* there is authority to initiate the project
* there is authority to deliver the project product
* management direction and control are provided throughout the project’s life
* the project remains viable
* corporate, programme management or the customer has an interface to the project
* there is authority to close the project
* plans for realizing the post-project benefits are managed and reviewed.
99
The purpose of initiating a project process.....
is to establish solid foundations for the project,
enabling the organization to understand the work that needs to be done to deliver the project
product before committing to a significant spend.
100
The objective of initiating a project process is to ensure that there is a common
understanding of:
* the reasons for doing the project, the benefits expected, and the associated risks
* the scope of what is to be done and the products to be delivered
* how and when the project product will be delivered and at what cost
* who is to be involved in the project decision-making
* how the quality required will be achieved
* how baselines will be established and controlled
* how risks, issues and changes will be identified, assessed, and controlled
* how progress will be monitored and controlled
* who needs information, in what format, and at what time
* how the corporate, programme management, or customer method will be tailored to suit the
project.
101
The purpose of controlling a stage process is to....
..... assign work to be done, monitor such
work, deal with issues, report progress to the project board, and take corrective actions to ensure
that the management stage remains within tolerance.
The objective of controlling a stage process is to ensure that:
* attention is focused on the delivery of the management stage’s products; Any movement away
from the direction and products agreed upon at the start of the management stage is monitored to
avoid uncontrolled change and loss of focus
* risks and issues are kept under control
* the business case is kept under review
* the agreed products for the management stage are delivered to stated quality standards, within cost,
effort, and time agreed, and ultimately in support of the achievement of the defined benefits
* the project management team is focused on delivery within the tolerances laid down.
102
The purpose of the managing product delivery process is to ....
control the link between the
project manager and the team manager(s), by agreeing on the requirements for acceptance, execution.
and delivery
103
The objective of the managing product delivery process is to ensure that:
* work on products allocated to the team is authorized and agreed
* team managers, team members, and suppliers are clear as to what is to be produced and
what is the expected effort, cost, or timescales
* the planned products are delivered to expectations and within tolerance
* accurate progress information is provided to the project manager at an agreed frequency to ensure expectations are managed
104
The purpose of the managing a stage boundary process is to enable the project manager to provide the
project board with sufficient information to be able to:
* review the success of the current management stage
* approve the next stage plan
* review the updated project plan
* confirm continued business justification and acceptability of the risks.
Therefore, the process should be executed at, or close to, the end of each management stage.
105
The objective of the managing a stage boundary process is to...
* assure the project board that all products in the stage plan for the current management stage have been
completed and approved
* prepare the stage plan for the next management stage
* review and, if necessary, update the PID; in particular the business case, project plan, project approaches,
project management team structure and role descriptions
* provide the information needed for the project board to assess the continuing viability of the project
* record any information or lessons that can help later management stages of this project and/ or other
projects
* request authorization to start the next management stage.
For exceptions, the objectives of the managing a stage boundary process are to:
* review and, if necessary, update the PID; in particular the customer’s quality expectations, project
approaches and controls, and role descriptions
* provide the information needed for the project board to assess the continuing viability of the project
* prepare an exception plan as directed by the project board
* seek approval to replace the project plan or stage plan for the current management stage with the
exception plan.
106
The purpose of the closing a project process ...
....is to provide a fixed point at which acceptance
of the project product is confirmed, and to recognize that objectives set out in the original PID have
been achieved (or approved changes to the objectives have been achieved), or that the project has
nothing more to contribute.
107
The objective of the closing a project process is to:
* verify user acceptance of the project product
* ensure that the host site is able to support the products when the project is disbanded
* review the performance of the project against its baselines
* assess any benefits that have already been realized and update the benefits management
approach to include any post-project benefit reviews
* ensure that provision has been made to address all open issues and risks, with follow-on
action recommendations
