Project Management

Project management
Project management is the ensemble of activities (such as tasks) concerned with successfully
achieving a set of goals. This includes planning, scheduling and maintaining progress of the activities
that comprise the project. Reduced to its simplest project management is the discipline of
maintaining the risk of failure at as low a value as necessary over the lifetime of the project. Risk of
failure arises primarily from the presence of uncertainty at all stages of a project.

An alternate point of view is that project management is the discipline of defining and achieving
targets while optimizing the use of resources (time, money, people, space, etc).

Project management is quite often the province and responsibility of an individual project manager.
This individual seldom participates directly in the activities that produce the end result, but rather
strives to maintain the progress and productive mutual interaction of various parties in such a way
that overall risk of failure is reduced.

What is a project?

A project could literally be as simple as making breakfast, but in the context of the practice of
project management a project is best defined as an undertaking with a discrete start, a discrete finish,
and some complexity. Compare this to, say, a manufacturing line, which is intended to be a
continuous process without a planned end.

Typical projects might include the engineering and construction of a building, or the design, coding,
testing and documentation of a computer software program, or development of the science and
clinical testing of a new drug. The duration of a project is the time from its start to its completion,
which can take days, weeks, months or even years.

Approaches

Generally, there are two approaches that can be taken to project management today. The "traditional"
approach identifies a sequence of steps to be completed. This contrasts with the agile software
development approach in which the project is seen as relatively small tasks rather than a complete
process. The objective of this approach is to impose as little overhead as possible in the form of
rationale, justification, documentation, reporting, meetings, and permission.

The traditional approach

In the traditional approach, we can distinguish 5 stages in the development of a project:

1. project initiation
2. project planning
3. project production
4. project monitoring
5. project completion

Not all projects will visit every stage as projects can be terminated before they reach completion.
Some projects probably don't have the planning and/or the monitoring. Some projects will go
through steps 2, 3 and 4 multiple times.

Many industries utilize variations on these stages. For example, in bricks and mortar architectural
design, projects typically progress through stages like Pre-Planning, Conceptual Design, Schematic
Design, Design Development, Construction Drawings (or Contract Documents), and Construction
NH 2
Administration. While the names may differ from industry to industry, the actual stages typically
follow common steps to problem solving--defining the problem, weighing options, choosing a path,
implementation and evaluation.

Project management tries to gain control over four variables:

• time
• cost
• quality
• scope (In project management, scope is the sum total of all projects products and their
features.)

For example, the scope of a variable refers to where in the program the variable can be accessed
and/or modified. For a function, to where the function can be called, and so on.

Common scope levels:

• global scope: visible from the entire program

• file scope: visible from a single source file.
• local scope: visible only from the local function or block where the name was declared.

Scope is usually hierarchical: a variable declared at local scope (for example, as a local variable
inside a function) supersedes the same variable declared at global scope. All references to this
variable inside the function will manipulate the locally-defined variable. Outside the function, they
will manipulate the globally-defined variable.

Because of this automatic scope handling, careful management of variable, class and function names
should be a requirement for any non-trivial program. It is considered good programming practice to
make variables as narrow a scope as feasible so that different parts of your program do not
accidentally interact with each other by modifying each other's variables. This also prevents Action
at a distance. Common techniques for doing so are to have different sections of your program use
different namespaces, or else make individual variables private through either dynamic variable
scoping or lexical variable scoping.

Three of these variables can be given by external or internal customers. The value(s) of the
remaining variable(s) is/are then set by project management, ideally based on solid estimation
techniques. The final values have to be agreed upon in a negotiation process between project
management and the customer. Usually, the values in terms of time, cost, quality and scope are
contracted.

To keep control over the project from the beginning of the project all the way to its natural
conclusion, a project manager uses a number of techniques: project planning, earned value, risk
management, scheduling, process improvement.

Project planning
Project management is the process to quantify the amount of time and budget a project will cost.
The purpose of project planning is creating a project plan that a project manager can use to track
the progress of his team.

NH 3
How to plan a project

