SLOVAK UNIVERSITY OF TECHNOLOGY

Faculty of Material Science and Technology in Trnava

PROJECT MANAGEMENT
Colected and Processed by Pavol Tanuka

TRNAVA 2007

Obsah:
Project management............................................................................................3
History of project management......................................................................3
Definitions.........................................................................................................4
Job description.................................................................................................4
The traditional triple constraints...................................................................4
Project management activities...........................................................................6
Project objectives.............................................................................................7
Project management artifacts.........................................................................7
Project control variables.................................................................................7
Approaches.......................................................................................................8
Project systems...............................................................................................11
Project management tools.................................................................................13
Project management associations.................................................................13
International standards....................................................................................14
PLANNING A PROJECT.................................................................................16
Gantt chart.........................................................................................................25
Historical development..................................................................................25
Advantages and limitations...........................................................................25
Program Evaluation and Review Technique...................................................27
Overview.........................................................................................................27
PERT terminology and conventions.............................................................28
Implementing PERT......................................................................................29
Critical path method.........................................................................................35
Work breakdown structure..............................................................................37
History.............................................................................................................37
WBS design principles...................................................................................38
WBS construction example...........................................................................40
Common pitfalls and misconceptions...........................................................41
PRINCE2 Methodology....................................................................................42

Project management
Project Management is the discipline of planning, organizing, and managing resources to
bring about the successful completion of specific project goals and objectives. A project is a
finite endeavorhaving specific start and completion datesundertaken to create a unique
product or service which brings about beneficial change or added value. This finite
characteristic of projects stands in sharp contrast to processes, or operations, which are
permanent or semi-permanent functional work to repetitively produce the same product or
service. In practice, the management of these two systems is often found to be quite different,
and as such requires the development of distinct technical skills and the adoption of separate
management philosophy, which is the subject of this article.
The primary challenge of project management is to achieve all of the project goals and
objectives while adhering to classic project constraintsusually scope, quality, time and
budget. The secondaryand more ambitiouschallenge is to optimize the allocation and
integration of inputs necessary to meet pre-defined objectives. A project is a carefully defined
set of activities that use resources (money, people, materials, energy, space, provisions,
communication, motivation, etc.) to achieve the project goals and objectives.

History of project management

As a discipline, project management developed from different fields of application including
construction, engineering, and defense. In the United States, the forefather of project
management is Henry Gantt, called the father of planning and control techniques, who is
famously known for his use of the Gantt chart as a project management tool, for being an
associate of Frederick Winslow Taylor's theories of scientific management, and for his study
of the work and management of Navy ship building. His work is the forerunner to many
modern project management tools including the work breakdown structure (WBS) and
resource allocation.
The 1950s marked the beginning of the modern project management era. Again, in the United
States, prior to the 1950s, projects were managed on an ad hoc basis using mostly Gantt
Charts, and informal techniques and tools. At that time, two mathematical project scheduling
models were developed: (1) the "Program Evaluation and Review Technique" or PERT,
developed by Booz-Allen & Hamilton as part of the United States Navy's (in conjunction with
the Lockheed Corporation) Polaris missile submarine program; and the "Critical Path
Method" (CPM) developed in a joint venture by both DuPont Corporation and Remington
Rand Corporation for managing plant maintenance projects. These mathematical techniques
quickly spread into many private enterprises.
At the same time, technology for project cost estimating, cost management, and engineering
economics was evolving, with pioneering work by Hans Lang and others. In 1956, the
American Association of Cost Engineers (now AACE International; the Association for the
Advancement of Cost Engineering) was formed by early practitioners of project management
and the associated specialties of planning and scheduling, cost estimating, and cost/schedule
control (project control). AACE has continued its pioneering work and in 2006 released the
first ever integrated process for portfolio, program and project management(Total Cost
Management Framework).

In 1969, the Project Management Institute (PMI) was formed to serve the interest of the
project management industry. The premise of PMI is that the tools and techniques of project
management are common even among the widespread application of projects from the
software industry to the construction industry. In 1981, the PMI Board of Directors authorized
the development of what has become A Guide to the Project Management Body of Knowledge
(PMBOK Guide), containing the standards and guidelines of practice that are widely used
throughout the profession. The International Project Management Association (IPMA),
founded in Europe in 1967, has undergone a similar development and instituted the IPMA
Competence Baseline (ICB). The focus of the ICB also begins with knowledge as a
foundation, and adds considerations about relevant experience, interpersonal skills, and
competence. Both organizations are now participating in the development of an ISO project
management standard.

Definitions

PMBOK (Project Management -- Body of Knowledge as defined by the Project

Management Institute PMI):"Project management is the application of knowledge,
skills, tools and techniques to project activities to meet project requirements."
PRINCE2 project management methodology: "The planning, monitoring and control
of all aspects of the project and the motivation of all those involved in it to achieve the
project objectives on time and to the specified cost, quality and performance."
PROJECT: A temporary endeavor with a finite completion date undertaken to create a
unique product or service. Projects bring form or function to ideas or needs.
DIN 69901 (Deutsches Institut fr Normung - German Organization for
Standardization): "Project management is the complete set of tasks, techniques, tools
applied during project execution"

Job description
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.
A project manager is often a client representative and has to determine and implement the
exact needs of the client, based on knowledge of the firm they are representing. The ability to
adapt to the various internal procedures of the contracting party, and to form close links with
the nominated representatives, is essential in ensuring that the key issues of cost, time, quality,
and above all, client satisfaction, can be realized.
In whatever field, a successful project manager must be able to envision the entire project
from start to finish and to have the ability to ensure that this vision is realized.
Any type of product or service buildings, vehicles, electronics, computer software, financial
services, etc. may have its implementation overseen by a project manager and its operations
by a product manager.

The traditional triple constraints

Like any human undertaking, projects need to be performed and delivered under certain
constraints. Traditionally, these constraints have been listed as scope, time, and cost[citation
needed]
. These are also referred to as the Project Management Triangle, where each side
represents a constraint. One side of the triangle cannot be changed without impacting the
others. A further refinement of the constraints separates product 'quality' or 'performance' from
scope, and turns quality into a fourth constraint.

The Project Management Triangle

The time constraint refers to the amount of time available to complete a project. The cost
constraint refers to the budgeted amount available for the project. The scope constraint refers
to what must be done to produce the project's end result. These three constraints are often
competing constraints: increased scope typically means increased time and increased cost, a
tight time constraint could mean increased costs and reduced scope, and a tight budget could
mean increased time and reduced scope.
The discipline of project management is about providing the tools and techniques that enable
the project team (not just the project manager) to organize their work to meet these
constraints.
Another approach to project management is to consider the three constraints as finance, time
and human resources. If you need to finish a job in a shorter time, you can throw more people
at the problem, which in turn will raise the cost of the project, unless by doing this task
quicker we will reduce costs elsewhere in the project by an equal amount.

Time
For analytical purposes, the time required to produce a deliverable is estimated using several
techniques. One method is to identify tasks needed to produce the deliverables documented in
a work breakdown structure or WBS. The work effort for each task is estimated and those
estimates are rolled up into the final deliverable estimate.
The tasks are also prioritized, dependencies between tasks are identified, and this information
is documented in a project schedule. The dependencies between the tasks can affect the length

of the overall project (dependency constrained), as can the availability of resources (resource
constrained). Time is not considered a cost nor a resource since the project manager cannot
control the rate at which it is expended. This makes it different from all other resources and
cost categories. It should be remembered that no effort expended will have any higher quality
than that of the effort- expenders.

Cost
Cost to develop a project depends on several variables including (chiefly): resource quantities,
labor rates, material rates, risk management (i.e.cost contingency), Earned value management,
plant (buildings, machines, etc.), equipment, cost escalation, indirect costs, and profit.

Scope
Requirements specified for the end result. The overall definition of what the project is
supposed to accomplish, and a specific description of what the end result should be or
accomplish. A major component of scope is the quality of the final product. The amount of
time put into individual tasks determines the overall quality of the project. Some tasks may
require a given amount of time to complete adequately, but given more time could be
completed exceptionally. Over the course of a large project, quality can have a significant
impact on time and cost (or vice versa).
Together, these three constraints have given rise to the phrase "On Time, On Spec, On
Budget". In this case, the term "scope" is substituted with "spec(ification)".

Project management activities

Project management is composed of several different types of activities such as:
1. Analysis & design of objectives and events
2. Planning the work according to the objectives
3. Assessing and controlling risk (or Risk Management)
4. Estimating resources
5. Allocation of resources
6. Organizing the work
7. Acquiring human and material resources
8. Assigning tasks
9. Directing activities
10. Controlling project execution
11. Tracking and reporting progress (Management information system)
12. Analyzing the results based on the facts achieved
13. Defining the products of the project
14. Forecasting future trends in the project
15. Quality Management
16. Issues management
17. Issue solving
18. Defect prevention
19. Identifying, managing & controlling changes
20. Project closure (and project debrief)

21. Communicating to stakeholders

22. Increasing/ decreasing a company's workers

Project objectives
Project objectives define target status at the end of the project, reaching of which is
considered necessary for the achievement of planned benefits. They can be formulated as
S.M.A.R.T.

Specific,
Measurable (or at least evaluable) achievement,
Achievable (recently Acceptable is used regularly as well),
Relevant and
Time terminated (bounded).

The evaluation (measurement) occurs at the project closure. However a continuous guard on
the project progress should be kept by monitoring and evaluating.

Project management artifacts

The following documents serve to clarify objectives and deliverables and to align sponsors,
clients, and project team's expectations.
1. Project Charter
2. Preliminary Scope Statement / Statement of work
3. Business case / Feasibility Study
4. Scope Statement / Terms of reference
5. Project management plan / Project Initiation Document
6. Work Breakdown Structure
7. Change Control Plan
8. Risk Management Plan
9. Risk Breakdown Structure
10. Communications Plan
11. Governance Model
12. Risk Register
13. Issue Log
14. Action Item List
15. Resource Management Plan
16. Project Schedule
17. Status Report
18. Responsibility assignment matrix
19. Database of lessons learned
20. Stakeholder Analysis
These documents are normally hosted on a shared resource (i.e., intranet web page) and are
available for review by the project's stakeholders (except for the Stakeholder Analysis, since
this document comprises personal information regarding certain stakeholders. Only the
Project Manager has access to this analysis). Changes or updates to these documents are
explicitly outlined in the project's configuration management (or change control plan).

Project control variables

