gerente de proyectos

Project Management Compendium

/ PROJECT MANAGEMENT COMPENDIUM / 2

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


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 (standard)

Criteria

Prince2 (projects in controlled environments)

PMBOK® (project management body of knowledge)

ICB (IPMA competence baseline)

CMMI (capability maturity model integration)

V-Model XT (v-shaped 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 für 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 [Koordinierungs- und Beratungsstelle der Bundesregierung für Informations-technik in der Bundesverwaltung (KBSt)], (D)

Type of method Process model Best practice model with processes and knowledge areas

Competence and capabilities model

Maturity 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: Let’s 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. Starting points are the defined results (major deliverables) and contents of the list of obligations (scope statement).

2. 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.

3. 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.

4. Each WBS element is only associated with one other WBS element of the next higher level.

5. The WBS is sufficiently detailed to be able to detect interdependencies between WBS elements.

6. The lowest level of the WBS in each line of elements is called work package.


7. 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 short-term (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.

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 80-100 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.

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:

Project team executes

Project manager initiates


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-benefit-analysis 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 equipment

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 kick-off 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 whom

Until/by Remarks


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-Gate-Model is the rule. The Stage-Gate-Model 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: Date: Project manager:

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: Function:

Project result: Recommendation:

Comment:

Approved denied


Date:

Approver information

Approver name: Function:

Decision: Comments: Signature: Date:

Project manager information

___________________________________ Name (print) ___________________________________ __________ Place date

Approved denied


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

Documents

context of project management

project initiation

project charter

project execution

project controlling

stakeholder management

quality management

communications management