1. Determine the exact conditions for the project to be completed or to be terminated. Before it
is absolutely clear what the objectives of the project are, it makes little sense to start
estimating how long it will take and how much it will cost. Unfortunately, many project
managers fail to take this first, crucial step. Each project should have a clear connection to
one or more real of organization's business issues.
2. Make an inventory of all the work that needs to be done with an estimate of the time it will
take to complete by a single team member. This can be done in a planning session with all the
team members. Tasks that will take over three weeks to complete need to be broken down
further to get good granularity. To avoid getting swamped with details, the tasks at the lowest
level should take approximately 1 week. The result is a work breakdown structure. Make
sure that having the project's deliverables injected into the organization or its environment
will actually cause the expected benefits (project objectives) to materialize.
3. Identify the resources needed to complete each terminal element of the WBS. At this point
you can usually estimate the cost to deliver each terminal element and, consequently, the
project (bottom-up approach). Sometimes a top-down approach to estimating costs is also
possible by means of using coefficients (e.g. it costs between $X and $Y to build a square
meter of a house of such-and-such a standard).
4. Make a decision whether this initial plan makes sense, i.e. whether the costs justify the
benefits. Modify the objectives and the supporting work as necessary.
5. Define dependencies among tasks. Some tasks need to be completed before other tasks can
begin. By putting tasks into their relative completion order, a project manager constructs a
project network.
6. Calculate the minimum time the project will take: it is the longest path through the project
network from the start of the project until its end. This path is called the critical path (or
critical chain, if resource dependencies are taken into account). Other tasks can be done in
parallel to the critical path but any delay in the tasks on the critical path will automatically
result in a delay in the overall deadline of the project.
7. Create a project schedule (e.g. in the form of a Gantt chart).
8. Plan for risk management and modify the project plan accordingly.
9. Commit the organization to starting the project implementation.

Project planning is not something that is done only once at the beginning of the project. It should be
an ongoing task of the project manager to keep an eye on the progress of his team and update the
project plan accordingly. Project management software can be helpful if used properly. There are
several plans for risk

1. Using the same plan for every project

2. Applying prepackaged plans indiscriminately
3. Allowing a plan to diverge from project reality
4. Planning in too much detail too soon
5. Planning to catch up later
6. Not learning from past planning sins

Earned value management

Project management technique for estimating how a project is doing in terms of its budget and
schedule.

Earned value compares the work the project team has finished so far with the estimates they made in
the beginning of the project. This gives a measure of how far the project is from completion. By

NH 4
extrapolating from the amount of work already put into the project, the project manager can get an
estimate on how much resources the project will have used at completion.

This technique is based on the critical path concept. An alternative project performance measurement
and management technique is critical chain, which utilizes buffer management instead. The reason is
that the earned value management method does not distinguish between the progress on the project
constraint (i.e. its critical chain) from progress on the non-constraints (i.e. other paths in the project
network). This can sometimes lead the project manager to expedite non-critical work at the expense
of critical work in pursuit of better earned value measures, resulting in delayed project completion.
This is a case of local optimalization, resulting from a lack of subordination of local measures to
work breakdown structure (WBS): a list of all tasks broken down in a hierarchical structure

• project master schedule (PMS): a Gantt chart of what task will be done when and by who
• budgeted cost of work scheduled (BCWS) or planned value: for every period the budgets of
the tasks that were planned to be finished in this time unit
• budgeted cost of work produced (BCWP) or earned value: for every period the budgets of the
tasks that actually finished in this time unit
• actual cost of work produced (ACWP) or effort spent: for every period the actual costs of the
work
• budget at completion (BAC): sum(BCWS), the total budget we estimate to spend to complete
the project
• total funding available (TFA): the budget the client has committed to
• negotiated period of performance (NPOP): the time period the client has agreed upon with the
project manager
• planned period of performance (PPOP): the time period we think we can finish the project
• cost accrual ratio (CAR): the total average cost per person per time unit
• forecast of remaining work (FCST) or current schedule: the work that still needs to be done
after this time unit

From this data, the project manager can calculate

• the cost variance (CV): BCWS - ACWP, greater than 0 is good

• the schedule variance (SV): BCWP - BCWS, greater than 0 is good
• the cost performance index (CPI): BCWP/ACWP, greater than 1 is good
• the schedule performance index (SPI): BCWP/BCWS, greater than 1 is good
• the estimate at completion (EAC): sum(ACWP) + (BAC - sum(BCWP)) / CPI, an estimate of
the budget spent at the end of the project