Project Management tries to gain control over variables such as risk:
Risk
Potential points of failure: Most negative risks (or potential failures) can be overcome
or resolved, given enough planning capabilities, time, and resources. According to
some definitions (including PMBOK Third Edition) risk can also be categorized as
"positive--" meaning that there is a potential opportunity, e.g., complete the project
faster than expected.
Customers (either internal or external project sponsors) and external organizations (such as
government agencies and regulators) can dictate the extent of three variables: time, cost, and
scope. The remaining variable (risk) is managed by the project team, ideally based on solid
estimation and response planning techniques. Through a negotiation process among project
stakeholders, an agreement defines the final objectives, in terms of time, cost, scope, and risk,
usually in the form of a charter or contract.
To properly control these variables a good project manager has a depth of knowledge and
experience in these four areas (time, cost, scope, and risk), and in six other areas as well:
integration, communication, human resources, quality assurance, schedule development, and
procurement.

Approaches
There are several approaches that can be taken to managing project activities including agile,
interactive, incremental, and phased approaches.
Regardless of the approach employed, careful consideration needs to be given to clarify
surrounding project objectives, goals, and importantly, the roles and responsibilities of all
participants and stakeholders.

The traditional approach

A traditional phased approach identifies a sequence of steps to be completed. In the
traditional approach, we can distinguish 5 components of a project (4 stages plus control) in
the development of a project:
1.
2.
3.
4.
5.

project initiation stage;

project planning or design stage;
project execution or production stage;
project monitoring and controlling systems;
project completion stage.

Not all the 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 Administration. In software development, this approach is
often known as 'waterfall development' i.e. one series of tasks after another in linear sequence.
In software development many organizations have adapted the Rational Unified Process
(RUP) to fit this methodology, although RUP does not require or explicitly recommend this
practice. Waterfall development can work for small tightly defined projects, but for larger
projects of undefined or unknowable scope, it is less suited. The Cone of Uncertainty explains
some of this as the planning made on the initial phase of the project suffers from a high
degree of uncertainty. This becomes specially true as software development is often the
realization of a new or novel product, this method has been widely accepted as ineffective for
software projects where requirements are largely unknowable up front and susceptible to
change. 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.

Rational Unified Process

1. Inception - Identify the initial scope of the project, a potential architecture for the
system, and obtain initial project funding and stakeholder acceptance.
2. Elaboration - Prove the architecture of the system.
3. Construction - Build working software on a regular, incremental basis which meets the
highest-priority needs of project stakeholders.
4. Transition - Validate and deploy the system into the production environment

Temporary organization sequencing concepts

1.
2.
3.
4.

Action-based entrepreneurship
Fragmentation for commitment-building
Planned isolation
Institutionalised termination

Critical Chain
Critical chain is the application of the Theory of Constraints (TOC) to projects. The goal is to
increase the rate of throughput (or completion rates) of projects in an organization. Applying
the first three of the five focusing steps of TOC, the system constraint for all projects is
identified as resources. To exploit the constraint, tasks on the critical chain are given priority
over all other activities. Finally, projects are planned and managed to ensure that the critical
chain tasks are ready to start as soon as the needed resources are available, subordinating all
other resources to the critical chain.
For specific projects, the project plan is resource-leveled, and the longest sequence of
resource-constrained tasks is identified as the critical chain. In multi-project environments,
resource leveling should be performed across projects. However, it is often enough to identify
(or simply select) a single "drum" resourcea resource that acts as a constraint across
projectsand stagger projects based on the availability of that single resource.

Extreme Project Management

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
projects, and nowadays all kinds of management are 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 Extreme
Programming for software development and Scrum techniques. The generalization of Extreme
Programming to other kinds of projects is extreme project management, which may be used in
combination with the process modeling and management principles of human interaction
management.

Event chain methodology

Event chain methodology is the next advance beyond critical path method and critical chain
project management.
Event chain methodology is an uncertainty modeling and schedule network analysis technique
that is focused on identifying and managing events and event chains that affect project
schedules. Event chain methodology helps to mitigate the negative impact of psychological
heuristics and biases, as well as to allow for easy modeling of uncertainties in the project
schedules. Event chain methodology is based on the following major principles.

Probabilistic moment of risk: An activity (task) in most real life processes is not a
continuous uniform process. Tasks are affected by external events, which can occur at
some point in the middle of the task.
Event chains: Events can cause other events, which will create event chains. These
event chains can significantly affect the course of the project. Quantitative analysis is
used to determine a cumulative effect of these event chains on the project schedule.
Critical events or event chains: The single events or the event chains that have the
most potential to affect the projects are the critical events or critical chains of
events. They can be determined by the analysis.
Project tracking with events: If a project is partially completed and data about the
project duration, cost, and events occurred is available, it is possible to refine
information about future potential events and helps to forecast future project
performance.
Event chain visualization: Events and event chains can be visualized using event chain
diagrams on a Gantt chart.

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 Integration) and ISO/IEC15504 (SPICE - Software Process
Improvement and Capability Determination), which have been far more successful.

Agile project management approaches based on the principles of human interaction

management are founded on a process view of human collaboration. This contrasts sharply
with traditional approach. In the agile software development or flexible product development
approach, the project is seen as a series of relatively small tasks conceived and executed as the
situation demands in an adaptive manner, rather than as a completely pre-planned process.

Project systems
As mentioned above, traditionally, project development includes five elements: control
systems and four stages.

Project control systems

Project control is that element of a project that keeps it on-track, on-time, and within budget.
Project control begins early in the project with planning and ends late in the project with postimplementation review, having a thorough involvement of each step in the process. Each
project should be assessed for the appropriate level of control needed: too much control is too
time consuming, too little control is very risky. If project control is not implemented correctly,
the cost to the business should be clarified in terms of errors, fixes, and additional audit fees.
Control systems are needed for cost, risk, quality, communication, time, change, procurement,
and human resources. In addition, auditors should consider how important the projects are to
the financial statements, how reliant the stakeholders are on controls, and how many controls
exist. Auditors should review the development process and procedures for how they are
implemented. The process of development and the quality of the final product may also be
assessed if needed or requested. A business may want the auditing firm to be involved
throughout the process to catch problems earlier on so that they can be fixed more easily. An
auditor can serve as a controls consultant as part of the development team or as an
independent auditor as part of an audit.
Businesses sometimes use formal systems development processes. These help assure that
systems are developed successfully. A formal process is more effective in creating strong
controls, and auditors should review this process to confirm that it is well designed and is
followed in practice. A good formal systems development plan outlines:

A strategy to align development with the organizations broader objectives

Standards for new systems
Project management policies for timing and budgeting
Procedures describing the process

Project development stages

Regardless of the methodology used, the project development process will have the same
major stages: initiation, planning or development, production or execution, maintenance and
controlling, and closing.
Initiation

The initiation stage determines the nature and scope of the development. If this stage is not
performed well, it is unlikely that the project will be successful in meeting the businesss
needs. The key project controls needed here are an understanding of the business environment
and making sure that all necessary controls are incorporated into the project. Any deficiencies
should be reported and a recommendation should be made to fix them.
The initiation stage should include a cohesive plan that encompasses the following areas:

Study analyzing the business needs in measurable goals.

Review of the current operations.
Conceptual design of the operation of the final product.
Equipment requirement.
Financial analysis of the costs and benefits including a budget.
Select stake holders, including users, and support personnel for the project.
Project charter including costs, tasks, deliverables, and schedule.

Planning and design

After the initiation stage, the system is designed. Occasionally, a small prototype of the final
product is built and tested. Testing is generally performed by a combination of testers and end
users, and can occur after the prototype is built or concurrently. Controls should be in place
that ensure that the final product will meet the specifications of the project charter. The results
of the design stage should include a product design that:

Satisfies the project sponsor, end user, and business requirements.

Functions as it was intended.
Can be produced within quality standards.
Can be produced within time and budget constraints.

Executing
Executing consists of the processes used to complete the work defined in the project
management plan to accomplish the project's requirements. Execution process involves
coordinating people and resources, as well as integrating and performing the activities of the
project in accordance with the project management plan. The deliverables are produced as
outputs from the processes performed as defined in the project management plan.
Monitoring and Controlling
Monitoring and Controlling consists of those processes performed to observe project
execution so that potential problems can be identified in a timely manner and corrective
action can be taken, when necessary, to control the execution of the project. The key benefit is
that project performance is observed and measured regularly to identify variances from the
project management plan. Monitoring and Controlling includes:

Monitoring the ongoing project activities against the project management plan and the
project performance baseline
Influencing the factors that could circumvent integrated change control so only
approved changes are implemented

In multi-phase projects, the Monitoring and Controlling process also provides feedback
between project phases, in order to implement corrective or preventive actions to bring the
project into compliance with the project management plan.
Project Maintenance is an ongoing process, and it includes:

Continuing support of end users

Correction of errors
Updates of the software over time

In this stage, auditors should pay attention to how effectively and quickly user problems are
resolved.
Over the course of any construction project, the work scope changes. Change is a normal and
expected part of the construction process. Changes can be the result of necessary design
modifications, differing site conditions, material availability, contractor-requested changes,
value engineering and impacts from third parties, to name a few. Beyond executing the
change in the field, the change normally needs to be documented to show what was actually
constructed. Hence, the owner usually requires a final record to show all changes or, more
specifically, any change that modifies the tangible portions of the finished work. The record is
made on the contract documents usually, but not necessarily limited to, the design drawings.
The end product of this effort is what the industry terms as-built drawings, or more simply,
asbuilts. The requirement for providing them is a norm in construction contracts.
Closing
Closing includes the formal acceptance of the project and the ending thereof. Administrative
activities include the archiving of the files and documenting lessons learned. Closing phase
consist of two parts:

Close project: to finalize all activities across all of the process groups to formally close
the project or a project phase
Contract closure: necessary for completing and settling each contract, including the
resolution of any open items, and closing each contract applicable to the project or a
project phase.

Project management tools

Project management tools include

Financial tools
Cause and effect charts
PERT charts
Gantt charts
Event Chain Diagrams
RACI diagram
Run charts
Project Cycle Optimisation
List of project management software

Participatory Impact Pathways Analysis (An approach for developing common

understanding and consensus amongst project partcipants and stakeholders as to how
the project will achieve its goal)

Project management associations

Several national and professional associations exist which have as their aim the promotion
and development of project management and the project management profession. The most
prominent associations include:

The Project Management Institute (PMI)

