Gerente de Proyectos

Project Management
Compendium
Content
1.
Introduction ............................................................................................................... 3
1.1 What is a project? ................................................................................................... 3
1.2 What makes projects successful? .......................................................................... 5
1.3 Context of project management.............................................................................. 6
1.4 Project management knowledge areas................................................................... 8
1.5 Phases & processes of projects ........................................................................... 10
2. Project initiation and project charter ........................................................................ 12
3. Project definition (project scope statement) ............................................................ 16
4. Stakeholder management ....................................................................................... 20
5. Work Breakdown Structure ..................................................................................... 23
6. Roles and responsibilities in the project .................................................................. 27
7. Scheduling .............................................................................................................. 30
7.1 Network plan......................................................................................................... 30
7.2 Bar charts & milestones ........................................................................................ 33
8. Planning resources ................................................................................................. 34
9. Cost planning and budgeting .................................................................................. 36
10. Quality management ............................................................................................ 39
11. Communications management ............................................................................. 41
12. Risk management ................................................................................................ 46
13. Plan integration in project management ............................................................... 51
14. Project execution .................................................................................................. 52
15. Project controlling ................................................................................................. 54
15.1 Milestone trend analysis (MTA) .......................................................................... 56
15.2 Earned value management................................................................................. 57
15.3 Status reports and reporting ............................................................................... 60
15.4 Issue log (open aspects or so-called "action item log")....................................... 64
15.6 Change management ......................................................................................... 65
15.7 Configuration management ................................................................................ 69
16. Project closure...................................................................................................... 71
/ PROJECT MANAGEMENT COMPENDIUM / 2
1. Introduction
1.1 What is a project?
We all know it: Just because something is called a project, it not necessarily is a project.
In our daily work we are confronted with tasks that are called projects but really are not.
In principle this is not a big deal since the term is not protected. However, it does
become problematic if one tries to crack nuts with a sledgehammer by handling trivial
routine tasks with the help of a complex project management method that does not
unfold its full effect unless used for rather complex tasks. This would be totally inefficient.
It is even worse taking on real projects without the necessary planning, controlling and
reviewing as well as without appropriate responsibilities. This, too, is totally inefficient:
one loses sight of the big picture, results are ignored or are duplicated, and wasting time
is the consequence. And due to the lack of proper clarification of the assignment, it may
be pure coincidence if objectives are actually achieved at the end, meeting the
expectations of external or internal customers.
Therefore, it is worth checking, prior to starting the work, whether the task actually is a
project and thus requires certain work processes. Or whether the task may not be better
handled or completed in a different way.
So, let's start with a simple yet central question: what is a project?
"A project is a temporary endeavour undertaken to create a unique product or
service" (PMBOK Guide, p. 5)
Typical characteristics and features of projects are:
limited in time, each project has a set start and completion date;
clearly defined objective;
unique, the created product or service is different from any before (high degree of
novelty);
complex;
often very important for the implementing company;
cross functional, usually realized by more than one department or division;
progressive elaboration, proceeding in repeating steps, plan and content are
advanced in more detail over the course of the project;
limited resources;
associated with risks (due to being future-oriented and complex).
If it is clear based on aforementioned criteria that a certain task is a project, methods
and instruments of project management come into play.
For project management methods there are a number of so-called project management
standards:
PM method Prince2
(standard) (projects in
controlled
Criteria
environments)
PMBOK
(project
management
body of
knowledge)
ICB (IPMA
competence
baseline)
CMMI
(capability
maturity
model
integration)
V-Model XT (vshaped project

model, extreme
tailoring)
Issuer
Office of
Government
Commerce (GB)
Project
Management
Institute (USA)
International
Project
Management
Association
(CH) with
national
country
organizations
(e.g. GPM Gesellschaft
fr Projekt
Management,
Germany)
Software
Engineering
Institute (SEI)
Carnegie
Mellon
University
(USA)
Office of the
federal
government for
coordinating and
supporting
information
technology in the
federal
administration
[Koordinierungsund
Beratungsstelle
der
Bundesregierung
fr Informationstechnik in der
Bundesverwaltung
(KBSt)], (D)
Type of method
Process model
Best practice
model with
processes and
knowledge
areas
Competence
Maturity model
and capabilities
model
Flow model
Content in
focus
Methods for PM
Methods for
PM
Methods for
PM
Best practices
for PM and for
system
development
Approach to PM
and system
development
Regional focus
Standard for
British
government,
general standard
in GB and
popular in NL
Worldwide,
ANSI standard
(USA)
Europe
Worldwide
Standard for
administration and
defence project of
German
government
Divisional and
field of
application
focus
IT industry
Generic
approach,
popular in all
industries
Generic
approach,
popular in all
industries
Larger
organizations
with
development
projects
Larger
organizations with
development
projects
A project management method always includes a plan for the management of projects
and a guideline for the cooperation of project teams.
It is a collection of processes, methods and tools, and it provides a checklist of activities
and so-called key deliverables which are the decisive and important results
"delivered" by a project.
They help us to avoid important project tasks being forgotten.
Project teams that do not use a common method tend to be inefficient, which results in
higher costs, longer schedules and higher risks.
Even if the project management method influences the entire team, the project manager,
in its leading role, is the person ultimately responsible and most affected by the method.
Usually, the method is prescribed by the organization.
Project management methods differ from system development and product management
methods: These refer to product-specific needs and define certain phases and activities
over the entire life cycle. In contrast, project management is "the application of
knowledge, capabilities, tools & methods for meeting project requirements" 2) or
for achieving the objectives as defined within the project.
The following remarks provide a practical overview based on the PMBOK Guide
(project management body of knowledge), the international standard of the PMI
(Project Management Institute).
1.2 What makes projects successful?

All empirical studies of the past few years come to the conclusion that only a relatively
small portion of all projects (approx. 30 %) may be considered as successful. This
means that 70 % of all projects are in trouble and do partially or completely fail.
A study by Price Waterhouse Coopers from 2009 even alleges that only 2.5 % of
surveyed organizations are able to successfully complete all of their projects in terms of
achieving their defined objectives in time and in budget.
The ability to successfully manage projects partially depends on the maturity level of an
organization. The maturity level depends on the degree to which project management
and business processes are integrated as well as measured and controlled in terms of
quantity. The highest level of maturity is reached if all processes are continuously
improved.
On the other hand, project success depends on factors that can be influenced by project
managers, their team, the project sponsor, the customer and other directly or indirectly
involved stakeholders in the project.
Typical factors are:

Clearly defined project objectives
Consistent project management and leadership
Consistent stakeholder management
Gaining support through management
- Involve users
- Clear and intensive communication with customers
- Clear business objectives
Experienced project manager and competent project team
Stable customer and project requirements
Each individual element can, if handled improperly or if missing, lead to project failure.
1.3 Context of project management

How do projects arise?
Projects generally arise because there are internal or external changes that affect
corporate objectives and consequently imply the necessity of adjusting or changing
business processes.
This is the answer to the question "WHY" a project should be implemented. There are
many reasons for the initiation of a project:
Market potential that is to be tapped and maximized, requests by a large customer,
technological advantages, new legal requirements [...]
Ultimately, the level of success is decided by the project's contribution to achieving
corporate objectives. An example shall illustrate this: Lets assume the respective project
is a website on which the customers of an energy utility company can enter their meter
readings. Our project was just completed and we delivered a technically sound and
trouble-free solution. After a few weeks we determine that only very few customers have
used the new portal. Success or failure? The answer is obvious, as are the missing
success criteria in our example:
These include ways and means to measure the number of meter readings entered per
day - two weeks, four weeks, and three months after the implementation of the website.
And this would allow deriving measures directly aiming at the achievement of these
critical success factors.
This exact contribution to the corporate objectives is the operationalization based on the
project objectives that are to be defined in the initiation and planning phases of the
project. Project management is concerned with the question "WHAT" must be done to
achieve the corporate objectives and "WHO" must do it.
The process model of the project management differentiates between 5 so-called

process groups:
Initiation
Planning
Execution
Controlling
Closure
Implementation, the concrete "HOW", is part of the project process. The concrete
physically measurable result of the project (deliverable) is thus created or developed.
The context of the project management illustrates that strategies are realized and
implemented using projects. In this context two additional aspects are important:
programs and portfolios.
Programs are long-term tasks that consist