Risk management
Risk management is the process of measuring, or assessing risk and then developing strategies to
manage the risk. In ideal risk management, a prioritization process is followed whereby the risks
with the greatest loss and the greatest probability of occurring are handled first, and risks with lower
probability of occurrence and lower loss are handled later.

In practice the process can be very difficult, and balancing between risks with a high probability of
occurrence but lower loss vs. a risk with high loss but lower probability of occurrence can often be
mishandled.

Risk management also faces a difficulty in allocating resources properly. This is the idea of
opportunity cost. Resources spent on risk management could be instead spent on more profitable
activities. Again, ideal risk management spends the least amount of resources in the process while
reducing the effects of risks as much as possible.
NH 5
Steps in the risk management process
Identification and assessment

A first step in the process of managing risk is to identify potential risks. The risks must then be
assessed as to their potential severity of loss and to the probability of occurrence.

Possible actions available

Once risks have been identified and assessed, all techniques to manage the risk fall into one or more
of these four major categories:

• Avoidance
• Reduction
• Retention
• Transfer

Ideal use of these strategies may not be possible. Some of them may involve trade offs that are not
acceptable to the organization or person making the risk management decisions.

Risk avoidance

Includes not performing an activity that could carry risk. An example would be not buying a property
or business in order to not take on the liability that comes with it. Another would be not flying in
order to not take the risk that the plane were to be hijacked. Avoidance may seem the answer to all
risks, but avoiding risks also means losing out on the potential gain that accepting (retaining) the risk
may have allowed. Not entering a business to avoid the risk of loss also avoids the possibility of
earning the profits.

Risk reduction

Involves methods that reduce the severity of the loss. Examples include sprinklers designed to put
out a fire to reduce the risk of loss by fire. This method may cause a greater loss by water damage
and therefore may not be suitable. Halon fire suppression systems may mitigate that risk, but the cost
may be prohibitive as a strategy.

Risk retention

Involves accepting the loss when it occurs. True self insurance falls in this category. All risks that are
not avoided or transferred are retained by default.

Risk transfer

Means causing another party to accept the risk, typically by contract. Insurance is one type of risk
transfer. Other times it may involve contract language that transfers a risk to another party without
the payment of an insurance premium. Liability among construction or other contractors is very often
transferred this way.

Some ways of managing risk fall into multiple categories. Risk retention pools are technically
retaining the risk for the group, but spreading it over the whole group, involves transfer among
individual members of the group. This is different from traditional insurance, in that no premium is
exchanged between members of the group.

NH 6
Create the plan

Decide on the combination of methods to be used for each risk

Implementation

Follow all of the planned methods for mitigating the effect of the risks. Purchase insurance policies
for the risks that have been decided to be transferred to an insurer, avoid all risks that can be without
sacrificing the entity's goals, reduce others, and retain the rest.

Review and evaluation of the plan

Initial risk management plans will never be perfect. Practice, experience, and actual loss results, will
necessitate changes in the plan and contribute information to allow possible different decisions to be
made in dealing with the risks being faced.

Limitations

If risks are improperly assessed and prioritized, time can be wasted in dealing with risk of losses that
are not likely to occur. Spending too much time assessing and managing unlikely risks can divert
resources that could be used more profitably. Unlikely events do occur, but if the risk is unlikely
enough to occur, it may be better to simply retain the risk, and deal with the result if the loss does in
fact occur.

Prioritizing too highly the Risk management processes itself could potentially keep an organization
from ever completing a project or even getting started. This is especially true if other work is
suspended until the risk management process is considered complete.

Areas of risk management

As applied to corporate finance, risk management is a technique for measuring, monitoring and
controlling the financial or operational risk on a firm's balance sheet.

Project management

In project management, a risk is more narrowly defined as a possible event or circumstance that can
have negative influences on a project. Its influence can be on the schedule, the resources, the scope
and/or the quality.

In project management parlance, when a risk escalates, it becomes a liability. A liability is a negative
event or circumstance that is hindering the project.

Some of the processes for assessing risk include the following (the parentheses contain some of the
jargon used to refer to them).