The American Academy of Project Management (AAPM)
The Agile Project Leadership Network (APLN)
The Association for Project Management (UK) (APM)
The Australian Institute of Project Management (AIPM)
The International Project Management Association (IPMA)
The Brazilian Association for Project Management (ABGP)
The International Association of Project and Program Management (IAPPM)

International standards
There have been several attempts to develop project management standards, such as:

A Framework for Performance Based Competency Standards for Global Level 1 and
Level 2 Project Managers (Global Alliance for Project Performance Standards)
A Guide to the Project Management Body of Knowledge (PMBOK Guide)
The Standard for Program Management
The Standard for Portfolio Management
APM Body of Knowledge 5th ed. (APM Association for Project Management (UK))
ICB v3 (IPMA Competence Baseline)
RBC v1.1 (ABGP Competence Baseline)
PRINCE2 (PRojects IN a Controlled Environment)
P2M (A guidebook of Project & Program Management for Enterprise Innovation,
Japanese third-generation project management method) (Download page for P2M and
related products)
V-Modell (German project management method)
HERMES method (The Swiss general project management method, selected for use in
Luxembourg and international organisations)
Organizational Project Management Maturity Model (OPM3)
International Organisation for Standardisation Founded 1947
o ISO 9000: a family of standards for quality management systems.
o ISO 10006:2003, Quality management systems Guidelines for quality
management in projects
JPACE (Justify, Plan, Activate, Control, and End - The James Martin Method for
Managing Projects (1981present))
Software Engineering Institute: Capability Maturity Model
Total Cost Management Framework (AACE International's process for Portfolio,
Program and Project Management) (ref:Cost Engineering)

Professional certifications

CompTIA Project+, ([Computer Technology Industry Association])

CPM (The International Association of Project & Program Management)
IPMA (Levels of Certification: IPMA-A, IPMA-B, IPMA-C and IPMA-D)
PMP (Project Management Professional), CAPM (Certified Associate in Project
Management). PMI certifications
Master Project Manager, Certified International Project Manager. AAPM certifications
Certified Portfolio, Program & Project Manager (C3PM)- AACE International.
Master's Certificate in Project Management The George Washington University and
ESI International
Master of Science in Project Management

PLANNING A PROJECT
THE SPECIFICATION
Before describing the role and creation of a specification, we need to introduce and explain a
fairly technical term: a numbty is a person whose brain is totally numb. In this context, numb
means "deprived of feeling or the power of unassisted activity"; in general, a numbty needs
the stimulation of an electric cattle prod to even get to the right office in the morning.
Communication with numbties is severely hampered by the fact that although they think they
know what they mean (which they do not), they seldom actually say it, and they never write it
down. And the main employment of numbties world-wide is in creating project specifications.
You must know this - and protect your team accordingly.
A specification is the definition of your project: a statement of the problem, not the solution.
Normally, the specification contains errors, ambiguities, misunderstandings and enough rope
to hang you and your entire team. Thus before you embark upon the the next six months of
activity working on the wrong project, you must assume that a numbty was the chief author of
the specification you received and you must read, worry, revise and ensure that everyone
concerned with the project (from originator, through the workers, to the end-customer) is
working with the same understanding. The outcome of this deliberation should be a written
definition of what is required, by when; and this must be agreed by all involved. There are no
short-cuts to this; if you fail to spend the time initially, it will cost you far more later on.
The agreement upon a written specification has several benefits:

the clarity will reveal misunderstandings

the completeness will remove contradictory assumptions
the rigour of the analysis will expose technical and practical details which numbties
normally gloss over through ignorance or fear
the agreement forces all concerned to actually read and think about the details

The work on the specification can seen as the first stage of Quality Assurance since you are
looking for and countering problems in the very foundation of the project - from this
perspective the creation of the specification clearly merits a large investment of time.
From a purely defensive point of view, the agreed specification also affords you protection
against the numbties who have second thoughts, or new ideas, half way through the project.
Once the project is underway, changes cost time (and money). The existence of a
demonstrably-agreed specification enables you to resist or to charge for (possibly in terms of
extra time) such changes. Further, people tend to forget what they originally thought; you may
need proof that you have been working as instructed.
The places to look for errors in a specification are:

the global context: numbties often focus too narrowly on the work of one team and fail
to consider how it fits into the larger picture. Some of the work given to you may
actually be undone or duplicated by others. Some of the proposed work may be
incompatible with that of others; it might be just plain barmy in the larger context.

the interfaces: between your team and both its customers and suppliers, there are
interfaces. At these points something gets transferred. Exactly what, how and when
should be discussed and agreed from the very beginning. Never assume a common
understanding, because you will be wrong. All it takes for your habitual
understandings to evaporate is the arrival of one new member, in either of the teams.
Define and agree your interfaces and maintain a friendly contact throughout the
project.
time-scales: numbties always underestimate the time involved for work. If there are no
time-scales in the specification, you can assume that one will be imposed upon you
(which will be impossible). You must add realistic dates. The detail should include a
precise understanding of the extent of any intermediate stages of the task, particularly
those which have to be delivered.
external dependencies: your work may depend upon that of others. Make this very
clear so that these people too will receive warning of your needs. Highlight the effect
that problems with these would have upon your project so that everyone is quite clear
about their importance. To be sure, contact these people yourself and ask if they are
able to fulfil the assumptions in your specification.
resources: the numbty tends to ignore resources. The specification should identify the
materials, equipment and manpower which are needed for the project. The agreement
should include a commitment by your managers to allocate or to fund them. You
should check that the actual numbers are practical and/or correct. If they are omitted,
add them - there is bound to be differences in their assumed values.

This seems to make the specification sound like a long document. It should not be. Each of
the above could be a simple sub-heading followed by either bullet points or a table - you are
not writing a brochure, you are stating the definition of the project in clear, concise and
unambiguous glory.
Of course, the specification may change. If circumstances, or simply your knowledge, change
then the specification will be out of date. You should not regard it as cast in stone but rather as
a display board where everyone involved can see the current, common understanding of the
project. If you change the content everyone must know, but do not hesitate to change it as
necessary.

PROVIDING STRUCTURE
Having decide what the specification intends, your next problem is to decide what you and
your team actually need to do, and how to do it. As a manager, you have to provide some form
of framework both to plan and to communicate what needs doing. Without a structure, the
work is a series of unrelated tasks which provides little sense of achievement and no feeling
of advancement. If the team has no grasp of how individual tasks fit together towards an
understood goal, then the work will seem pointless and they will feel only frustration.
To take the planning forward, therefore, you need to turn the specification into a complete set
of tasks with a linking structure. Fortunately, these two requirements are met at the same time
since the derivation of such a structure is the simplest method of arriving at a list of tasks.

Work Breakdown Structure

Once you have a clear understanding of the project, and have eliminated the vagaries of the
numbties, you then describe it as a set of simpler separate activities. If any of these are still
too complex for you to easily organise, you break them down also into another level of
simpler descriptions, and so on until you can manage everything. Thus your one complex
project is organised as a set of simple tasks which together achieve the desired result.
The reasoning behind this is that the human brain (even yours) can only take in and process so
much information at one time. To get a real grasp of the project, you have to think about it in
pieces rather than trying to process the complexity of its entire details all at once. Thus each
level of the project can be understood as the amalgamation of a few simply described smaller
units.
In planning any project, you follow the same simple steps: if an item is too complicated to
manage, it becomes a list of simpler items. People call this producing a work breakdown
structure to make it sound more formal and impressive. Without following this formal
approach you are unlikely to remember all the niggling little details; with this procedure, the
details are simply displayed on the final lists.
One common fault is to produce too much detail at the initial planning stage. You should be
stop when you have a sufficient description of the activity to provide a clear instruction for
the person who will actually do the work, and to have a reasonable estimate for the total
time/effort involved. You need the former to allocate (or delegate) the task; you need the latter
to finish the planning.
Task Allocation
The next stage is a little complicated. You now have to allocate the tasks to different people in
the team and, at the same time, order these tasks so that they are performed in a sensible
sequence.
Task allocation is not simply a case of handing out the various tasks on your final lists to the
people you have available; it is far more subtle (and powerful) than that. As a manager you
have to look far beyond the single project; indeed any individual project can be seen as
merely a single step in your team's development. The allocation of tasks should thus be seen
as a means of increasing the skills and experience of your team - when the project is done, the
team should have gained.
In simple terms, consider what each member of your team is capable of and allocate sufficient
complexity of tasks to match that (and to slightly stretch). The tasks you allocate are not the
ones on your finals lists, they are adapted to better suit the needs of your team's development;
tasks are moulded to fit people, which is far more effective than the other way around. For
example, if Arthur is to learn something new, the task may be simplified with responsibility
given to another to guide and check the work; if Brenda is to develop, sufficient tasks are
combined so that her responsibility increases beyond what she has held before; if Colin lacks
confidence, the tasks are broken into smaller units which can be completed (and commended)
frequently.

Sometimes tasks can be grouped and allocated together. For instance, some tasks which are
seemingly independent may benefit from being done together since they use common ideas,
information, talents. One person doing them both removes the start-up time for one of them;
two people (one on each) will be able to help each other.
The ordering of the tasks is really quite simple, although you may find that sketching a
sequence diagram helps you to think it through (and to communicate the result). Pert charts
are the accepted outcome, but sketches will suffice. Getting the details exactly right, however,
can be a long and painful process, and often it can be futile. The degree to which you can
predict the future is limited, so too should be the detail of your planning. You must have the
broad outlines by which to monitor progress, and sufficient detail to assign each task when it
needs to be started, but beyond that - stop and do something useful instead.
Guesstimation
At the initial planning stage the main objective is to get a realistic estimate of the time
involved in the project. You must establish this not only to assist higher management with
their planning, but also to protect your team from being expected to do the impossible. The
most important technique for achieving this is known as: guesstimation.
Guesstimating schedules is notoriously difficult but it is helped by two approaches:

make your guesstimates of the simple tasks at the bottom of the work break down
structure and look for the longest path through the sequence diagram
use the experience from previous projects to improve your guesstimating skills