of a number of related projects.
They have a strategic direction and are
combined based on objectives or function
(e.g. program for innovation or program for
increasing competitiveness).
Several projects are coordinated jointly,
which results in advantages or synergies
compared to isolated separate controlling of
individual projects.
The project portfolio refers to the sum of
all projects and programs of a company (or
division) at time x.
The portfolio changes constantly and is also constantly adjusted (according to the
planning cycle of the company). It prioritizes new and current projects, coordinates the
projects in terms of resources, synergies and conflicts as well as evaluates new
projects/ideas based on opportunities, risks and strategic importance for the company.
The management of the project portfolio has the objective of realizing the right projects
at the right time and in the right environment (selection).
The different perspectives adopted respectively by of portfolio and project managers are
illustrated by the following diagram:
1.4 Project management knowledge areas
Project management includes the following knowledge areas:

Scope Management...
... defines, what is part of the project and what is not. Scope management identifies the
limits of the project, which results or products (deliverables) are executed over the
course of the project. It also defines the work packages that must be implemented for
the completion of the deliverables.
Time management...
... describes all processes in terms of punctual completion of the project: definition of
activities, dependencies (order), estimation of resource and time requirements,
development and controlling of the schedule.
Cost management...
... describes the estimation of all relevant costs and the development and controlling of
the project budget.
Quality management...
... describes processes that ensure project and project results meeting the requirements
of the stakeholders.
Human resources management...
... refers to the processes of the project team organization as well as management and
leadership of the project team.
Communications management
... describes the processes required for the distribution of project information.
Risk management...
...identifies and analyzes risks & opportunities as well as possible coping strategies.
Procurement management...
... includes purchase and procurement planning as well as contract management.
Integration management...
... integrates all partial plans into an encompassing and consistent project management
plan, controls and reviews the overall project (incl. change management/change control).
1.5 Phases & processes of projects

Project phases
Phases refer to the different consecutive sections of a project. In their totality, they
describe the life cycle of the project. The phases break down the whole project in
smaller, more easily manageable parts.
Characteristics of phases:
they consist of separate tasks;
they have clearly defined objectives (milestones of the project);
their scope is defined sufficiently and clearly;
they produce a comprehensible and measurable result (deliverable) that is reviewed at
the end of the phase;
the end of a phase is generally a milestone;
On the basis of this review the decision is made, whether the next phase can begin; or
the phase must be repeated in part or in whole; or
the entire project is aborted und terminated.
The approach described above is referred to as gate review.

Course, sequence, content and name of the phases depend on industry and function of
the project.
Project life cycle system development
Project processes
Any and all project management processes are to be assigned to one of the five
consecutive process groups:
Initiation: The project is defined and approved.
Planning: Defines the project management plan (the project manual) in which the
implementation is described.
Execution: Executes that which is described in the project management plan.
Monitoring and controlling: Project status and project progress are monitored and
measured.
Closure: The project or phase ends and is formally closed with the acceptance of
project deliverables.
The process groups have clear dependencies and must be realized in each project in an
identical order, independently of the application area or the particularities of the applied
project life cycle. In each phase of the project, all project groups are passed.
Project management is an iterative process: it can monitor itself and becomes more and
more exact and detailed over the course of the project (rolling wave planning).
The following diagram shows the process groups with their dependencies (simplified) as
well as the respective project management processes:
2. Project initiation and project

charter
Project initiation is the process of formal authorization of a new project or the beginning
of a new phase within an ongoing project.
Projects arise through changes in the environment of the company or through the
implementation of corporate objectives and strategies. Typical events that may initiate a
project are, for example:
a new market or customer need

a customer request
a corporate objective
taking advantage of a technical edge
a legislative amendment
For large projects the initiation phase itself is a project. The main aspect is presenting
and arguing why and with what economic consequences a project should be
implemented (feasibility and preliminary study).
The end result of the initiation phase is the project assignment (project description or
project charter) and the naming of the responsible project manager.
Besides the project background, the project charter also contains
corporate objectives,
project objectives and
critical success factors.
All these data must be phrased SMART - which means:
Specific
Measurable
Attainable
Relevant
Timely
Project objectives in this phase generally include economic objectives (e.g. a business
case) and a rough schedule (milestones). Additionally, an initial risk evaluation and the
composition of project management or the planning team as well as the subsequent
project organization may be part of this phase.
Included are also:

constraints/limitations (anything limiting the freedom of action of the project team) as
well as
valid assumptions (everything the project team considers to be given at a point in
time).
Project limitations are usually based on the so-called "magical triangle".
Originally, this involves the competing requirements of scope (content and scale), time
and cost, which are to be kept in balance by project manager and project team.
Nowadays, this process does not merely involve three but six constraints. The element,
however, remains to be called "triple constraint".
All variables are interdependent. If, for example, the time component changes, this
affects costs, scope, quality and risks.
The competing objectives must be balanced such that customer satisfaction is achieved.
To make this possible, not all of the elements of the triple constraint may be fixed by the
client or customer but only one or two.
If too many components are fixed, balancing is impossible. The project can in fact not be
managed.
Practical advice:
Scrutinize any possible constraints issued by the client or customer.
Use the "triple constraint" as a checklist and create margins to work with.
The fewer constraints are documented in the project assignment the better.
In parallel with the approval of the project charter, the project manager must be
nominated.
What does the project charter mean in practice?
At first, no project should exist without an approved charter or approved project
assignment. Because only if this document is approved by management or the project
sponsor, the project will enter the next phase planning and the project manager may
use the necessary resources for that phase.
The purpose of the document: Project and project manager are officially "authorized".
This way, the project manager actually gains authority, which would not be the case
without the project assignment. The project manager receives the binding commitment
from management to support the project in the future. The point is the so-called
"management sponsorship" and the "buy in" of all relevant stakeholders.
Practical advice:
Develop the project charter together with the core team (all participants who later will
contribute important parts to the project and take on responsibilities) during the kick-off
meeting.
Once the document is approved, communicate and spread the information in your
organization, so that as many stakeholders as possible will know of your project.
The project charter is the birth certificate of the project and makes it known within the
company. Only "chartered" projects are projects!
Project charter (project description/assignment)

Background information on the project
Information and reasons that led to the project.
Corporate objectives of the project

Corporate objectives associated with the project or to be achieved with the help of the
project.
Project objectives
Main objectives of the project. These are refined in subsequent documents.
Critical success factors

These determine how to measure project success from a business point of view. Often
times these are minimum objectives or prerequisites to the achievement of corporate
objectives.
Limitations
Anything that limits the options of the project team.
Assumptions
Factors that are assumed to be given or true even though they are not (yet) certain.
Project responsibilities
Project manager, members of the core team, project sponsor
3. Project definition (project

scope statement)
Upon approval of the project assignment (project charter) the project initiation phase is
completed and planning begins. The planning phase begins with the area scope (content
and scale of the project) and in a sense represents the "answer" of the project manager
to the project assignment. The total knowledge area scope management includes the
following elements:
The project definition or the so-called scope statement documents and describes the
concrete result of the project that is the product to be delivered to the client in the end
(deliverables), be it a technical solution, a study or an analysis or the verification of a
hypothesis. Additionally, project content is described: the total work that must be done to
create defined results/deliverables. The scope statement can thus be considered the list
of obligations for the entire project, not only for the specification of requirements by
customer or client.
The simple and pragmatic structure of a project definition is briefly described below:
Project objectives
Project objectives from the project charter are refined here and described from the point
of view of the project manager
Project results
What shall be delivered in the end as a concrete, comprehensible and measurable
result? (products, "deliverables")
Project content
Concrete description of what is being done and what are the issues (activities,
processes)
Acceptance criteria
This is a list of acceptance criteria for the product(s).
Project boundaries
This is a list of aspects not part of the project.
Constraints (update)
Anything that limits the options of the project team and that cannot be influenced by the
project team.
Assumptions (update)
Factors that are assumed to be given or true for planning purposes. Assumptions must
be validated over the course of the process.
Practical advice:
First, write down project objectives from your point of view. Show how you understand
the project charter and what you made of it. You should never simply assume the
objectives of the project assignment without scrutiny.
Then, define the important project results that you will deliver to the customer or client
during the project (at the end of each project phase) or at the end of the project: what will
be delivered as physically tangible and measurable "product"? What you will get from
this activity is a list of your deliverables.
In the second step you ask yourself, what must be done (work, process steps) to create
the listed deliverables. Those are the project contents. You will see that with this
approach deliverables are "taken apart" into smaller parts. If you continue to do this until
you reach a level of work packages, you will have taken the scope statement and turned
it into a work breakdown structure - the so-called work breakdown structure (see chapter
5).
A scope statement can, of course, also be more detailed and more extensive than the
"minimum version" described above. The following diagram shows typical contents:
Additional best practices are:
The description of content and scope must clearly define what is part of the project
and what is not. When in doubt, all project-related processes, activities, systems and
other issues not part of the content and scale (scope) must be identified.
Review whether project content, project results and project objectives coincide.
The scope statement should be written in a clear, unambiguous way in the language
of the customer or client. Words and statements requiring evaluation or allowing
interpretation should be avoided.
The scope statement should be reviewed by all relevant stakeholders and receive their
consent.
A clearly defined project definition (scope statement) is the basis for project
success!
4. Stakeholder management
So-called stakeholders are all those actively involved in project processes or people and
organizations influenced by project processes.
Stakeholder analysis helps the project manager determining the social environment of a
project, identifying participants/people involved and managing accordingly.
With this instrument the different stakeholders and their influences and interests are
identified.
Furthermore, their wishes, needs and expectations are documented.
The analysis provides an answer to the questions:
Who is involved?
Who has what attitude towards the project?
What relationships do the stakeholders have among each other?
What must I do as a project manager to reach out to certain stakeholders and bring
them aboard?
The overall communications plan with its measures is based on the knowledge gained
from the stakeholder analysis and derived activities.
Advantages of the analysis:
The advancement of the stakeholders from their current roles to, for example, a target
role, can be done in a consistent and comprehensible way. The stakeholder analysis
is dynamic, i.e. roles and attitudes are subject to change.
New team members who join in during the course of the project can quickly adapt to
the communications structure.
Risks are detected early and counter measures can be planned.
The stakeholder analysis is a team-internal and highly confidential document!
Concrete approach to the stakeholder analysis:
Identification of all relevant stakeholders with names and function