• Choosing unique identifiers for referring to the same risk in company or project documents
(identification).
• Describing the risk and how it could become a liability (description).
• Assessing the consequences of that (effect).
• Considering what precautions could be taken to prevent it (precaution).
• Drawing up contingency plans or procedures for handling it (contingency).
• Categorising the risk as new, ongoing or closed (risk status)
• Estimating the probability of the risk becoming a liability (Risk escalation probability, P)

NH 7
 • Estimating the consequences in terms of time for the project (Schedule impact, S)

In addition, every probable risk can have a pre-formulated plan to deal with it to deal with it's
possible consequences (to ensure contingency if the risk becomes a liability).

From the information above and the average cost per employee over time, or Cost Accrual Ratio, a
project manager can estimate

• the cost associated with the risk if it arises, estimated by multiplying employee costs per unit
time by the estimated time lost (cost impact, C where C = CAR * S)
• the probable increase in time associated with a risk (schedule variance due to risk, Rs where
Rs = P * S):
o Sorting on this value puts the highest risks to the schedule first. This is intended to
cause the greatest risks to the project to be attempted first so that risk is minimised as
quickly as possible.
o This is slightly misleading as schedule variances with a large P and small S and visa-
versa are not equivalent. (The risk of the HMS Titanic sinking vs. the passengers'
meals being served at slightly the wrong time).
• the probable increase in cost associated with a risk (cost variance due to risk, Rc where Rc =
P*C = P*CAR*S = P*S*CAR)
o sorting on this value puts the highest risks to the budget first.
o see concerns about schedule variance as this is a function of it, as illustrated in the
equation above.

Risk in a project or process can be due either to special causes of deviation or common causes of
deviation and requires appropriate treatment. That is to re-iterate the concern about extremal cases
not being equivalent in the list immediately above.

Risk management activities as applied to project management

In project management, risk management includes the following activities:

• Planning how risk management will be held in the particular project. Plan should include risk
management tasks, responsibilities, activities and budget.
• Assigning risk officer - a team member other than a project manager who is responsible for
foreseeing potential project problems. Typical characteristic of risk officer is a healthy
skepticism.
• Maintaining live project risk database. Each risk should have the following attributes:
opening date, title, short description, probability and importance. Optionally risk can have
assigned person responsible for its resolution and date till then risk still can be resolved.
• Creating anonymous risk reporting channel. Each team member should have possibility to
report risk that he foresees in the project.
• Preparing mitigation plans for risks that are chosen to be mitigated. The purpose of the
mitigation plan is to describe how this particular risk will be handled – what, when, by who
and how will be done to avoid it or minimize consequences if it becomes a liability.
• Summarizing planned and faced risks, effectiveness of mitigation activities and effort spend
for the risk management.

Scheduling
Schema) is the process of assigning tasks to a set of resources. It is an important concept in many
areas such as computing, production processes or airlines.

NH 8
In mathematical terms, a scheduling problem is often solved as an optimization problem, with the
objective of maximizing a measure of schedule quality. For example, an airline might wish to
minimize the number of airport gates required for its aircraft in order to reduce its operating costs.

Scheduling is important in modern production and chemical industries, where it can have a major
impact in the productivity of a process. Common objectives in this type of scheduling are to
minimize the makespan (duration) of production or to maximize total profit for a given set of
customer demands. Modern computerised scheduling tools greatly outperform the manual (heuristic)
scheduling methods commonly employed in the industry.

It is a key concept in multitasking and multiprocessing operating system design, and in real-time
operating system design. It refers to the way processes are assigned priorities in a priority queue.
This assignment is carried out by software known as a scheduler.

In general-purpose operating systems, the goal of the scheduler is to balance processor loads, and
prevent any one process from either monopolizing the processor or being starved for resources. In
real-time environments, such as devices for automatic control in industry (for example robotics), the
scheduler also must ensure that processes can meet deadlines; this is crucial for keeping the system
stable.

Many scheduling problems are NP-hard and much research has been performed to find efficient
ways of solving larger scheduling problems. Common mathematical techniques used to solve
scheduling problems are Mixed Integer Linear Programming, Logical programming and Constraint
programming.

Process improvement
Process improvement is the activity of elevating the performance of a process, especially that of a
business process with regard to its goal.

Process improvement can take the form of an improvement project, or that of a process. Such a
process of continuous improvement is part of organization's management processes (as opposed to
business processes and reengineering.