The corollary to this is that you should keep records in an easily accessible form of all
projects as you do them. Part of your final project review should be to update your personal
data base of how long various activities take. Managing this planning phase is vital to your
success as a manager.
Some people find guesstimating a difficult concept in that if you have no experience of an
activity, how can you make a worthwhile estimate? Let us consider such a problem: how long
would it take you to walk all the way to the top of the Eiffel Tower or the Statue of Liberty?
Presuming you have never actually tried this (most people take the elevator part of the way),
you really have very little to go on. Indeed if you have actually seen one (and only one) of
these buildings, think about the other. Your job depends upon this, so think carefully. One idea
is to start with the number of steps - guess that if you can. Notice, you do not have to be right,
merely reasonable. Next, consider the sort of pace you could maintain while climbing a flight
of steps for a long time. Now imagine yourself at the base of a flight of steps you do know,
and estimate a) how many steps there are, and b) how long it takes you to climb them (at that
steady pace). To complete, apply a little mathematics.
Now examine how confident you are with this estimate. If you won a free flight to Paris or
New York and tried it, you would probably (need your head examined) be mildly surprised if
you climbed to the top in less than half the estimated time and if it took you more than double
you would be mildly annoyed. If it took you less than a tenth the time, or ten times as long,
you would extremely surprised/annoyed. In fact, you do not currently believe that that would
happen (no really, do you?). The point is that from very little experience of the given problem,
you can actually come up with a working estimate - and one which is far better than no

estimate at all when it comes to deriving a schedule. Guesstimating does take a little practice,
but it is a very useful skill to develop.
There are two practical problems in guesstimation. First, you are simply too optimistic. It is
human nature at the beginning of a new project to ignore the difficulties and assume best case
scenarii - in producing your estimates (and using those of others) you must inject a little
realism. In practice, you should also build-in a little slack to allow yourself some tolerance
against mistakes. This is known as defensive scheduling. Also, if you eventually deliver ahead
of the agreed schedule, you will be loved.
Second, you will be under pressure from senior management to deliver quickly, especially if
the project is being sold competitively. Resist the temptation to rely upon speed as the only
selling point. You might, for instance, suggest the criteria of: fewer errors, history of
adherence to initial schedules, previous customer satisfaction, "this is how long it takes, so
how can you trust the other quotes".

ESTABLISHING CONTROLS
When the planning phase is over (and agreed), the "doing" phase begins. Once it is in motion,
a project acquires a direction and momentum which is totally independent of anything you
predicted. If you come to terms with that from the start, you can then enjoy the roller-coaster
which follows. To gain some hope, however, you need to establish at the start (within the
plan) the means to monitor and to influence the project's progress.
There are two key elements to the control of a project

milestones (clear, unambiguous targets of what, by when)

established means of communication

For you, the milestones are a mechanism to monitor progress; for your team, they are shortterm goals which are far more tangible than the foggy, distant completion of the entire project.
The milestones maintain the momentum and encourage effort; they allow the team to judge
their own progress and to celebrate achievement throughout the project rather than just at its
end.
The simplest way to construct milestones is to take the timing information from the work
breakdown structure and sequence diagram. When you have guesstimated how long each subtask will take and have strung them together, you can identify by when each of these tasks
will actually be completed. This is simple and effective; however, it lacks creativity.
A second method is to construct more significant milestones. These can be found by identify
stages in the development of a project which are recognisable as steps towards the final
product. Sometimes these are simply the higher levels of your structure; for instance, the
completion of a market-evaluation phase. Sometimes, they cut across many parallel activities;
for instance, a prototype of the eventual product or a mock-up of the new brochure format.
If you are running parallel activities, this type of milestone is particularly useful since it
provides a means of pulling together the people on disparate activities, and so:

they all have a shared goal (the common milestone)

their responsibility to (and dependence upon) each other is emphasised

each can provide a new (but informed) viewpoint on the others' work
the problems to do with combining the different activities are highlighted and
discussed early in the implementation phase
you have something tangible which senior management (and numbties) can recognise
as progress
you have something tangible which your team can celebrate and which constitutes a
short-term goal in a possibly long-term project
it provides an excellent opportunity for quality checking and for review

Of course, there are milestones and there are mill-stones. You will have to be sensitive to any
belief that working for some specific milestone is hindering rather than helping the work
forward. If this arises then either you have chosen the wrong milestone, or you have failed to
communicate how it fits into the broader structure.
Communication is your everything. To monitor progress, to receive early warning of danger,
to promote cooperation, to motivate through team involvement, all of these rely upon
communication. Regular reports are invaluable - if you clearly define what information is
needed and if teach your team how to provided it in a rapidly accessible form. Often these
reports merely say "progressing according to schedule". These you send back, for while the
message is desired the evidence is missing: you need to insist that your team monitor their
own progress with concrete, tangible, measurements and if this is done, the figures should be
included in the report. However, the real value of this practice comes when progress is not
according to schedule - then your communication system is worth all the effort you invested
in its planning.

THE ARTISTRY IN PLANNING

At the planning stage, you can deal with far more than the mere project at hand. You can also
shape the overall pattern of your team's working using the division and type of activities you
assign.
Who know best?
Ask your team. They too must be involved in the planning of projects, especially in the lower
levels of the work breakdown structure. Not only will they provide information and ideas, but
also they will feel ownership in the final plan.
This does not mean that your projects should be planned by committee - rather that you, as
manager, plan the project based upon all the available experience and creative ideas. As an
initial approach, you could attempt the first level(s) of the work breakdown structure to help
you communicate the project to the team and then ask for comments. Then, using these, the
final levels could be refined by the people to whom the tasks will be allocated. However,
since the specification is so vital, all the team should vet the penultimate draft.
Dangers in review
There are two pitfalls to avoid in project reviews:
they can be too frequent
they can be too drastic

The constant trickle of new information can lead to a vicious cycle of planning and revising
which shakes the team's confidence in any particular version of the plan and which destroys
the very stability which the structure was designed to provide. You must decide the balance.
Pick a point on the horizon and walk confidently towards it. Decide objectively, and explain
beforehand, when the review phases will occur and make this a scheduled milestone in itself.
Even though the situation may have changed since the last review, it is important to recognise
the work which has been accomplished during the interim. Firstly, you do not want to
abandon it since the team will be demotivated feeling that they have achieved nothing.
Secondly, this work itself is part of the new situation: it has been done, it should provide a
foundation for the next step or at least the basis of a lesson well learnt. Always try to build
upon the existing achievements of your team.
Testing and Quality
No plan is complete without explicit provision for testing and quality. As a wise manager, you
will know that this should be part of each individual phase of the project. This means that no
activity is completed until it has passed the (objectively) defined criteria which establishes its
quality, and these are best defined (objectively) at the beginning as part of the planning.
When devising the schedule therefore you must include allocated time for this part of each
activity. Thus your question is not only: "how long will it take", but also: "how long will the
testing take". By asking both questions together you raise the issue of "how do we know we
have done it right" at the very beginning and so the testing is more likely to be done in
parallel with the implementation. You establish this philosophy for your team by include
testing as a justified (required) cost.
Fitness for purpose
Another reason for stating the testing criteria at the beginning is that you can avoid futile
quests for perfection. If you have motivated your team well, they will each take pride in their
work and want to do the best job possible. Often this means polishing their work until is
shines; often this wastes time. If it clear at the onset exactly what is needed, then they are
more likely to stop when that has been achieved. You need to avoid generalities and to
stipulate boundaries; not easy, but essential.
The same is also true when choosing the tools or building-blocks of your project. While it
might be nice to have use of the most modern versions, or to develop an exact match to your
needs; often there is an old/existing version which will serve almost as well (sufficient for the
purpose), and the difference is not worth the time you would need to invest in obtaining or
developing the new one. Use what is available whenever possible unless the difference in the
new version is worth the time, money and the initial, teething pains.
A related idea is that you should discourage too much effort on aspects of the project which
are idiosyncratic to that one job. In the specification phase, you might try to eliminate these
through negotiation with the customer; in the implementation phase you might leave these
parts until last. The reason for this advice is that a general piece of work can be tailored to
many specific instances; thus, if the work is in a general form, you will be able to rapidly reuse it for other projects. On the other hand, if you produce something which is cut to fit
exactly one specific case, you may have to repeat the work entirely even though the next

project is fairly similar. At the planning phase, a manager should bare in mind the future and
the long-term development of the team as well as the requirements of the current project.
Fighting for time
As a manager, you have to regulate the pressure and work load which is imposed upon your
team; you must protect them from the unreasonable demands of the rest of the company. Once
you have arrived at what you consider to be a realistic schedule, fight for it. Never let the
outside world deflect you from what you know to be practical. If they impose a deadline upon
you which is impossible, clearly state this and give your reasons. You will need to give some
room for compromise, however, since a flat NO will be seen as obstructive. Since you want to
help the company, you should look for alternative positions.
You could offer a prototype service or product at an earlier date. This might, in some cases, be
sufficient for the customer to start the next stage of his/her own project on the understanding
that your project would be completed at a later date and the final version would then replace
the prototype.
The complexity of the product, or the total number of units, might be reduced. This might, in
some cases, be sufficient for the customer's immediate needs. Future enhancements or more
units would then be the subject of a subsequent negotiation which, you feel, would be likely
to succeed since you will have already demonstrate your ability to deliver on time.
You can show on an alternative schedule that the project could be delivered by the deadline if
certain (specified) resources are given to you or if other projects are rescheduled. Thus, you
provide a clear picture of the situation and a possible solution; it is up to your manager then
how he/she proceeds.
Planning for error
The most common error in planning is to assume that there will be no errors in the
implementation: in effect, the schedule is derived on the basis of "if nothing goes wrong, this
will take ...". Of course, recognising that errors will occur is the reason for implementing a
monitoring strategy on the project. Thus when the inevitable does happen, you can react and
adapt the plan to compensate. However, by carefully considering errors in advance you can
make changes to the original plan to enhance its tolerance. Quite simply, your planning should
include time where you stand back from the design and ask: "what can go wrong?"; indeed,
this is an excellent way of asking your team for their analysis of your plan.
You can try to predict where the errors will occur. By examining the activities' list you can
usually pinpoint some activities which are risky (for instance, those involving new equipment)
and those which are quite secure (for instance, those your team has done often before). The
risky areas might then be given a less stringent time-scale - actually planning-in time for the
mistakes. Another possibility is to apply a different strategy, or more resources, to such
activities to minimise the disruption. For instance, you could include training or consultancy
for new equipment, or you might parallel the work with the foundation of a fall-back position.

Post-mortem
At the end of any project, you should allocate time to reviewing the lessons and information
on both the work itself and the management of that work: an open meeting, with open
discussion, with the whole team and all customers and suppliers. If you think that this might
be thought a waste of time by your own manager, think of the effect it will have on future
communications with your customers and suppliers.

PLANNING FOR THE FUTURE