Graphic illustration (e.g. sociogram):
- close relationship to the project = close placement
- less relationship to the project = placement in corresponding distance
Issuance of concrete roles, as they are currently perceived
drawing of relationship lines between project team, Stakeholder and the project
- grey = neutral/unknown relationship
- red = negative relationship
- green = positive
Consequences and measures to be derived from the analysis
Development of an - initial or preliminary - communications plan to manage
stakeholders and their expectations
Sociogram
Practical advice:
Of course, detecting project obstacles and managing them appropriately is important.
However, it is just as important to gather your allies and utilize them to the advantage of
the project.
Stakeholder management is relationship management. And that also and primarily works
indirectly!
As already explained above, the stakeholder analysis is a dynamic instrument and is first
used in the initiation phase and over and over again thereafter. We use the analysis to
define the requirements of the stakeholders for our project as well as for project
communication.
5. Work Breakdown Structure

The next step is the preparation of a work breakdown structure. The work breakdown
structure (WBS) is the "heart" of the project plan and the central element of project
management. It defines what must be done to generate the project results and the
content listed in the scope statement. What work packages are required?
The objective of this decomposition of project results in smaller parts is:
1. Transparency of the project (what must really be done?)
2. Decomposition makes parts/components of the project easier to handle and manage
3. Links between parts of the project become more obvious
4. The WBS is the basis for further planning and project controlling
Steps for developing the work breakdown structure (WBS):

1.
2.
3.
4.
5.
6.
Starting points are the defined results (major deliverables) and contents of the list of
obligations (scope statement).
Further decomposition can be done based on both results and deliverables (objects)
or based on process steps and phases. On the first level of the WBS there quite often
is a structure based on sub-projects.
All WBS elements that were generated by decomposing a higher level jointly describe
the same scope as the higher level, but with a higher degree of details.
Each WBS element is only associated with one other WBS element of the next higher
level.
The WBS is sufficiently detailed to be able to detect interdependencies between WBS
elements.
The lowest level of the WBS in each line of elements is called work package.
The WBS has different degrees of details, i.e. work packages exist on different levels
of the WBS, depending on size, complexity, familiarity and similarity with previous
projects.
8. Additionally, WBS elements placed and executed in the distant future (more than 6
months) are less detailed than elements in the near future to be executed in the shortterm (rolling wave planning).
9. WBS elements that are delivered by an external party as part of procurement must be
exactly in line with the elements in the WBS of the external party.
10. Each work package or higher WBS level has a clearly defined deliverable.
11. The WBS is developed or at least reviewed by the respective experts who later
execute the work packages.
7.
Work packages
A work package defines a clearly outlined sub-task of the overall project.
It describes:
what is to be done;
what result is to be achieved (deliverables);
what expenses are involved (person days or PD --> basis for cost estimate);
and within what period of time (work days or WD --> basis for scheduling) the project
will be completed.
Additionally, it is also important that:

there is only one person responsible for each work package
there is a clear distinction to other work packages
processing should mostly be possible independent of other work packages
The size of work packages measured in work hours varies greatly in practice depending
on project and subject area. The scope of a work package ranges on average from 80100 work hours to 800 work hours.
Work package descriptions
For each work package a description is prepared by the respective responsible officer.
This way the work packages from the work breakdown structure are defined and
structured (activity level) in more detail and estimates are made in terms of required
time, resources (effort) and cost. The totality of all work package descriptions is
illustrated by the WBS dictionary (work breakdown structure dictionary).
Estimate of required efforts, time and costs

The estimation of the required efforts, time and costs for each work package or activity
or task is the first step into quantitative project planning. First of all, it is important to
clearly differentiate between these three categories.
Efforts refer to the amount of work needed to carry out a task or work package. Efforts
are measured in hours or person days. We need this information as a basis for the
assignment of resources or skills and for the determination of costs.
The estimation process involves answering the following questions:
How big are the efforts (in hours of days) for an activity, and not how long does it
take?
How many resources are required? How many are available?
Are resources available full time or part time?
What skills, knowledge and experiences are required?
What assumptions and limitations build the foundation?
What are possible risks?
The required time is the calendar time needed from start to finish implementing a work
package. Duration is measured in calendar days or in working days.
The required time always depends on the following variables:
Efforts
Productivity factors
Availability of resources
Work calendar
Costs for a work package include personnel and material costs, costs for equipment and
machinery, travel expenses, overhead as well as special categories such as provisions
for inflation costs and risks. Costs are always a function of efforts per resource and time.
For the estimation of required time, efforts and costs the following methods are used, at
times in combination:
Analogue estimate (top down):

Estimates are based on actual data of similar previous projects. This method requires
corresponding experience and expertise. A work package or a larger WBS element is
estimated as a whole (top-down).
This estimate is usually performed quickly and easily; however, it is less accurate. This
is particularly useful during early stages of the project to get quick but useful results.
Bottom-up estimate:
Work packages are decomposed into individual activities and procedures. Each single
element is estimated and subsequently aggregated. This method of estimation is
accurate but time-consuming. It is used to gain definitive and realistic data during the
planning phase or at the beginning of each project phase.
Three point estimate:

For any work package or activity three values are added up and subsequently divided
by three: an optimistic estimate, a probable estimate and a pessimistic estimate. For
example:
Time required for an activity (D) = (10 + 13 + 19)/3 = 42/3 = 14 days.
Very popular in this context is the so-called PERT method, which delivers a weighted
estimate:
Time required for an activity (D) = (10 + 4x13 + 19)/6 = 81/6 = 13.5 days.
Parametric estimate:
For any work package or activity an estimate is determined per unit, e.g. per sqm,
work station, etc. Time required is then calculated based on this per unit estimate.
The complete and detailed work breakdown structure is the central element in
project management!
6. Roles and responsibilities in

the project
The basic organizational structure of a project generally follows this format:
Project managers are "spiders in the web" and play a central role. They are in charge of
ensuring that project objectives are achieved. This responsibility comprises certain
competencies:
Project leaders/managers integrate the different sub-plans into a coherent project
management plan. They must be able to deal with unrealistic demands and competing
objectives of the different stakeholders (content and scope, quality, schedule, etc.).
This includes the ability as well as the formal competence to be able to say "no". They
will be made responsible for both achieving the project objectives as well as failing to
achieve the objectives.
They lead and control the planning process, take over regular monitoring and provide
support during the implementation of the project. All of this is done actively and in a
forward-thinking manner: project managers initiate, the project team executes.
Project manager
initiates
Project team
executes
The project manager should be nominated as early as possible, ideally upon or better
even before approval of the project.
What the project manager must definitely bring to the table are
Management skills: leading, motivating, communicating, solving conflicts
Methods and knowledge areas of project management
Product and industry knowledge, business competence
Intercultural management skills, language skills
What is not necessarily required is specific deep product knowledge and detailed
technical knowledge for problem solving.
Other important project roles are depicted in the following diagram:
In terms of role assignments during project implementation it may be useful to