History of project management

Project management was not used as an isolated concept before the Sputnik crisis of the Cold War.
After this crisis, the United States Department of Defense needed to speed up the military project
process and new tools (models) for achieving this goal were invented. In 1958 they invented the
Program Evaluation and Review Technique or PERT, as part of the Polaris missile submarine
program. At the same time, the DuPont corporation invented a similar model called CPM, critical
path method. PERT was later extended with a work breakdown structure or WBS. The process flow
and structure of the military undertakings quickly spread into many private enterprises.

There are a number of guiding techniques that have been developed over the years that can be used
to formally specify exactly how the project will be managed. These include the Project Management
Body of Knowledge (PMBOK), and such ideas as the Personal Software Process (PSP), and the
Team Software Process (TSP) and PRINCE2. These techniques attempt to standardize the practices
of the development team making them easier to predict and manage as well as track.

Critical chain is the latest extension to the traditional critical path method.

NH 9
In critical studies of project management, it has been noted that several of these fundamentally
PERT-based models are not well suited for the multi-project company environment of today. Most of
them are aimed at very large-scale, one-time, non-routine project, and nowadays all kinds of
management is expressed in terms of projects. Using complex models for "projects" (or rather
"tasks") spanning a few weeks has been proven to cause unnecessary costs and low maneuverability
in several cases. Instead project management experts try to identify different "lightweight" models,
such as, for example Extreme Programming for software development and Scrum techniques. The
generalization of extreme programming to other kinds of projects is extreme project management.

Process based management

Also furthering the concept of Project Control is the incorporation of Process Based Management.
This area has been driven by the use of Maturity models such as the CMMi (Capability Maturity
Model integrated) and ISO/IEC15504 (SPICE - Software Process Improvement Capability
dEtermination). Both of these models have been successfully adopted by organisations all over the
world in an effort to have better control over project. With a view to improving accuracy of
estimation, reducing costs and preventing defects. CMMi is widely used in the defence industry and
their subcontractors in the USA and Australia, and SPICE is growing in use in the private sector in
Europe.

The main thrust of Process Management is the concept of knowledge management. It is the
experience of companies that use these models that the creation of a set of defined processes
detailing what the company actually does has enabled them to achieve consistency across project
teams and project. They have also found that, when it is defined, their ability to track and monitor
performance with a view to improvement is far more successful.

PRINCE2
PRINCE2, or Projects in a Controlled Environment, is a project management method. It covers the
managing, controlling and organizing of a project.

History

PRINCE (Projects in Controlled Environments) is a project management methodology for the

organisation, management and control of projects. It was initially developed in 1989 by the Central
Computer and Telecommunications Agency (CCTA) as a UK Government standard for IT project
management; however, it soon became regularly applied outside the purely IT environment.

PRINCE2 was released in 1996 as a generic project management method. PRINCE2 has become
increasingly popular and is now the de facto standard for project management in the UK. Its use has
spread beyond the UK to more than 50 other countries. The most current revision was released in
2002 by the Office for Government Commerce (OGC), which has replaced the CCTA.

Processes

PRINCE2 is a process based approach to project management. It consists of eight high level
processes:

• Directing a project (DP)

• Planning (PL)
• Starting up a project (SU)
• Initiating a project (IP)
• Controlling a stage (CS)
NH 10
 • Managing product delivery (MP)
• Managing stage boundaries (SB)
• Closing a project (CP)

The processes Starting up a project, Initiating a project and Closing a project are specific phases in a
project. Three processes are involved in the implementation phase - Controlling a stage, Managing
product delivery and Managing stage boundaries. The process Directing a project applies for the
length of the project, while Planning applies for all phases except the final one - Closing a project.

A PRINCE2 project must consist of at least two phases, but will typically contain four:

• Starting a project
• Initiating a project
• Implementation
• Closing a project.

The implementation phase is often broken up into multiple stages if, as is often the case, it proves
sensible.

Starting up a project

The purpose of this process is to set the project up in the right way. It is a pre-project process that
ascertains if the project would be worthwhile and viable before seeking commitment of resources. Its
major input is the Project Mandate. It involves identifying the senior decision makers required to
make up the project board who will oversee the project. The project board selects a project manager.
The reasons for the project are outlined in a Project Brief. The project approach is decided, as is the
plan for the initiation stage, to give the project a firm foundation.