With all these considerations in merely the "planning" stage of a project, it is perhaps
surprising that projects get done at all. In fact projects do get done, but seldom in the
predicted manner and often as much by brute force as by careful planning. The point,
however, is that this method is non-optimal. Customers feel let down by late delivery, staff are
demotivated by constant pressure for impossible goals, corners get cut which harm your
reputation, and each project has to overcome the same problems as the last.
With planning, projects can run on time and interact effectively with both customers and
suppliers. Everyone involved understands what is wanted and emerging problems are seen
(and dealt with) long before they cause damage. If you want your projects to run this way then you must invest time in planning.

Gantt chart

A Gantt chart showing three kinds of schedule dependencies (in red) and percent complete
indications.
A Gantt chart is a popular type of bar chart that illustrates a project schedule. Gantt charts
illustrate the start and finish dates of the terminal elements and summary elements of a
project. Terminal elements and summary elements comprise the work breakdown structure of
the project. Some Gantt charts also show the dependency (i.e., precedence network)
relationships between activities. Gantt charts can be used to show current schedule status
using percent-complete shadings and a vertical "TODAY" line as shown here.

Historical development
The first Gantt Chart was developed by Karol Adamiecki, who called it a Harmonogram.
Because Adamiecki did not publish his chart until 1931, this famous chart bears Gantt's name.
[citation needed]
Henry Gantt (18611919) designed his chart in 1910.
In the 1980s, personal computers eased the creation and editing of elaborate Gantt charts.
These desktop applications were intended mainly for project managers and project schedulers.
In the late 1990s and early 2000s, Gantt charts became a common feature of web-based
applications, including collaborative groupware.
Although now considered a common charting technique, Gantt charts were considered quite
revolutionary when they were introduced. In recognition of Henry Gantt's contributions, the
Henry Laurence Gantt Medal is awarded for distinguished achievement in management and in
community service.

Advantages and limitations

Gantt charts have become a common technique for representing the phases and activities of a
project work breakdown structure (WBS), so they can be understood by a wide audience.

A common error made by those who equate Gantt chart design with project design is that they
attempt to define the project work breakdown structure at the same time that they define
schedule activities. This practice makes it very difficult to follow the 100% Rule. Instead the
WBS should be fully defined to follow the 100% Rule, then the project schedule can be
designed.
Although a Gantt chart is easily comprehended for small projects that fit on a single sheet or
screen, they can become quite unwieldy for projects with more than about 30 activities.
Larger Gantt charts may not be suitable for most computer displays. A related criticism is that
Gantt charts communicate relatively little information per unit area of display. That is,
projects are often considerably more complex than can be communicated effectively with a
Gantt chart.
Gantt charts only represent part of the triple constraints of projects, because they focus
primarily on schedule management. Moreover, Gantt charts do not represent the size of a
project or the relative size of work elements, therefore the magnitude of a behind-schedule
condition is easily miscommunicated. If two projects are the same number of days behind
schedule, the larger project has a larger impact on resource utilization, yet the Gantt does not
represent this difference.
Although project management software can show schedule dependencies as lines between
activities, displaying a large number of dependencies may result in a cluttered or unreadable
chart.
Because the horizontal bars of a Gantt chart have a fixed height, they can misrepresent the
time-phased workload (resource requirements) of a project. In the example shown in this
article, Activities E and G appear to be the same size, but in reality they may be orders of
magnitude different. A related criticism is that all activities of a Gantt chart show planned
workload as constant. In practice, many activities (especially summary elements) have frontloaded or back-loaded work plans, so a Gantt chart with percent-complete shading may
actually miscommunicate the true schedule performance status.

Program Evaluation and Review Technique

PERT network chart for a seven-month project with five milestones (10 through 50) and six
activities (A through F).
The Program (or Project) Evaluation and Review Technique, commonly abbreviated
PERT, is a model for project management designed to analyze and represent the tasks
involved in completing a given project.

Overview
PERT is a method to analyze the tasks involved in completing a given project, especially the
time needed to complete each task, and identifying the minimum time needed to complete the
total project.
This model was invented by Booz Allen Hamilton, Inc. under contract to the United States
Department of Defense's US Navy Special Projects Office in 1958 as part of the Polaris
mobile submarine-launched ballistic missile project. This project was a direct response to the
Sputnik crisis. Some US government contracts required that PERT be used as part of
management supervision.
PERT was developed primarily to simplify the planning and scheduling of large and complex
projects. It was able to incorporate uncertainty by making it possible to schedule a project
while not knowing precisely the details and durations of all the activities. It is more of an
event-oriented technique rather than start- and completion-oriented, and is used more in
R&D-type projects where time, rather than cost, is the major factor.
This project model was the first of its kind, a revival for scientific management, founded in
Fordism and Taylorism. Though most companies now have their own project model, they all
resemble PERT in some respect.[citation needed] Only DuPont corporation's critical path method
was invented at roughly the same time as PERT.

The most recognizable feature of PERT is the "PERT Networks", a chart of interconnecting
timelines. PERT is intended for very large-scale, one-time, complex, non-routine projects.

PERT terminology and conventions

Conventions

A PERT chart is a tool that facilitates decision making; The first draft of a PERT
chart will number its events sequentially in 10s (10, 20, 30, etc.) to allow the later
insertion of additional events.
Two consecutive events in a PERT chart are linked by activities, which are
conventionally represented as arrows in the diagram above.
The events are presented in a logical sequence and no activity can commence until its
immediately preceding event is completed.
The planner decides which milestones should be PERT events and also decides their
proper sequence.
A PERT chart may have multiple pages with many sub-tasks.

Terminology

A PERT event: is a point that marks the start or completion of one or more tasks. It
consumes no time, and uses no resources. It marks the completion of one or more
tasks, and is not reached until all of the activities leading to that event have been
completed.
A predecessor event: an event (or events) that immediately precedes some other event
without any other events intervening. It may be the consequence of more than one
activity.
A successor event: an event (or events) that immediately follows some other event
without any other events intervening. It may be the consequence of more than one
activity.
A PERT activity: is the actual performance of a task. It consumes time, it requires
resources (such as labour, materials, space, machinery), and it can be understood as
representing the time, effort, and resources required to move from one event to
another. A PERT activity cannot be completed until the event preceding it has
occurred.
Optimistic time (O): the minimum possible time required to accomplish a task,
assuming everything proceeds better than is normally expected
Pessimistic time (P): the maximum possible time required to accomplish a task,
assuming everything goes wrong (but excluding major catastrophes).
Most likely time (M): the best estimate of the time required to accomplish a task,
assuming everything proceeds as normal.
Expected time (TE): the best estimate of the time required to accomplish a task,
assuming everything proceeds as normal (the implication being that the expected time
is the average time the task would require if the task were repeated on a number of
occasions over an extended period of time).
TE = (O + 4M + P) 6
Critical Path: the longest possible continuous pathway taken from the initial event to
the terminal event. It determines the total calendar time required for the project; and,

therefore, any time delays along the critical path will delay the reaching of the
terminal event by at least the same amount.
Critical Activity: A activity that has total float equal to zero. Activity with zero float
does not mean it is on critical path.
Lead time (rhymes with "feed", not "fed"): the time by which a predecessor event must
be completed in order to allow sufficient time for the activities that must elapse before
a specific PERT event is reached to be completed.
Lag time: the earliest time by which a successor event can follow a specific PERT
event.
Slack: the slack of an event is a measure of the excess time and resources available in
achieving this event. Positive slack(+) would indicate ahead of schedule; negative
slack would indicate behind schedule; and zero slack would indicate on schedule.
Fast tracking: performing more critical activities in parallel
Crashing critical path: Shortening duration of critical activities
Float or Slack is the amount of time that a task in a project network can be delayed
without causing a delay - Subsequent tasks (free float) or Project Completion
(total float)

Implementing PERT
The first step to scheduling the project is to determine the tasks that the project requires and
the order in which they must be completed. The order may be easy to record for some tasks
(e.g. When building a house, the land must be graded before the foundation can be laid) while
difficult for others (There are two areas that need to be graded, but there are only enough
bulldozers to do one). Additionally, the time estimates usually reflect the normal, non-rushed
time. Many times, the time required to execute the task can be reduced for an additional cost
or a reduction in the quality.
In the following example there are seven tasks, labeled a through g. Some tasks can be done
concurrently (a & b) while others cannot be done until their predecessor task is complete (c
cannot begin until a is complete). Additionally, each task has three time estimates: the
optimistic time estimate (a), the most likely or normal time estimate (m), and the pessimistic
time estimate (b). The expected time (TE) is computed using the formula (a + 4m + b) /6.
Activity Predecessor

Opt. Norm. Pess.

TE
a
m
b (a + 4m + b) /6

--

4.00

--

5.33

5.17

10

6.33

b, c

5.17

4.50

5.17

Note: All times listed are in work days (Mon - Fri, 8 A.M. to 5 P.M. with a one hour lunch
break).

Once this step is complete, one can draw a Gantt chart or a network diagram.

A Gantt chart created using Microsoft Project (MSP). Note (1) the critical path is in red, (2)
the slack is the black lines connected to non-critical activities, (3) when using MSP, you must
use the task ID when labeling predecessor activities, and (4) since Saturday and Sunday are
not work days (as described above) some bars on the Gantt chart are longer if they cut through
a weekend.

A Gantt chart created using OmniPlan. Note (1) the critical path is highlighted, (2) the slack is
not specifically indicated on task 5 (d), though it can be observed on tasks 3 and 7 (b and f),
(3) when using OmniPlan, you may use the GUI to easily link dependencies, or you may enter
them by reference to task ID, and (4) since weekends are indicated by a thin vertical line, and
take up no additional space on the work calendar, bars on the Gantt chart are not longer or
shorter when they do or don't carry over a weekend.
A network diagram can be created by hand or by using a diagram software. There are two
types of network diagrams, activity on arrow (AOA) and activity on node (AON). Activity on
node diagrams are generally easier to create and interpret. To create an AON diagram, it is
recommended (but not necessary) to start with a node named start. This "activity" has a
duration of zero (0). Then you draw each activity that does not have a predecessor activity (a
and b in this example) and connect them with an arrow from start to each node. Next, since
both c and d list a as a predecessor activity, their nodes are drawn with arrows coming from a.
Activity e is listed with b and c as predecessor activities, so node e is drawn with arrows
coming from both b and c, signifying that e cannot begin until both b and c have been

completed. Activity f has d as a predecessor activity, so an arrow is drawn connecting the

activities. Likewise, an arrow is drawn from e to g. Since there are no activities that come
after f or g, it is recommended (but again not necessary) to connect them to a node labeled
finish.