differentiate roles by the following additional criteria:
R = Responsible: these are personnel who are "responsible" for actually executing work
packages, i.e. the resources
A = Accountable: those who monitor work packages and get credited for success as
well as take responsibility for failure.
C = Consulted: those whose opinion is important and who deliver relevant input and
information.
I = Informed: those who are being informed about progress and results of the work
package because they need the information for their area of responsibility.
V = Verify: those who verify whether the deliverables of a work package meet previously
defined objectives (e.g. acceptance criteria).
S = Sign-off: those who approve the handing over of deliverables or work packages.
Another typical and very popular scheme is
R
= responsible
A
= assistance
I
= to be informed
It defines minimum requirements for the assignment of roles or people and work
packages: who is responsible (in terms of "accountable"), who works as a resource or
important source of input and how is the flow of information in the project?
7. Scheduling
7.1 Network plan
After having agreed on the work breakdown structure with the client and the persons
responsible for work packages, you can prepare a schedule in form of a network plan to
define the concrete order of work packages or activities in the project.
As is the case for almost all project management techniques, the following principle
applies: we differentiate between first draft and subsequent optimization.
Orthodox project managers go from the assumption that only purely technical
interdependencies between work packages are defined in the first step.
What they mean is that the basis for any further planning should be a logical
arrangement of work packages that must be stuck to in either case. For example, you
can only begin eating after cooking is complete - no matter how many cooks are
involved and who is invited for dinner. Or you only begin replacing spark plugs once the
hood is opened and secured. This is what is meant by technical interdependencies and
this is the one important task during the preparation of the network plan.
The most commonly used illustration of network plans in practice describes an activity or
work package as "node"; interdependencies are illustrated using arrows (activity on node
- AON).
There are the following logical interdependencies:
A typical procedure or activity node looks as follows:

Earliest start (ES)
Free buffer
Earliest end (EE)
Duration
Work package no. (activity, procedure)
Latest start (LS)
Total buffer
Latest end (LE)
Calculation of critical path

The calculation of the network plan is usually done with the help of a software tool.
Errors in the interdependencies, however, cannot be detected or corrected by any
software or other aides.
Critical path: the longest duration from the beginning to the end of a project and at the
same time the shortest total duration of the project each delay on this path results in a
delay of the final deadline.
The calculation of the network plan is done in two mathematic procedures:

Forward pass: in the "forward pass" through the network plan one gets the earliest start
and earliest end for each procedure. Project start is either a given date or "0" on a
timeline.
Project start date is the earliest start of the first procedure
Earliest end of the procedure: EE = ES + duration
ES of the subsequent procedure = EE of preceding procedure
If a successor has several predecessors, the highest EE is to be taken as the ES of

the successor (end-start relationship)
Backward pass: the "backward pass" through the network plan beginning at the project
end results in the latest end (LE) and latest start (LS) for each procedure.
Project end is the value or date from the "forward pass". This equals the LE of the last
procedure.
Latest start of a procedure: LS = LE - duration
IF a predecessor has several successors, the lowest LS of the successors is to be
selected as the LE of the predecessor
There are no buffers on the critical path. Total buffers and free buffers of an activity are
= 0.
The total buffer reflects the number of days an activity can be delayed without delaying
the final project deadline.
It is determined by calculating the difference between latest end and earliest end (LE EE) or the difference between latest start and earliest start (LS - ES).
The free buffer of an activity shows how long the activity can be delayed without
affecting the earliest start of the successor.
Advantages to the network plan technique
Realistic calculation of end and intermediate deadlines
Immediate detection of critical procedures/activities
Complex interdependencies are illustrated in a simple and comprehensible way
The development of a network plan forces all participants to respect the logical
sequence in the project
The network plan is an important basis for determining the expected resource needs
For an effective project controlling, critical data must be known (procedures, critical
paths, alternative scenarios, ...)
Disadvantages to the network plan technique
The use of this technique has its price: it requires quite a bit of effort, which is often
unnecessary for smaller projects.
If the plan is too detailed, the network plan may become a tedious and annoying
venture.
A correct network plan is the first step towards keeping the deadline.
7.2 Bar charts & milestones

After you created a network plan, you transfer each individual procedure or work
package in sequence in a so-called Gantt Chart or bar chart.
On the vertical axis are work packages/activities; on the horizontal axis is a calendar.
And ready is your schedule.
Please be aware that this is the most optimistic schedule for your project. It represents
the absolute minimum time required to implement the project.
Important events or activities can be defined as milestones and thus steer the focus of
the different stakeholders to different items of interest.
For customers it is important when to expect preliminary results, when and which
important decisions must be made in the project or when a partial acceptance may be
made.
For the clients other points on the timeline are more important, and yet other
stakeholders pay attention to even different important interim results.
Milestones can be:
Begin - end of a project phase
Important results
Significant decisions
Monitoring and controlling of the course of project phases is done using milestone trend
analyses.
Detailed bar charts as basis for internal communication ( team), milestone plans
as basis for external communication (customer, stakeholder).
8. Planning resources
Based on the estimated effort and time required (schedule) for realizing the work
packages one can conclude the required resources for the project.
For the calculation of the network plan there already was an assumption of a certain
extent of tools/resources or employees to be utilized in the project.
However, work packages or procedures are at times parallel in the network plan, which
provides the first reason for potential resource bottlenecks: one and the same person is
to work on two different procedures at the same time - or one and the same machine is
to be utilized for two different work packages.
A second bottleneck may be the fact be that a resource may not be available, in full or
partially, at the time required according to the network plan. For whatever reason: be it
vacation, another project or daily business.
There also are required set-up times. Not only for machines but also for people. How
long does it take to switch from one task to another and be "fully immersed"?
This also includes the question of how we define availability of resources, in principle.
How many hours constitute a person day? Do we really work 8 hours a day?
A working day generally consists of 6 to 6.5 productive work hours.
Sometimes resources may be substituted, replaced by others, and the question is: for
what resources is this an option? Und where is this not an option?
On the other hand not all work packages are on a critical path, i.e. have a buffer, some
spare time, during which they can be moved without affecting the final project deadline.
All this is to be reflected in the resource plan. It is a plan, first, not a decision.
This means that we differentiate between planning and optimization. The plan shows the
need for resources based on the assumptions in the schedule. The subsequent
adjustment based on resource availability
through moving, stretching, compressing or parallelizing of procedures/work packages
signifies the optimization of the resource plan.
Practical advice:
Use the following steps to assign resources:
Determine which capabilities/skills are required for each procedure
Find suitable resources (e.g. in the resource pool)
Evaluate resource availability
Assign resources to specific procedures (resource loading)
Realize a resource levelling in case of overextended resources
Is your resource plan realistic?
What risks have you considered?
What alternatives are there?
Once you plan is complete:
- Request resources for the determined periods form the responsible line
manager
- Confirm resource assignment for the different procedures
9. Cost planning and budgeting

If you planned your project on a methodically sound basis up to this point, cost and
budget planning are a piece of cake, a mere logical consequence of the work done so
far. The budget follows as a result of the schedule as the sum of the cumulated
estimated costs of work packages or larger elements of the work breakdown structure.
This can also be done with a rolling plan. The cost estimates of current and near future
project phases are more accurate and detailed than those of the distant future. The
following diagram illustrates this point.
The S-line is characteristic for the shape of the cost baseline of the project. It shows that
most of the costs accrue during implementation of the project. In the earlier stages of the
project (initiation and planning) as well as at the end of the project, usually only few
costs accrue.
Each project is an investment and costs are part of any investment. The investor or
client wants to know what the project will cost. Even if a project is realized using only
one's own employees and no additional material, these employees could be doing some
other job instead or execute a different project. Even if preparing a cost-benefitanalysis is not one of your regular job duties, you have to deliver input to the simplest
form of an investment calculation the cost comparison evaluation i.e. actually