The actual elements of Starting Up a Project are:

• SU1. Appointing a Project Executive and a Project Manager

• SU2. Designing a Project Management Team
• SU3. Appointing a Project Management Team
• SU4. Preparing a Project Brief
• SU5. Defining Project Approach
• SU6. Planning Initiation Stage

Directing a project

This process defines the functions of the Project Board who are responsible for the project. The
project manager keeps the Project Board informed with regular reports, who leave the day to day
management of the project to the Project Manager. They only become involved at stage boundaries
when they must approve progress so far and give the go ahead to the next stage. A fundamental
principle of PRINCE2 is management by exception, which means the only other time the Project
Board make decisions about the project is when the project is forecast to go off course.

The actual elements of Directing a Project are:

• DP1. Authorising Initiation

• DP2. Authorising a Project
• DP3. Authorising a Stage or Exception Plan

NH 11
 • DP4. Giving Ad Hoc Direction
• DP5. Confirming Project Closure

Planning

Planning is a process involved throughout the project's life-cycle.

The actual elements of Planning are:

• PL1. Designing a Plan

• PL2. Defining and Analysing Products
• PL3. Identifying Activities and Dependencies
• PL4. Estimating
• PL5. Scheduling
• PL6. Analysing Risks
• PL7. Completing a Plan

Initiating a project

In order for a project to be approved it must be carefully planned to show how it will meet its goals.
This requires making detailed estimations of costs. These go together to create the main product of
this process, the PID or Project Inititiation Document, which must be approved by the Project Board
before implementation can commence.

The actual elements of Initiating a Project are:

• IP1. Planning Quality

• IP2. Planning a Project
• IP3. Refining the Business Case and Risks
• IP4. Setting Up Project Controls
• IP5. Setting Up Project Files
• IP6. Assembling a Project Initiation Document (PID)

Controlling a stage

PRINCE2 projects are divided into stages so the project can be more easily managed and controlled.
The exact number of stages is not fixed; it depends on the size of the project and the degree of risk.
This process cover the day-to-day management of the project by the Project Manager.

The actual elements of Controlling a Stage are:

• CS1. Authorising Work Package

• CS2. Assessing Progress
• CS3. Capturing Project Issues
• CS4. Examining Project Issues
• CS5. Reviewing Stage Status
• CS6. Reporting Highlights
• CS7. Taking Corrective Action
• CS8. Escalating Project Issues
• CS9. Receiving Completed Work Package

NH 12
Managing product delivery

PRINCE2 is a product based system. A product can be a physical thing like a book, or it could be a
more intangible thing like a service agreement. In fact everything created by PRINCE2 including
documents is a product. Products can be created by anyone including external suppliers. This process
creates the products of the project and is where most of its resources are used.

The actual elements of Managing Product Delivery are:

• MP1. Accepting a Work Package

• MP2. Executing a Work Package
• MP3. Delivering a Work Package

Managing stage boundaries

According to PRINCE2 principles, each stage must be completed and approved by the project board
before the go ahead is given to proceed to the next stage.

The actual elements of Managing Stage Boundaries are:

• SB1. Planning a Stage

• SB2. Updating a Project Plan
• SB3. Updating a Project Business Case
• SB4. Updating the Risk Log
• SB5. Reporting Stage End
• SB6. Producing an Exception Plan

Closing a project

Another principle of PRINCE2 is that projects must be closed down in a controlled and orderly way.
This involves evaluating the project's result (The Post Project Review). Any lessons learned are
recorded, a handover document is created if necessary and a post implementation review is planned.

The actual elements of Closing a Project are:

• CP1. Decommissioning a Project

• CP2. Identifying Follow-on Actions
• CP3. Project Evaluation Review

Components

PRINCE2 recognises eight key concepts or what it calls components in project management:

Business Case

The purpose of the Business Case is to justify the project – it drives the business process and ensures
the project’s progress is aligned with the business’ objectives. The Business Case must be valid for
life of project. The owner of the business case is the project’s Executive. A major input to the
business case will be the project mandate.

NH 13
The Organisation

Defines all the roles and responsibilities for the people managing and executing the project.
PRINCE2 assumes that projects take place in a Customer – Supplier environment.