A network diagram created using Microsoft Project (MSP). Note the critical path is in red.

A node like this one (from Microsoft Visio) can be used to display the activity name, duration,
ES, EF, LS, LF, and slack.
By itself, the network diagram pictured above does not give much more information than a
Gantt chart; however, it can be expanded to display more information. The most common
information shown is:
1.
2.
3.
4.
5.
6.
7.

The activity name

The normal duration time
The early start time (ES)
The early finish time (EF)
The late start time (LS)
The late finish time (LF)
The slack

In order to determine this information it is assumed that the activities and normal duration
times are given. The first step is to determine the ES and EF. The ES is defined as the

maximum EF of all predecessor activities, unless the activity in question is the first activity,
which the ES is zero (0). The EF is the ES plus the task duration (EF = ES + duration).

The ES for start is zero since it is the first activity. Since the duration is zero, the EF is
also zero. This EF is used as the ES for a and b.
The ES for a is zero. The duration (4 work days) is added to the ES to get an EF of
four. This EF is used as the ES for c and d.
The ES for b is zero. The duration (5.33 work days) is added to the ES to get an EF of
5.33.
The ES for c is four. The duration (5.17 work days) is added to the ES to get an EF of
9.17.
The ES for d is four. The duration (6.33 work days) is added to the ES to get an EF of
10.33. This EF is used as the ES for f.
The ES for e is the greatest EF of its predecessor activities (b and c). Since b has an
EF of 5.33 and c has an EF of 9.17, the ES of e is 9.17. The duration (5.17 work days)
is added to the ES to get an EF of 14.34. This EF is used as the ES for g.
The ES for f is 10.33. The duration (4.5 work days) is added to the ES to get an EF of
14.83.
The ES for g is 14.34. The duration (5.17 work days) is added to the ES to get an EF
of 19.51.
The ES for finish is the greatest EF of its predecessor activities (f and g). Since f has an
EF of 14.83 and g has an EF of 19.51, the ES of finish is 19.51. Finish is a milestone
(and therefore has a duration of zero), so the EF is also 19.51.

Barring any unforeseen events, the project should take 19.51 work days to complete. The next
step is to determine the late start (LS) and late finish (LF) of each activity. This will
eventually show if there are activities that have slack. The LF is defined as the minimum LS
of all successor activities, unless the activity is the last activity, for which the LF equals the
EF. The LS is the LF minus the task duration (LS = LF - duration).

The LF for finish is equal to the EF (19.51 work days) since it is the last activity in the
project. Since the duration is zero, the LS is also 19.51 work days. This will be used as
the LF for f and g.
The LF for g is 19.51 work days. The duration (5.17 work days) is subtracted from the
LF to get an LS of 14.34 work days. This will be used as the LF for e.
The LF for f is 19.51 work days. The duration (4.5 work days) is subtracted from the
LF to get an LS of 15.01 work days. This will be used as the LF for d.
The LF for e is 14.34 work days. The duration (5.17 work days) is subtracted from the
LF to get an LS of 9.17 work days. This will be used as the LF for b and c.
The LF for d is 15.01 work days. The duration (6.33 work days) is subtracted from the
LF to get an LS of 8.68 work days.
The LF for c is 9.17 work days. The duration (5.17 work days) is subtracted from the
LF to get an LS of 4 work days.
The LF for b is 9.17 work days. The duration (5.33 work days) is subtracted from the
LF to get an LS of 3.84 work days.
The LF for a is the minimum LS of its successor activities. Since c has an LS of 4
work days and d has an LS of 8.68 work days, the LF for a is 4 work days. The
duration (4 work days) is subtracted from the LF to get an LS of 0 work days.
The LF for start is the minimum LS of its successor activities. Since a has an LS of 0
work days and b has an LS of 3.84 work days, the LS is 0 work days.

The next step is to determine the critical path and if any activities have slack. The critical path
is the path that takes the longest to complete. To determine the path times, add the task
durations for all available paths. Activities that have slack can be delayed without changing
the overall time of the project. Slack is computed in one of two ways, slack = LF - EF or slack
= LS - ES. Activities that are on the critical path have a slack of zero (0).

The duration of path adf is 14.83 work days.

The duration of path aceg is 19.51 work days.
The duration of path beg is 15.67 work days.

The critical path is aceg and the critical time is 19.51 work days. It is important to note that
there can be more than one critical path (in a project more complex than this example) or the
critical path can change. For example, let's say that activities d and f take their pessimistic (b)
times to complete instead of their expected (TE) times. The critical path is now adf and the
critical time is 22 work days. On the other hand, if activity c can be crashed to one work day,
the path time for aceg is reduced to 15.34 work days, which is slightly less than the time of
the new critical path, beg (15.67 work days).
Assuming these scenarios do not happen, the slack for each activity can now be determined.

Start and finish are milestones and by definition have no duration, therefore they can
have no slack (0 work days).
The activities on the critical path by definition have a slack of zero; however, it is
always a good idea to check the math anyway when drawing by hand.
o LFa - EFa = 4 - 4 = 0
o LFc - EFc = 9.17 - 9.17 = 0
o LFe - EFe = 14.34 - 14.34 = 0
o LFg - EFg = 19.51 - 19.51 = 0
Activity b has an LF of 9.17 and an EF of 5.33, so the slack is 3.84 work days.
Activity d has an LF of 15.01 and an EF of 10.33, so the slack is 4.68 work days.
Activity f has an LF of 19.51 and an EF of 14.83, so the slack is 3.84 work days.

Therefore, activity b can be delayed almost 4 work days without delaying the project.
Likewise, activity d or activity f can be delayed 4.68 work days without delaying the project
(alternatively, d and f can be delayed 2.34 work days each).

A completed network diagram created using Microsoft Visio. Note the critical path is in red.

Critical path method

The Critical Path Method, abbreviated CPM, or critical path analysis, is a mathematically
based algorithm for scheduling a set of project activities. It is an important tool for effective
project management.
It was developed in the 1950s in a joint venture between DuPont Corporation and Remington
Rand Corporation for managing plant maintenance projects. Today, it is commonly used with
all forms of projects, including construction, software development, research projects, product
development, engineering, and plant maintenance, among others. Any project with
interdependent activities can apply this method of scheduling.
The essential technique for using CPM is to construct a model of the project that includes the
following:
1. A list of all activities required to complete the project (also known as Work breakdown
structure),
2. The time (duration) that each activity will take to completion, and
3. The dependencies between the activities.
Using these values, CPM calculates the longest path of planned activities to the end of the
project, and the earliest and latest that each activity can start and finish without making the
project longer. This process determines which activities are "critical" (i.e., on the longest path)
and which have "total float" (i.e., can be delayed without making the project longer). In
project management, a critical path is the sequence of project network activities which add
up to the longest overall duration. This determines the shortest time possible to complete the
project. Any delay of an activity on the critical path directly impacts the planned project
completion date (i.e. there is no float on the critical path). A project can have several, parallel,
near critical paths. An additional parallel path through the network with the total durations
shorter than the critical path is called a sub-critical or non-critical path.
These results allow managers to prioritize activities for the effective management of project
completion, and to shorten the planned critical path of a project by pruning critical path
activities, by "fast tracking" (i.e., performing more activities in parallel), and/or by "crashing
the critical path" (i.e., shortening the durations of critical path activities by adding
resources).
Originally, the critical path method considered only logical dependencies between terminal
elements. Since then, it has been expanded to allow for the inclusion of resources related to
each activity, through processes called "activity-based resource assignments" and "resource
leveling". A resource-leveled schedule may include delays due to resource bottlenecks (i.e.,
unavailability of a resource at the required time), and may cause a previously shorter path to
become the longest or "resource critical" path. A related concept is called the critical chain,
which attempts to protect activity and project durations from unforeseen delays due to
resource constraints.
Since project schedules change on a regular basis, CPM allows continuous monitoring of the
schedule, allows the project manager to track the critical activities, and alerts the project

manager to the possibility that non-critical activities may be delayed beyond their total float,
thus creating a new critical path and delaying project completion. In addition, the method can
easily incorporate the concepts of stochastic predictions, using the Program Evaluation and
Review Technique (PERT) and event chain methodology.
Currently, there are several software solutions available in industry that use the CPM method
of scheduling, see list of project management software. However, the method was developed
and used without the aid of computers.
A schedule generated using critical path techniques often is not realized precisely, as
estimations are used to calculate times: if one mistake is made, the results of the analysis may
change. This could cause an upset in the implementation of a project if the estimates are
blindly believed, and if changes are not addressed promptly. However, the structure of critical
path analysis is such that the variance from the original schedule caused by any change can be
measured, and its impact either ameliorated or adjusted for. Indeed, an important element of
project postmortem analysis is the As Built Critical Path (ABCP), which analyzes the specific
causes and impacts of changes between the planned schedule and eventual schedule as
actually implemented.

Work breakdown structure

A (WBS) is a fundamental project management technique for defining and organizing the
total scope of a project, using a hierarchical tree structure. The first two levels of the WBS
(the root node and Level 2) define a set of planned outcomes that collectively and exclusively
represent 100% of the project scope. At each subsequent level, the children of a parent node
collectively and exclusively represent 100% of the scope of their parent node. A welldesigned WBS describes planned outcomes instead of planned actions. Outcomes are the
desired ends of the project, and can be predicted accurately; actions comprise the project plan
and may be difficult to predict accurately. A well-designed WBS makes it easy to assign any
project activity to one and only one terminal element of the WBS.

History
The concept of the WBS developed with the Program Evaluation and Review Technique
(PERT) in the United States Department of Defense (DoD). PERT was introduced by the U.S.
Navy in 1957 to support the development of its Polaris missile program. While the term
"work breakdown structure" was not used, this first implementation of PERT did organize the
tasks into product oriented categories.
By June of 1962, DoD, NASA and the aerospace industry published a guidance document for
the PERT Cost system which included an extensive description of the WBS approach. This
guide was endorsed by the Secretary of Defense for adoption by all services.
In 1968, the DoD issued "Work Breakdown Structures for Defense Materiel Items" (MILSTD-881), a military standard mandating the use of work breakdown structures across the
DoD. [4] This standard established top-level templates for common defense materiel items
along with associated descriptions (WBS dictionary) for their elements.
The document has been revised several times, most recently in 2005. The current version of
this guidance can be found in "Work Breakdown Structures for Defense Materiel Items"
(MIL-HDBK-881A).
It includes guidance for preparing work breakdown structures, templates for the top three
levels of typical systems (Appendices A through H), and a set of "common elements" that are
applicable to all major systems and subsystems (Appendix I)
Defense Materiel Item categories from MIL-HDBK-881A:

Aircraft Systems
Electronic/Automated Software Systems
Missile Systems
Ordnance Systems
Sea Systems
Space Systems
Surface Vehicle Systems
Unmanned Air Vehicle Systems

Common Elements

The Common Elements identified in MIL-HDBK-881A, Appendix I are: Integration,

assembly, test, and checkout; Systems engineering; Program management; Training; Data;
System test and evaluation; Peculiar support equipment; Common support equipment;
Operational and site activation; Industrial facilities; and Initial spares and repair parts
In 1987, the Project Management Institute (PMI) documented the expanion of these
techniques across non-defense organizations. The Project Management Body of Knowledge
(PMBOK) Guide provides an overview of the WBS concept, while the "Practice Standard for
Work Breakdown Structures" is comparable to the DoD handbook, but is intended for more
general application.[6]

WBS design principles

The 100% Rule
One of the most important WBS design principles is called the 100% Rule. The Practice
Standard for Work Breakdown Structures (Second Edition), published by the Project
Management Institute (PMI) defines the 100% Rule as follows:
The 100% Rule...states that the WBS includes 100% of the work defined by the project
scope and captures all deliverables internal, external, interim in terms of the work
to be completed, including project management. The 100% rule is one of the most
important principles guiding the development, decomposition and evaluation of the
WBS. The rule applies at all levels within the hierarchy: the sum of the work at the
child level must equal 100% of the work represented by the parent and the WBS
should not include any work that falls outside the actual scope of the project, that is, it
cannot include more than 100% of the work It is important to remember that the
100% rule also applies to the activity level. The work represented by the activities in
each work package must add up to 100% of the work necessary to complete the work
package. (p. 8)

Planned outcomes, not planned actions

If the WBS designer attempts to capture any action-oriented details in the WBS, he/she will
likely include either too many actions or too few actions. Too many actions will exceed 100%
of the parent's scope and too few will fall short of 100% of the parent's scope. The best way to
adhere to the 100% Rule is to define WBS elements in terms of outcomes or results. This also
ensures that the WBS is not overly prescriptive of methods, allowing for greater ingenuity and
creative thinking on the part of the project participants. For new product development
projects, the most common technique to ensure an outcome-oriented WBS is to use a product
breakdown structure. Feature-driven software projects may use a similar technique which is to
employ a feature breakdown structure. When a project provides professional services, a
common technique is to capture all planned deliverables to create a deliverable-oriented
WBS. Work breakdown structures that subdivide work by project phases (e.g. Preliminary
Design Phase, Critical Design Phase) must ensure that phases are clearly separated by a
deliverable also used in defining Entry and Exit Criteria (e.g. an approved Preliminary Design
Review document, or an approved Critical Design Review document).

Mutually exclusive elements

In addition to the 100% Rule, it is important that there is no overlap in scope definition
between two elements of a WBS. This ambiguity could result in duplicated work or
miscommunications about responsibility and authority. Likewise, such overlap is likely to
cause confusion regarding project cost accounting. If the WBS element names are ambiguous,
a WBS dictionary can help clarify the distinctions between WBS elements. The WBS
Dictionary describes each component of the WBS with milestones, deliverables, activities,
scope, and sometimes dates, resources, costs, quality, etc.

Level of detail
A question to be answered in the design of any WBS is when to stop dividing work into
smaller elements.
A common way of deciding the detailing level is the time between status reports/meetings. If
the team reports bi-weekly the largest work package should be 80 hours. Then at reporting
time a package is either not started, in progress, finished or late. This way makes it easy
catching delays.
A work package is a piece that:

can be realistically and confidently estimated

cannot be logically subdivided further
can be completed quickly
have a meaningful conclusion and deliverable
can be completed without interruption (without the need for more information)
will be outsourced or contracted out

Decomposition Considerations (Breadth vs. Depth)

A WBS will tend to be most useful for project management when its breadth and depth are
thoughtfully balanced. A common pitfall is to inadequately group related elements, resulting
in one or more nodes of the WBS becoming "too wide" to support effective management. This
can make it difficult for management to find risk-relevant roll-up points within the WBS,
requiring manual subtotaling of nodes or eventual restructuring of the WBS in order to make
useful cost data more readily accessible. While no concrete standard exists for optimal depth
or breadth, a common rule-of-thumb is to avoid having more than 7 immediate sub-elements
below any given node of the WBS. This rule-of-thumb appears to be derived from
psychological studies indicating that an average human brain is only capable of processing
about 7 to 9 considerations simultaneously. The relevance of that psychological consideration
to any particular WBS elaboration is left to the discretion of the WBS designer. At a
minimum, the existence of more than 7 sister-nodes at any point in the WBS should prompt
the designer to carefully consider whether those sub-elements might not best be expressed
(and tracked) in more logical sub-groupings.

WBS coding scheme

It is common for WBS elements to be numbered sequentially to reveal the hierarchical
structure. For example 1.3.2 Rear Wheel identifies this item as a Level 3 WBS element, since
there are three numbers separated by a decimal point. A coding scheme also helps WBS
elements to be recognized in any written context.

WBS construction example

Figure 1: WBS Construction Technique. This exemplary WBS is from PMI's Practice
Standard for Work Breakdown Structures (2nd Edition). This image illustrates an objective
method of employing the 100% Rule during WBS construction.
Figure 1 shows a WBS construction technique that demonstrates the 100% Rule
quantitatively. At the beginning of the design process, the project manager has assigned 100
points to the total scope of this project, which is designing and building a custom bicycle. At
WBS Level 2, the 100 total points are subdivided into seven comprehensive elements. The
number of points allocated to each is a judgment based on the relative effort involved; it is
NOT an estimate of duration. The three largest elements of WBS Level 2 are further
subdivided at Level 3, and so forth. The largest terminal elements at Level 3 represent only
17% of the total scope of work. These larger elements may be further subdivided using the
progressive elaboration technique described above. In this example, the WBS coding scheme
includes a trailing "underscore" character ("_") to identify terminal elements. This is a useful
coding scheme because planned activities (e.g. "Install inner tube and tire") will be assigned
to terminal elements instead of parent elements. Incidentally, this quantitiative method is
related to the Earned Value Management technique.
It is recommended that WBS design be initiated with interactive software (i.e. a spreadsheet)
that allows automatic rolling up of point values. Another recommended practice is to discuss

the point estimations with project team members. This collaborative technique builds greater
insight into scope definitions, underlying assumptions, and consensus regarding the level of
granularity required to manage the project.

Common pitfalls and misconceptions

A WBS is not an exhaustive list of work. It is instead a comprehensive classification of
project scope.
A WBS is not a project plan or a project schedule and it is not a chronological listing. It is
considered poor practice to construct a project schedule (e.g. using project management
software) before designing a proper WBS. This would be similar to scheduling the activities
of home construction before completing the house design. Without concentrating on planned
outcomes, it is very difficult to follow the 100% Rule at all levels of the WBS hierarchy.
A WBS is not an organizational hierarchy. Some practitioners make the mistake of creating a
WBS that shadows the organizational chart. While it is common for responsibility to be
assigned to organizational elements, a WBS that shadows the organizational structure is not
descriptive of the project scope and is not outcome-oriented. See also: responsibility
assignment matrix (also called a Staffing Matrix).
WBS updates, other than progressive elaboration of details, require formal change control.
This is another reason why a WBS should be outcome-oriented and not be prescriptive of
methods. Methods can, and do, change frequently, but changes in planned outcomes require a
higher degree of formality. If outcomes and actions are blended, change control may be too
rigid for actions and too informal for outcomes.

PRINCE2 Methodology
PRINCE2 (PRojects IN Controlled Environments) is a structured method for effective project
management. PRINCE2 is based on the experiences of scores of projects, project managers
and project teams, who have contributed, some from their mistakes or omissions, others from
their successes. PRINCE2 is a de facto standard used extensively by the UK government and
is widely recognised and used in the private sector, both in the UK and internationally.
PRINCE2 is in the public domain.
PBS - Product Breakdown Structure
This is the first step in product-based planning. Breaking down a product into its constituent
sub-products helps clarify and identify all necessary work for its creation. The objectives of
the step are: Identify the products required by the customers Identify additional products
needed to build and support the customer products Build a consensus on the best product
groupings that should be used to generate ideas on what products have to be created or
obtained A PRINCE2 project has two types of product: 1. The specialist products whose
development is the subject of the plan 2. The management products that will be required as
part of managing the project (e.g. Highlight Reports, End Stage Reports, Project Issues) and
as part of establishing and maintaining quality. All the products of the project need to be
drawn up in a hierarchical structure.
Practitioner Exam Tips: There must be no one-to-one product relationships There must not
be any arrows There must be at least three levels not including the top level product i.e. a
multiple level There must be at least two intermediate products: one integration product and
one collective group The projects final product should be at the top There must be at least
one simple, external product Ask Does this product consist of these products?.
PD - Product Description A description of a products purpose, composition, derivation and
quality criteria. It is produced at planning time, as soon as the need for the product is
identified. Product Descriptions may need to be updated if a change to a product is agreed.
Once approved, a Product Description should not be changed without passing through Change
Control.
PFD - Product Flow Diagram A diagram showing the sequence of production and
interdependencies of the products listed in a Product Breakdown Structure.
PID - Project Initiation Document A logical document which brings together the key
information needed to start the project on a sound basis and to convey that information to all
concerned with the project. Once approved at the end of the Initiation Stage, the Project
Initiation Document is frozen and used as a baseline to make key decisions upon during the
project. The most dynamic parts of the PID are: Project Plan, Business Case and Risk Log.
They will be updated at least at the end of each stage.
PL - Planning Planning is a repeatable process and plays an important role in other processes,
the main ones being: Planning an Initiation Stage (SU6) Planning a Project (IP2)
Planning a Stage (SB1) Updating a Project Plan (SB2) Accepting a Work Package (MP1)
Producing an Exception Plan (SB6). Apart from a plan, the process produces: A Product
Checklist, which is a table of the products to be produced by the work planned, with space for

planned and actual dates for delivery of draft, quality-checked and approved products The
Risk Log, updated with any risk situation changes made as a result of the planning activity.
Peer Review Specific reviews of a project or any of its products where personnel from within
the organisation and/or from other organisations carry out an independent assessment of the
project. Peer reviews can be done at any point within a project but are often used at stage-end
points.
Phase A part, section or segment of a project, similar in meaning to a PRINCE2 stage. The
key meaning of stage in PRINCE2 terms is the use of management stages, i.e. sections of the
project to which the Project Board only commits one at a time. A phase might be more
connected to a time slice, change of skills required or change of emphasis.
Planning Network A flow diagram showing the activities of a plan and their
interdependencies. The network shows each activitys duration, earliest start and finish times,
latest start and finish times and float.
Planning Quality (IP1) This process builds on the Project Approach defined in SU5 and
describes how quality will be achieved in the subsequent planning processes. The Project
Quality Plan will contain the results of Planning Quality (IP1) and will be an element of the
Project Initiation Document output from Assembling a PID (IP6).
Planning a Project (IP2) The process uses the common Planning (PL) process to produce the
Project Plan. The Project Plan becomes a major element of the Project Initiation Document.
Planning a Stage (SB1) The approaching end of the current stage triggers the process. The
main objective is to prepare a plan for the next stage of the project. The high-level summary
of the next stage is expanded from the Project Plan into sufficient detail that the Project
Manager will be able to control progress against it ona day-to-day basis. The Planning (PL)
process is used to develop the plan. The Stage Plan will need to be prepared in parallel with
any relevant team plans.
Planning an Initiation Stage (SU6) The Project Board needs to know what effort is required to
create the PID. The common Planning (PL) process will be used to create the initiation Stage
Plan.
Plans PRINCE2 offers a series of plan levels that can be tailored to the size and needs of a
project and an approach to planning based on products rather than activities. A plan is a
document, framed in accordance with a predefined scheme or method, describing how, when
and by whom a specific target or set of targets is to be achieved. A plan is a design of how
identified targets for deliverables; timescales, costs and quality can be met. Plans are the
backbone of the management information system required for any project. PRINCE2
proposes 3 levels of Plan: Project (mandatory); Stage (mandatory); and Team (optional). This
is to reflect the different levels of management involved in the project. All plans follow the
same structure and format. Exception plans should also follow the same format as other plans.
An Exception plan picks up from the current plan actuals to the end of that current plan.
PRINCE2 has a Product-based approach to planning and also includes activity planning. The
Project Board approve the Project Plan, Stage Plan and any Exception Plans. The Project
Manager approves all Team Plans. The Project Plan is updated at the end of every stage to
reflect progress already made and to show the impact of the next stage. Re-planning is needed
at Stage Boundaries and when Exceptions arise. The last task when creating a plan is to add

its narrative to explain the plan, any constraints on it, external dependencies, assumptions
made and the risks identified.
Post-Project Review - One or more reviews held after project closure to determine if the
expected benefits have been obtained. Also known as post-implementation review.
Post-Project Review Plan The purpose of the Post-Project Review Plan is to define for the
Executive how and when a measurement of the achievement of the project benefits can be
made. The plan is presented to the Executive at the end of the project. The plan has to cover
the effort to find out: - Whether the expected benefits of the product(s) have been realised Whether the product(s) has caused any problems in use. Each expected benefit has to be
assessed for the level of its achievement so far or any additional time needed for the benefit to
materialise. Use of the product may have brought unexpected side effects, either beneficial or
adverse. Time and effort have to be allowed to document explanations of why these side
effects were not foreseen. The plan must include time for recommendations on how to realise
or improve benefits or counter problems. The post-project review is planned as part of
Identifying Follow-on Actions (CP2), but the Executive is responsible for ensuring that the
review happens after the project has finished.
Practitioner Examination Typical Topics for Preparation and individual practical work:
Product-Based Planning Risk Analysis Business Case Controls Configuration
Management & Change Control Quality
Practitioner Level This level is aiming to measure whether a candidate would be able to apply
PRINCE2 to the running and managing of a project within an environment supporting
PRINCE2. To this end they need to exhibit the competence required for the Foundation
qualification, and show that they can apply and tune PRINCE2 to address the needs and
problems of a specific project scenario. Preparing a Project Brief (SU4) The project needs to
start with a reliable statement of requirements and expectation, to ensure it is based on
consistent and adequate information. Keep the Project Brief as small and high level as is
consistent with the decisions that need to be taken in Authorising Initiation (DP1). Process
That which must be done to bring about a particular outcome, in terms of information to be
gathered, decisions to be made and results that must be achieved. Producer This role
represents the creator(s) of a product that is the subject of a quality review. Typically, it will
be filled by the person who has produced the product or who has led the team responsible.
Producing an Exception Plan (SB6) The deviation should have been recognised during
Controlling a Stage (CS). The Project Manager will have brought the situation to the attention
of the Project Board through an Exception Report. The Project Board will have requested the
Project Manager to produce an Exception Plan. The Exception Plan will then be presented to
the Project Board at an Exception Assessment.
Product Checklist To list the products to be produced within a Stage Plan, together with key
status dates. Used by the Project Board to monitor progress. Extracted from the Product
Breakdown Structure. Produced as an output from Defining and Analysing Products (PL2)
and finalised in Completing a Plan (PL7). Product Status Account Information about the state
of products within defined limits. The limits can vary. For example, the report could cover the
entire project, a particular stage or a particular area of the project.
Product-based Planning This PRINCE2 technique enables the project to define the standard of
quality to which each product must conform. Define what the project has to deliver
Provide descriptions of the required products, the skills needed to develop the products, plus

measurable statements of the quality required and how the presence of that quality is to be
tested Objectively monitor and control progress. The sequence in which each product should
be produced and any dependencies. The Planning (PL) process is where the technique of
product-based planning is used. There are three steps to the product-based planning technique:
1. Producing a Product Breakdown Structure 2. Writing Product Descriptions 3. Producing a
Product Flow Diagram. Practitioner Exam Tips: Use product-based planning for Exception,
Project, Stage and Team Plans Do not use product-based planning for the Project Quality
Plan, Configuration Management Plan, Post-Project Review Plan or Communication Plan
Only include management products if requested External products (i.e. those outside the
scope of the project) should be shown in ellipses Identify at least 20 simple products, not
activities, for a 50 mark question.
Products A product maybe a tangible one such as a machine, a document or a piece of
software, or it may be intangible, such as a culture change or a different organisational
structure. Within PRINCE2 these are all called products. A product may itself be a collection
of other products. PRINCE2 distinguishes between management products (which are
produced as part of the management or quality processes of the project) and specialist
products (which are those products that make up the final deliverable). Programme A portfolio
of projects selected, planned and managed in a co-ordinated way. Project A management
environment that is created for the purpose of delivering one or more business products
according to a specified Business Case A temporary organisation that is needed to produce a
unique and predefined outcome or result at a prespecified time using predetermined resources
Project Approach To define the type of solution to be developed by the project and/or the
method of delivering that solution. It should also identify any environment into which the
solution must fit. Project Assurance The Project Board are responsible for Project Assurance.
They may choose to delegate it but they will remain responsible. If Project Assurance is
delegated, it has to be independent of the Project Manager. One Project Assurance
responsibility is to ensure the right people are being involved, for example in product creation
and quality checking. Project Board There are three project interests that need to be
represented on the Project Board at all times, which are: Business, User and Supplier. The
Project Board are the owners of the project. The Project Board is the projects voice to the
outside world. The Project Board is not a democracy ruled by votes; the Executive is the key
decision maker, with advice and support from the Senior User and Senior Supplier.
The Project Board must also monitor the environment outside the project and bring to the
notice of those concerned, such as the Project Manager, any changes that affect the project.
Major Controls of the Project Board are: Project Initiation, End Stage Assessments, Highlight
Reports, Stage Level Tolerance, Exception Reports, Exception Assessments and Project
Closure.
Project Brief A description of what the project is to do; a refined and extended version of the
Project Mandate, which has been agreed by the Project Board and which is input to project
initiation. Project Closure Notification Advice from the Project Board to inform the host
location that the project resources can be disbanded and support services, such as space,
equipment and access, demobilised. Project Closure Recommendation Notification prepared
by the Project Manager for the Project Board to send (when the board is satisfied that the
project can be closed) to any organisation that has supplied facilities to the project. Project
Document Management Three main files are suggested by PRINCE2 Project, Stage and
Quality With sensible design,computerised support can avoid the need for multiple copies and
ensure that staff have access to only the latest version of information. Remember that filesdo

not necessarily mean paper. The project files will cover a wide range of media, all of which
need to be considered. Project File Filing under the Project file will include: The PID, Project
Plan, Risk Log, Business Case, Organisation Structure, Controls, Communications Plan.
Project Issue Project Issues can be about anything to do with the project. PRINCE2 uses the
same approach (Change Control) to capture all Change Requests, Off-Specifications and
any general issues, new risks, questions, concerns, good ideas etc. All such things are treated
and captured as Project Issues. Issues can impact existing risks and create new risks, therefore
the Risk Log should be examined along side project issues and updated where necessary.
Project Management The planning, monitoring and control of all aspects of the project and the
motivation of all those involved in it to achieve the project objectives on time and to the
specified cost, quality and performance. Project Management Team A term to represent the
entire management structure of Project Board, Project Manager, plus any Team Manager,
Project Assurance and Project Support roles. Project Manager The person given the authority
and responsibility to manage the project on a day-to-day basis to deliver the required products
within the constraints agreed with the Project Board. The Project Manager is responsible for
producing a result that is capable of achieving the benefits defined in the Project Initiation
Document.
Project Mandate The Project Mandate contains information created externally to the project,
which forms the terms of reference and is used to start up the PRINCE2 project. The Project
Mandate should contain at least some basic elements of the Business Case. It will be used to
create the Project Brief. The Project Mandate may take a variety of forms. Essentially any
trigger will suffice - the concept of the Project Mandate recognises that there has to be some
stimulus to get the project into play!
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 Project Initiation
Document. 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. It is used by
the Project Board as a baseline against which to monitor project progress and cost stage by
stage.
Project Quality Plan A plan defining the key quality criteria, quality control and audit
processes to be applied to project management and specialist work in the PRINCE2 project. It
will be part of the text in the PID. The planning function includes the creation of the
Configuration Management Plan, which forms part of the Project Quality Plan. It is produced
as an output from Planning Quality (IP1). Project Records A collection of all approved
management, specialist and quality products and other material, which is necessary to provide
an auditable record of the project. NB This does not include working files. Project Start-up
Notification Advice to the host location that the project is about to start and requesting any
required Project Support services. Project Support Office A group set up to provide certain
administrative services to the Project Manager. Often the group provides its services to many
projects in parallel.