planned project costs.
If project team or project manager begins planning the costs for a project, a budget has
often already been defined, approved and set as default (e.g. during the budget planning
phase, for proposals, during contract negotiations with the customer). This budget
defines the upper limit for cost planning.
The detailed cost estimate begins with the preparation of the work breakdown structure
(see chapter 4.5.5), usually on a rolling basis.
Project costs can be posted and budgeted in various categories. The following table
provides an example.
Budget information
Work
package
Work days
(Effort)
Rate per
day
Work
costs
Material
costs
Costs for
equipme
nt
Travel
costs
Total costs
Total budget
Typical components of the project budget, in addition to cumulated planned costs of the
elements of the work breakdown structure, are management reserve (premium for
unforeseen risks, so-called "unknown unknowns") as well as risk reserve for identified
and evaluated risks (contingency reserve, so-called "known unknowns").
Based on the cumulated cost trend, necessary financing (requesting internal budgets or
invoicing and receiving external payment from customer) can be planned to cover
project costs.
10.
Quality management
The quality of projects is sometimes a strange thing: At the beginning of a project

nobody can really tell you what quality is and how it is supposed to look like. At the end
of the project everyone will tell you what project results had not been acceptable and
what expectations had not been fulfilled. This is why we first pose the question: what
exactly is quality?
Quality according to DIN is defined as...
"...the sum of all characteristics and features of a product or service that relate to
suitability in terms of fulfilling defined requirements."
For the quality in projects this means that the project results or the product of a project
must fulfil the requirements stipulated by the client or customer. The project definition
(scope statement, see chapter 4.4) must contain clearly defined and measurable quality
criteria that are also the basis for acceptance. Sometimes these criteria are difficult to
define because they are not even (yet) known to client. In those cases you as the project
manager must determine the criteria through an exact and detailed requirement
analysis.
Quality management in a project includes
Planning quality: In this process quality standards (quality objectives) are defined
that are relevant to the project. These include metrics (operational criteria) that define
how to correctly measure the quality of project results. Furthermore it is determined,
how or with what activities these standards are to be achieved.
Assuring quality: In this process the planned quality activities are performed and all
relevant processes are implemented to ensure that the project achieves defined
quality objectives.
Steering quality: In this process the quality of project results is measured and
determined, i.e. compared to quality objectives. Any errors or defects are identified
and resolved.
The focus of the quality management lies in prevention. This means all relevant
processes must be organized in such a way that they are exempt of any errors. Errors
should not even arise in the first place. This means quality is to be "planned into the
project" through early tests and audits.
By investing more in prevention, costs for errors can be reduced so that these
investments are really paying off. The concept of cost of quality illustrates this
correlation.
The results of the quality management are:

The costs for preventing errors (prevention costs) increase due to increased time
spent for these activities.
Costs for internal and external errors as well as for reviewing and evaluating (quality
control) are reduced over the long haul.
Internal errors provide the largest source of potential savings.
11. Communications
management
The exchange of information between project participants, especially within the project
team, is one of the decisive factors for success of project management. Despite all
technical aids which simplify communication, the key aspect remains the questions of
how far the different project participants are willing to pass on their experience and ask
for support when encountering problems.
In addition to verbal communication (telephone, email, letters) non-verbal
communication (body language, eye contact, voice, form, reaction time, etc.) also
passes on significant information about relationships or true intentions. Technical media
can, therefore, still not replace personal meetings during which the communicating
parties can experience each other as a whole.
Cultural differences can also result in considerable problems in communication, which
must be taken into consideration - especially for international projects.
Project managers spend up to 90% of their time with communication. This is not the
least important reasons why a systematic and structured approach to project
communication is key. Communication comprises the processes of
1. communication planning (based on the stakeholder analysis, see chapter 3)
2. distribution of information (providing stakeholders with timely and relevant
information)
3. performance reporting (status reports, measuring project progress, forecasts)
4. Stakeholder management
In addition to the methods used for the processes, the communicative abilities of project
manager and project team are of primary importance.
The following table shows an example of a section of a communications management
plan:
The communications management plan is based on the stakeholder analysis; it identifies

the communications requirements of the stakeholders.
The plan illustrates who must be informed about what and at what point in time as well
as how often.
It is adjusted, primarily, if the stakeholder analysis changes: new participants join in or
requirements change.
The communications plan is developed from the point of view of the project team with an
eye on the project stakeholders: what are their expectations and how can they be
controlled by the team?
Another important topic in project communication is the management of project
documentation. Here, many projects have their weaknesses. Typical situations in this
context are:
duplicate documents in the project directory
certain documents cannot be found
documents are stored on hard drives of team members
documents exist in various formats and are in part written in the author's native
language.
Document management is a fundamental aspect of larger projects. One of the first steps
during the planning of a project is the definition of management of storage of project
documents.
Project documents include all documents that are related to the project: e.g. background
information, templates, project plan documents, various general plans, progress
information and progress reports.
Recommended approach to document management
Determining where the documents should be stored: The team should have its own
project folder for documents (physical/electronic).
Definition of a folder structure: determining the storage location for different
documents.
Assignment of responsibility for document management in the project
Determining which documents must be filed in the project folder
Definition of names: defining a standard for naming documents so that it is
immediately obvious what type of information and, if applicable, what document
version is stored
Determining whether the different versions of documents are stored or whether only
the most current version is stored.
Determining whether the approval/release of documents is documented (for which
documents and how).
Identifying suitable standard documents/formats (templates) and creation of templates
(if not already available).
Defining which documents are archived.
Example of project filing
Kick-off meeting
The kick-off meeting takes place at the start of a project or project phase. The exact time
is not defined. A very early kick-off meeting primarily serves project management and
motivation for the project, while a rather late event is chosen, e.g. after the definition of
the list of obligations, if an agreement on the concrete start of the work and disclosure of
information to participants are the primary focus.
Objectives of the kick-off meeting may be:
Disclosure and discussion of project objectives
Highlighting the importance of the project
Gaining support for the project
Motivation of project participants
Information and agreement of all project participants about project plan
Agreement of project participants among one another regarding the start of work and
scheduling
Clarification of each other's expectations in terms of cooperation
Participants of the kick-off meeting should be:
Representatives of the client (for important projects management of the client)
Representatives of management of the firm realizing the project (again depending on
the importance of the project)
Project manager
Core team
Other participants
Whether everyone participating in the project (i.e. including those only working in the
project for a short time) or only the important participants should be present at the kickoff meeting must be determined on a case by case basis. For fundamental business
projects it may be wise that even people not directly participating in the project take part
in the kick-off meeting since these are at least affected on the perimeter by and may also
profit from a successful project.
The kick-off meeting may consist of several different elements. It may, for example, be
limited to presentations for management (client, contractor, project management, etc.);
however, it may also actively involve the participants through workshops. For large
projects a kick-off meeting may even be followed by a press conference.
Practical advice:
6 principles for leading meetings
1. You always have a concrete reason for a meeting and prepare the meeting with a
written invitation and the respective topics we well as objectives and allotted time.
2. Each meeting starts and ends as planned.
3. Determine the keepers of minutes and time at the start. Especially for difficult
meetings it is recommended to involve a moderator who can visualize the results
during the meeting and provide the same in form of a picture protocol.
4. Any disturbances are forbidden: mobile phones, notebooks, etc. must be turned off.
5. No agenda item "other". It cannot be prepared for.
6. Each point of discussion or each topic is closed with an agreement and/or an activity
including assignment of responsibility and deadline; this is documented in the
(simultaneous) protocol and handed to all participants.
Minutes of meeting
Meeting
......................................................................
Date
......................................................................
Participants
......................................................................
cc
......................................................................
Topic
Activity/agreement
Responsible
With
Until/by Remarks
whom
12.
Risk management
Risk management is the part of project management that is concerned with the
identification, analysis and control of risks for the planned project implementation.
Uncertainties and risks are part of the characteristics of projects: these are possible
events through which objectives and course of the project may be negatively affected. A
project risk can be qualified in terms of probability, effects (delay, cost increase, quality
reduction) and caused damages. In many cases it is helpful to determine the root cause
of a risk. If we understand the cause, we can fight the potential risk more effectively. It is
just as helpful determining so-called "triggers" for risks. A trigger is an early warning sign
that announces the actual risk event.
The term "risk" also includes uncertain events with positive effects on objectives and
project course. Risks with positive consequences are called changes. To illustrate the
two sides of the term "risk" and how to deal with it, many organizations speak of risk
and chance management in this context. The following diagram shall illustrate these
terms:
The process of risk management should be an integral part of project management