The main roles are:

• Project Board
o Executive
o Senior User
o Senior Supplier
• Project Manager
• Project Assurance
• Optional roles are:
o Team Manager
o Project Support

Plans

PRINCE2 plans need to be approved before they are put into action. There are 3 levels of plan:

• Project Plans
• Stage Plans
• Team Plans

A fourth type of plan, an exception plan, is used to replace the stage plan when a project deviation
occurs.

Controls

Controls ensure the right projects are produced at the right time and that the project remains viable
against the business case. PRINCE2 uses management by exception. Therefore there is no standard
requirement to hold meetings with the Project Board, who will be informed immediately if there are
exceptions. The main types of control used are:

• Project initiation
• Highlight reports
• Exceptions reports
• Exception assessment
• End stage assessment
• Project closure
• Tolerance

Management of Risk

Projects are unique undertakings and therefore are subject to unpredictability. Risk is “uncertainty of
outcome”. The management of risk is about keeping risks within acceptable bounds, in an efficient
and cost effective manner.

Risk management has 3 main principles:

• Risk Tolerance
• Risk Responsibility
NH 14
 • Risk Ownership

Quality in a Project Environment

The aim of a project is to produce products that are fit for purpose and satisfy the needs and
expectations of the customer. The quality expectations are stated in the Project Mandate, Project
Brief and the PID. There are 4 main elements that make up quality management:

• Quality Management System

• Quality Assurance Function
• Quality Planning
• Quality Control

Configuration Management

Configuration management is concerned with controlling all of the products of the project. A
configuration is a logically related set of products that need to be managed as a composite set. In
project management terms, this means all the products and deliverables of the project.

Configuration management consists of 5 main functions:

• Planning
• Identification
• Control
• Status Accounting
• Verification

Change Control

Controlling change is dealt with by the technique change control (see below).

Techniques

PRINCE2 identifies three specific techniques for use on projects.

Product based planning

PRINCE2 uses product based planning as opposed to activity based planning. Product based
planning involves the production of:

• Product breakdown structures

• Product descriptions
• Product flow diagrams

Change control

In PRINCE2 all changes are treated as Project Issues, of which there are three types:

• Request for change. This is raised for a change to a requirement or product.

• Off specification. This is where a product fails to meet a requirement.
• Query

NH 15
All project issues are the responsibility of the Project Manager and are recorded in an Issues Log.
Requests for change must be approved by the Project Board, who will require an impact analysis of
the change. Off specifications can be dealt with directly by the project manager if they fall within
pre-determined tolerance limits. The project board can approve an off specification without any
change, known as a concession.

Quality reviews

PRINCE2 requires products to be reviewed for quality. This takes place in a quality review meeting,
which identifies errors in the product. The quality review meeting will not attempt to solve the
problems it identifies.

Strengths

PRINCE2 has a number of strengths:

• It produces highly standardised projects which share a common approach, vocabulary and
documents. Consequently it is a transferable skill and anyone familiar with a method can
quickly be brought up to speed on a properly applied PRINCE2 project.
• It is a method which embodies best practise in project management
• It enshrines management by exception as a guiding rule, which allows the Project Manager to
do their job without undue interference, while at the same time involving higher level
managers when things go badly off plan or in PRINCE terms out of tolerance.
• It provides a controlled start, middle and end of projects
• Each type of document required by PRINCE2 is supplied as a template, which includes
required sub-headings which produces easily comprehensible, standardised and complete
documentation.

Weaknesses

PRINCE2 has weaknesses:

• A number of organisations suffer from PINO (Prince In Name Only), carelesly picking and
choosing from the methodology, thereby failing to abide by its key principles.
• PRINCE2 is strongly document centric in order to provide good control. However, in some
organisations the documents become ends in themselves, and the actual projects themselves
falter.
• Similiarly PRINCE2 stresses the need for good organisation and regular meetings between
stakeholders. In some organisations this has degenerated into too many meetings and too little
work.
• PRINCE2 provides no explicit treatment of requirements analysis. It is an implementation
methodology, which can lead to projects being adopted on false premises, and thereby
inevitably failing.
• If too strictly applied PRINCE2 can be far too heavy duty an approach for small projects.

NH 16
NH 17