activities and be applied already during project evaluation and selection phases. Risk
management is a continuous process that is applied in all phases of the project (i.e.
primarily during implementation) and that is not completed with the one-time risk and
chance evaluation during the planning phase.
Risk identification
The purpose of this step is the determination of all risks involved with the project (at least
as many as possible). Goal is a precise definition of the risks.
Experts are an important source for risk identification. Their knowledge must be tapped
and prepared for risk management through selective surveys (questionnaire, interviews,
dolphin method, etc).
In addition to the assessment by experts, experiences stored in so-called "lessons
learned" documents from other projects are a second source for detecting potential
risks.
The third source is the project team, which contributes to risk identification through a
whole plethora of methods and techniques: e.g. creativity techniques such as
brainstorming, brain writing or mind mapping, Ishikawa diagrams and SWOT analyses.
Practical advice:
A proven approach for risk identification:
Review and adjustment of risks identified during project initiation (project charter).
Verification of the stakeholder analysis, scope statement, work breakdown structure,
schedule, cost baseline, quality plan (if available) and communications plan.
Review of all assumptions and limitations.
Sifting through all collected experiences (lessons learned) of similar projects (as well
as documented risks)
Review of existing risk checklists
Interviews of experts
Organizing a workshop with a representative selection of project stakeholders. All
levels and disciplines should be represented in this group. In this workshop risks
should be identified jointly, e.g. by using creativity techniques.
Ensure the use of concrete and clear-cut wording when formulating risks. You must be
able to still unambiguously understand the documented risks without any room for
interpretation even weeks after the workshop.
Identified risks are documented in the risk register:
Risk analysis (assessment)

The purpose of the (qualitative) risk analysis is determining the probability of occurrence
for risks as well as effects of risks on cost, schedule and product quality/content.
On this basis a risk matrix can be used to assess what priority a risk is assigned. All
identified risks are entered into the matrix.
In its simplest form the risk matrix has a total of nine fields with the two axes, probability
of occurrence and effects, each being divided into the assessment categories low,
medium and high. A 5 x 5 matrix is also used quite often by expanding the categories
with the options very low and very high.
Practical advice:
If you add numerical values to the qualitative categories, e.g.
very low
=1
low
=2
medium
=3
high
=4
very high
=5
you can multiply the values for the axes and get a clear priority based on the size of the
risk value.
Risk management (deriving counter measures)

For the risks on the top right top risks with high priority measures should be
developed that reduce the probability of occurrence or the effects of the risks.
The following options are possible, in principle:
Risks with low probability of occurrence and low effects can be accepted and covered by
building reserves. You have two alternatives concerning acceptance strategies: you both
only react once the risk has occurred (passive) or you are proactive and develop a plan
ahead of time that comes into effect once the risk occurred (active).
Risk monitoring and control

The following activities are part of risk monitoring and control:
Permanent monitoring of early warning signs (triggers) and initiation of measures as

previously defined in the respective action plans (active acceptance), as required;
Review of documented risks and adjustment of their records in the risk register, if
necessary;
Identification and documentation of new risks and chances
as soon as they are noticeable;
Analysis of consequences of changes in risk status
to planned risk measures and adjustment, if necessary;
Initiation of suitable project adjustment proposals;
Verification whether risk strategies and measures were implemented as planned and
whether they are acceptable;
Implementation of risk audits as soon as the correctness of the current risk status or
the effectiveness of risk measures are in doubt;
Immediate escalation upon occurrence of risks of highest priority;
Reporting about significant changes of risks with high priority.
13. Plan integration in project

management
The combination of the above-mentioned plans and their intertwining documentation
form the project management plan or the project manual. It is a so-called "container"
document, a folder containing all previously created planning documents.
The project management plan is primarily used for large and complex projects. It
describes how the project is realized, controlled and monitored. Documented are:
project management processes (incl. methods & techniques, their "depth of

application" and dependencies) as selected by the project management team
the planned total cycle of the project ("lifecycle") with the different project phases
how changes are controlled and monitored over the course of the project
how configuration management is realized
what sub-plans intertwine in what way and how sub-plans are executed, controlled
and monitored:
- scope
- deadlines
- costs
- quality
- employee resources
- communication
- risks
- procurement
The project management plan is thus a "living object" and becomes more detailed and
precise with every iteration over the course of the project. This is true for the planning
phase as well as for the implementation of the project: approved changes often times
have significant effects on the project management plan. These plan updates allow for a
better and more accurate controlling and monitoring.
14.
Project execution
When the planning phase of a project is completed (the rolling plan, i.e. the detailed
planning over the entire course of the project obviously continues), the project team
begins with the implementation of project activities and the creation of planned work
results (deliverables) of the project.
The PMBOK Guide describes the associated project management processes:
topics are integrated project execution, implementation of quality assurance activities,
acquiring the necessary project team for each respective phase, project team
development, project team management, implementation of a communications plan
(information distribution), stakeholder management and the generation of supplier
requests and selection (procurement conduct).
Project execution means executing the project management plan. The probably most
basic principle in the project management plan is: plan the work and work the plan.
Everything is done that is included and described in the project definition (scope
statement) and in the work breakdown structure.
In terms of controlling, two essential aspects are added:
This concerns, for one thing, the implementation of approved changes (project
change control).
Changes in the project (change requests) always relate to the project management
plan (baseline) as agreed with the stakeholders.
These are, therefore, deliberate changes and updates to the plan that must be
executed accordingly. Later in this document we will explain in more detail what
change management means and how it works.
Also, all current data of the project must be recorded, processed and communicated
by the team to be able to execute an ongoing target/actual comparison for
reasonable project controlling. Such data includes, for example:
- Progress (status information)
- Work results that were completed and/or not completed
- Work packages or activities that have been started
- Work packages or activities that have been completed
- Quality objectives/standards that were achieved or not achieved
- Approved and/or used costs
- Rendered work, use of resources
- Recorded and documented lessons learned
- Degree of completion of work packages or activities currently being worked on.
Well-planned projects may have difficulties because the project manager and his
team do not really know the degree of completion of project results. Relevant data
are missing. This sometimes happens involuntarily but quite often is a result of
insufficient discipline.
15.
Project controlling
Project controlling refers to the monitoring and controlling of the project in all different
aspects. Project controlling is done right from the start up to the very end.
Monitoring comprises the comparison of plan and actual figures and the determination of
any variances.
A variance in this context is defined as a variance from the plan or objective.

The ongoing monitoring provides the project manager, project team and all stakeholders
with insights into the state of the project and identifies areas that require particular
attention.
In the second step there is controlling: what measures should be taken to eliminate the
variance and achieve the objective as planned?
Project controlling is based on the so-called "Deming Wheel" and is known as "PDCA
Principle" (Plan - Do - Check - Act):
PLAN: Define project objectives and create project management plan.
DO: Execute project management plan.
CHECK: Monitor and assess project progress in comparison with plan and
objectives; report about project progress.
ACT: Define and implement corrective and preventive measures.
Monitoring and controlling includes the following activities:

Comparing actual project progress with the project management plan.
Assessing progress / performance to determine whether corrective or preventive
measures are necessary as well as recommending and initiating such measures, if
necessary.
Monitoring project risks as well as identifying and steadily analyzing new risks,
developing counter measures and verifying their effectiveness.
Providing a correct and current basis of information about work results and products
(deliverables) and documenting them (especially with regard to approvals)
Providing prognoses based on current actual costs and deadlines.
Monitoring the implementation of approved changes.
Coaching of employees participating in the project
Coordinating the cooperation of stakeholders participating in the project or in
selected results
Making or escalating decisions
Informing and reporting
It is important for an effective project controlling that controlling processes and
guidelines are implemented and embedded in the organization. The controlling
processes of the organization have to meet the following criteria:
Uniform, comparable status and progress indicators for all projects
Regular reporting
Reports customized to target audience (not too much, not too little information)
Creation of a high transparency regarding the status of all projects of the organization
Covering the entire project life cycle
Early warnings about imminent problems in projects
Easy access of top management to relevant controlling information
Ultimately, the question is how reporting and approval processes are organized. Let's
look at reporting, first:
Generally, there is regular bottom-up
reporting in the organization (monthly,
in critical cases weekly) about the
project status. Each hierarchy level is
provided with the necessary level of
details regarding status/controlling
information.
When it comes to approval of
processes, the so-called Stage-GateModel is the rule. The Stage-GateModel divides a project into life cycle
phases. Gates are placed at the end of
each phase and serve as milestones.
Before a project team can tackle the tasks of the next phase, a decision is made at the
gate whether the project is to be continued (pending corrections, if necessary), paused
or cancelled.
The objective is to ensure a sound basis for entering the next phase by stopping or
adjusting projects that are subject to noteworthy deviations from the plan.
The monitoring of compliance with defined expectations for the completion of a phase as
well as the application of measures for risk reduction are important elements of this
process.
The following diagram provides an example.
Techniques used the most in project controlling are:

1. Milestone trend analysis
2. Earned value management
3. Status reports
4. Issue log (open aspects or so-called "action item log")
5. Change management
6. Configuration management
15.1 Milestone trend analysis (MTA)

The milestone trend analysis is a very effective method for monitoring project progress in
terms of content. Prerequisites are the definition of a sufficient number of milestones and
regular reporting dates at which planned milestones are reviewed. The milestone trend
diagram is one of the most important instruments of project controlling.
For the implementation the vertical axis of a rectangular coordination system is defined
as target time axis where milestones are recorded at the planned dates. The horizontal
axis represents the actual time line; here is where reporting periods are recorded. At
these dates the prospective completion dates are recorded for each milestone. For each
milestone there is a prognostic graph that ideally remains horizontal up to the angle
bisector. That is where target and actual dates coincide; the milestone is reached within
the planned period of time. If the graph is ascending (delay), milestones and angle
bisector are reached later. If the graph goes down, a milestone is reached earlier than
expected or planned.
The experienced project manager can derive certain insights into the future development
of the project from this progression and thus detect imminent problems in time. The
milestone trend analysis is of particular value since it is combining a review of achieved
results and a forecast of future accomplishments
15.2 Earned value management

The earned value analysis focuses on the assessment of project progress. The current
situation of deadlines and costs is illustrated through key indicators, namely:
Planned values - PV - or planned costs - PC;

Actual costs - AC;
Earned value - EV.
By monitoring the key indicators a trend analysis is made possible.

The earned value analysis describes a measuring system with which the actual project
progress can be determined and evaluated in relation to the planned objective. The
earned value (EV) is a measure for accomplished work at a given point in time.
The base is formed by the elements of the work breakdown structure (WBS) - generally
on the level of the work packages.
The key indicator EV answers the question: "what was achieved up to this point (what
work packages have been completed)?" - evaluated with the respective costs budgeted.
Planned value (PV)
Planned costs (PC) are defined at the beginning of the project in the work packages and
accumulated over the schedule.
This way there is a planned budget that may be used at any point in time. If these costs
are exceeded, the project runs the risk of exceeding the total budget at the end of the
project.
Another designation for the planned value is budgeted cost of work scheduled (BCWS).
Actual costs (AC)
Actual costs are recognized using the variable AC. All costs incurred up to a certain
point in time are added up.
Another designation for actual costs is actual costs of work performed (ACWP).
Earned value (EV)

The earned value is calculated in monetary value or other agreed metrics, such as
person days. It designates the amount for the work performed so far, evaluated on the
basis of planned costs.
It must be defined whether work packages are taken into account only if completed
100% (0 / 100 - rule) or if work packages with a completion ratio of only 50%, for
example, are already considered (50 / 50 - rule).
The EV thus represents the work progress / earned value of the respective total value of
the project.
Another designation is budgeted costs of work performed (BCWP).
Schedule variance (SV)
If at any given time the value of the actually completed work packages (EV) is either
smaller or larger than the sum of the completed work packages according to the budget
(PV), the respective variance from the schedule is called schedule variance (SV).
Earned value (EV) - planned value (PV) = schedule variance (SV)
Cost variance (CV)
The cost variance (CV) is calculated on the basis of the actual costs of the project.
Earned value (EV) - actual costs (AC) = cost variance (CV)
Schedule performance index (SPI)

The schedule performance index (SPI) measures how far a project is off plan. A value
larger than 1 indicates that the project progress is faster than originally planned. On the
other side, a value smaller than 1 represents a delay in the project. The ratio of EV and
PV is as follows:
SPI = EV / PV
Cost performance index (CPI)
Cost performance index measures the value of performed work compared to the
originally planned value.
A value larger than 1 indicates cost savings in the project while a value smaller than 1
indicates that a project is developing more expensive than planned.
The ratio of EV and AC is as follows:
CPI = EV / AC
15.3 Status reports and reporting

The project reporting is a very significant part of project controlling. It serves the
distribution of information to the stakeholder as well as the documentation of project
results. Project reports should in general deliver information on scope, schedule, cost,
quality and risks. In many projects information on procurement management is also
required.
Another aspect is the time covered by the project reporting. Here the general distinction
is made between status and progress reports on one side and forecasts on the other.
A status report informs about the current state of the project. It gives us the answer to
the question: "where are we right now?" Project progress on the other hand represents
the information about what has been achieved in comparison to an earlier point in time.
Forecasts are directed toward the future and provide a view on what will be from the
current perspective.
A small example shall illustrate this. Imagine yourself in a car. A view out the side
window will tell you where you currently are. This represents the status. If you look into
the rear view mirror, you will see from how far you have come. That is the progress. And
a view through the windshield will tell you what is ahead. This is what we call forecast.
A practical project status report should include all of these elements. The project status
report is a formalized document that summarizes the project situation at a given point in
time.
The purpose of the project status report is to inform the client, steering committee or any
other relevant project participants about the project and allow well-founded decisions as
part of the ongoing project activities.
A status report is created in view of
milestone decisions
regular events
for special occasions (e.g. project audit)
A good project status report provides clear, brief and precise information on the most
important parameters of the project:
Scope, dates, costs (e.g. by using a traffic light system). Important in this context is
that the use of the traffic light colour is consistent and clearly defined as well as
realistically communicated to all participants. A practical definition is:
- RED: Critical variance that cannot be resolved without the support or a
decision by the steering committee, the sponsor or the customer.
- YELLOW: Controllable variance that can be handled by the project team by
taking counter measures or making corrections.
- GREEN: the project progresses as planned.
Milestones - achieved and not achieved
Newly emerged issues and problems still unsolved
Newly identified risks
Countermeasures for above-mentioned problems and new risks
Risk monitoring (TOP risks and countermeasures identified thus far)
Deadline and cost situation (often complemented by earned value indicators and
graphs as well as a milestone trend analysis)
Aspects for decision-making
The following diagrams illustrate a typical real life example.
Another important aide and documentation tool for project controlling is the approval
protocol. In those documents the client or customer confirms in writing the approval or
acceptance of project team deliverables or products using defined approval criteria (see
scope statement / list of obligations). This protocol also serves as an important guideline
for the project manager and the project team in terms of preparation for the approval of
project results:
What is relevant for the approval?
What criteria must be met?
How is measured whether the result is conform to the requirements set by client or
customer?
Did the project team verify that every requirement was met? (quality assurance and
internal review)
15.4 Issue log (open aspects or so-called "action item log")

An issue log is a problem or action protocol; i.e. a tool that is used for documenting and
monitoring the resolution of problems that arise during the course of a project.
The term "issue" is translated with "problem". The term "open points" is also used in this
sense. Open points, therefore, are NOT:
1. not yet completed tasks of the to-do list
2. not yet completed work packages
Open points or issues in this context are, instead, things like
known but not yet solved problems
change requests not yet decided on
open additional claims
occurred risks whose effects must yet be overcome
The PMBOK guide also clearly defines the term: "An uncertain or controversial point
that remains unclear is discussed or for which opposing views or disagreements exist."
In summary, issues are points or problems that cannot be solved on an individual level,
i.e. by a single person, and that usually do not immediately affect project objectives.
However, if issues remain unsolved or unprocessed, they may affect the project to a
large degree. Therefore, an issue log is an indispensable instrument for project
controlling.
The issue log is rather similar in structure to the risk register or the change control log. In
addition to the detailed description of the issue it contains the description of the effects, a
priority, a proposal for a solution with target date, the person assigned with or
responsible for the solution, the status of the issue (e.g. new, being analyzed, being
processed, escalated, solved), as well as a concrete description of how the issue was
solved.
Unsolved issues are among the most frequent reasons for project failures. Therefore,
the following practical advice:
Practical advice
No project without an issue log!

Availability and preparation of an issue log are the responsibility of the project
manager.
Issues with the highest priority should be processed first.
Always assign an issue (responsibility) to a person, never a group!
Define an exact date for completion.
Document EVERYTHING that contributed to the solution. These records are an
important source for lessons learned.
Discuss the issue log during each project meeting or status report.
If issues are closed, they remain in the issue log. This way, emerged problems and
their solutions remain in sight at all times.
Issues that did not yet occur (i.e. are potential problems) are risks and thus belong in
the risk register.
15.6 Change management

Since at the beginning and during the early stages of a project there are many
uncertainties, changes to the original plan are pretty much inevitable over the course of
project implementation. Changes become necessary to, for example, with regard to
deliverables or project results as well as to the schedule or the budget over the course of
the project.
A change is defined as ANY adjustment of ANY aspect of the project management plan
or ANY deliverables.
If changes occur, it is necessary to follow a controlled process for the assessment,
prioritization, approval and implementation of the changes. For project change control it
is important that project changes are analyzed and assessed as to their effects before
being realized. Furthermore, ALL changes must be coordinated centrally and
stakeholders must be informed about approved changes. The following diagram shows a
typical change request management process.
The committee deciding upon and approving the change request usually is the project
steering committee. Members of this committee are the project sponsor and relevant
decision-makers of management.
In addition to the depicted processes, the formal change request is the most important
tool:
Change request
Project master data
Project name:
Project manager:
Date:
Change request
Date
created:
Applicant:
Function:
Description of
change:
Effect on
performance:
Effect on
quality:
Effect on
resources:
Effect on
costs:
Effect on
schedule:
Reviewer information
Reviewer name:
Project result:
Recommendation
Approved
:
Comment:
Function:
denied
Date:
Approver information
Approver name:
Decision:
Comments:
Function:
Approved
denied
Signature:
Date:
Project manager information
___________________________________
Name (print)
___________________________________
Place
__________
date
The so-called "change log" supports the documentation and coordination of all changes
in the project. It has a similar structure as the issue log and usually contains the
following contents:
Practical advice:
The depicted change management process is not trying to avoid changes in the project.
It is, however, trying to avoid negative effects of unintended changes to the project,
which may come about through hasty implementation without sufficient analysis of the
effects.
15.7 Configuration management

Configuration management comprises all technical, organizational and decision-related
measures and structures that deal with the configuration (specification) of a project.
This mainly includes the formal and documented approach for technical and
administrative monitoring:
Identification and documentation of functional and physical characteristics of
components or systems
Controlling of changes to these characteristics
Documenting and reporting of any changes as well as their implementation status
In practice this means, for example, having a conclusive version system for (planning)
documents and files that ensures all participants working with the same current data and
information. The same is true for project results or for the "product" of our project: the
configuration management ensures that, for example, all components of a complex
energy utility system are identified and documented based on their respective
development status.
The objectives of the configuration management are:

Keeping documented and verified components/systems complete and avoiding
unauthorized changes
Ensuring the synchronization of project requirements and results
Providing historical information on deliverables as well as their changes during the
project and the product life cycle
Configuration management comprises process documentation, description of roles
and responsibilities (incl. approval levels) as well as supportive IT or software tools
and quite often also includes change management.
16.
Project closure
Project closure is concerned with the premature or planned closure of the project or the
closure of a phase (for large projects). The different aspects of project closure comprise
the formal approval and transfer of the project result from the project team to the client,
the completion or fulfilment of supply agreements, the administrative end of the project
or phase incl. reporting, final payment or invoicing and archiving of all project
documentation as well as collecting, analyzing and publishing collected experiences for
future projects (lessons learned).
The objective is ensuring a formal and controllable end to the project, either at the end of
the project or when the project is cancelled. This mainly involves the following activities:
Ending agreements with suppliers
Holding final status meetings
Formal approval of project results
Financial closure
Performing audits at project end (e.g. in terms of configuration or procurement)
Gaining and documenting lessons learned. Preparing and reviewing the final project
report
Archiving project information
Honouring and celebrating project success
Releasing resources from the project
Final project report

The final project report provides an overview of the project and highlights any important
lessons learned that may also be important to other projects.
The final project report helps project teams during the identification of projects with
similar problems/challenges as well as during the search and implementation of lessons
learned.
Important information presented in the final report:
Project purpose
Project background and significant results during the project
Project results/deliverables
Work breakdown structure or WBS (on highest level)
Project organization
Important progress measures (budget, schedule, requirements, objectives)
Top risks, significant problems and issues
Important changes
Final project documents
Overview of all lessons learned
Lessons learned
Many companies collect lessons learned; however, quite often this knowledge falls into
oblivion or remains untouched. Instead of questionnaires, which usually only lead to
rather generic statements and results, we recommend the implementation of a
moderated lessons learned workshop with the core project team, ideally also with
representatives of the client or customer and other important stakeholders participating.
The following questions are in focus:
What exactly did work well? What did we do successfully?

What was difficult? What should we do more, less, differently in the future?
How can we retain and sustain the positive achievements of the project?
The results are documented in a structured form and made accessible to company
stakeholders.

Gerente de Proyectos

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Gerente de Proyectos

Uploaded by

Copyright:

Available Formats

Project Management

/ PROJECT MANAGEMENT COMPENDIUM / 2

/ PROJECT MANAGEMENT COMPENDIUM / 3

V-Model XT (vshaped project

/ PROJECT MANAGEMENT COMPENDIUM / 4

1.2 What makes projects successful?

/ PROJECT MANAGEMENT COMPENDIUM / 5

Typical factors are:

1.3 Context of project management

/ PROJECT MANAGEMENT COMPENDIUM / 6

The process model of the project management differentiates between 5 so-called

Programs are long-term tasks that consist

/ PROJECT MANAGEMENT COMPENDIUM / 7

1.4 Project management knowledge areas

/ PROJECT MANAGEMENT COMPENDIUM / 8

Project management includes the following knowledge areas:

/ PROJECT MANAGEMENT COMPENDIUM / 9

1.5 Phases & processes of projects

The approach described above is referred to as gate review.

Project life cycle system development

/ PROJECT MANAGEMENT COMPENDIUM / 10

/ PROJECT MANAGEMENT COMPENDIUM / 11

2. Project initiation and project

a new market or customer need

All these data must be phrased SMART - which means:

/ PROJECT MANAGEMENT COMPENDIUM / 12

Included are also:

/ PROJECT MANAGEMENT COMPENDIUM / 13

/ PROJECT MANAGEMENT COMPENDIUM / 14

Project charter (project description/assignment)

Corporate objectives of the project

Critical success factors

/ PROJECT MANAGEMENT COMPENDIUM / 15

3. Project definition (project

/ PROJECT MANAGEMENT COMPENDIUM / 16

/ PROJECT MANAGEMENT COMPENDIUM / 17

/ PROJECT MANAGEMENT COMPENDIUM / 18

Additional best practices are:

/ PROJECT MANAGEMENT COMPENDIUM / 19

Advantages of the analysis:

The stakeholder analysis is a team-internal and highly confidential document!

/ PROJECT MANAGEMENT COMPENDIUM / 20

Concrete approach to the stakeholder analysis:

Identification of all relevant stakeholders with names and function

/ PROJECT MANAGEMENT COMPENDIUM / 21

/ PROJECT MANAGEMENT COMPENDIUM / 22

5. Work Breakdown Structure

Steps for developing the work breakdown structure (WBS):

/ PROJECT MANAGEMENT COMPENDIUM / 23

/ PROJECT MANAGEMENT COMPENDIUM / 24

Additionally, it is also important that:

Estimate of required efforts, time and costs

/ PROJECT MANAGEMENT COMPENDIUM / 25

Analogue estimate (top down):

Three point estimate:

/ PROJECT MANAGEMENT COMPENDIUM / 26

6. Roles and responsibilities in

/ PROJECT MANAGEMENT COMPENDIUM / 27

/ PROJECT MANAGEMENT COMPENDIUM / 28

In terms of role assignments during project implementation it may be useful to

/ PROJECT MANAGEMENT COMPENDIUM / 29

/ PROJECT MANAGEMENT COMPENDIUM / 30

A typical procedure or activity node looks as follows: