Basic Definitions

(A) What Is a Project?

There are two organizations who give us definitions:

(1) PMI, the Project Management Institute:

A project is a temporary endeavor undertaken to create a unique product, service, or result.

(2) IPMA, the International Project Management Association:

A project is a time and cost constrained operation to realize a set of defined deliverables (the scope to fulfill the project's objectives) up to quality standards and requirements.

This means that we differentiate projects from other endeavours: A project is an endeavor undertaken in order to create a result that is unique in terms of scope, schedule, and budget.

Examples:

1. Exchange the stairs in our two-story family home.
2. A vacation of two weeks for 4 people on two jeeps in Outback Australia
3. Construct a new office building of five stories for 400 employees

(B) What is "Project Management"?

According to PMI, project management is the application of knowledge, skills, tools and techniques to project activities to meet project requirements.

Almost every project needs contributions of experts in different areas. For the duration of the project, these experts form a team, the project team. Consequently, project management comprises all methods, skills, and activities necessary to lead project teams and coordinate and organize the project work.

Thus, each team member (project manager, sub-project manager, team member) has his or her share in project management activities in addition to his or her actual content-oriented contributions.

The Triple Constraint of PM

The triple constraint of project management describes the interdependency between the three cornerstones of a project, as we introduced them in the definition of the term project:

1. Scope: all the work we have to do in order to create the clearly specified product.
2. Schedule: the time we need in order to create that product.
3. Budget: the total amount of money we need in order to create that product.

If we change one cornerstone of the three, we influence the other two.

For example, if we increase the scope - because of additionally required features of the product - then we have to increase the necessary time and budget. Similarly, in order to shorten the time we could reduce the scope and consequently reduce the budget. We also could shorten the time by involving more resources and thus, increasing the budget.

The Project Life Cycle - Overview

Let us follow the project life cycle of a classical project, like the construction of a house, from the very beginning to the very end, and look at it from a generic point of view.

The Project Life Cycle - Summary

We summarize this in the following diagram, emphasizing major milestones in red.

Project Management As a Process

Referring to the generic project life cycle, as we introduced it on the previous page, we can define project management as a process that consists of four phases.


The four phases are

1. Definition Phase
2. Planning Phase
3. Implementation Phase
4. Closure Phase

This illustrates our understanding of project management (cf. page 1). We consider project management to be the application of knowledge, skills, tools and techniques to project activities to meet project requirements, organized in a process of above mentioned four phases.

We also recognize five generic milestones:

1. Project Start
2. Project Goal Defined (upon completion of definition phase)
3. Contract Signatures or Design and Plan Approval (upon completion of planning phase)
4. Preliminary Acceptance (upon completion of implementation phase)
5. Final Acceptance (upon completion of closure phase)

Project Life Cycle and Project Budget

Looking closer at the project budget or cost, we observe in most real life projects that we end up with a (much) higher final cost than originally planned before contract signatures.


Major reasons for this cost overrun are:

1. Unclear project goal(s).
2. Insufficient plans, because we want to save time and effort for planning in order to quickly start the "real work".
3. Necessary changes to the original design or project plan, due to unexpected events after contract signatures.

Test 1

SMART Goals

Main task in project definition phase is to formulate a clear project goal and work out features and requirements the project result shall fulfill.

How Do We Define a Project Goal?

General criterion is: the goal definition needs to give us enough information so that we can continue with more detailed planning in the subsequent planning phase.

We achieve this best by setting SMART goals:

Examples:

1. Construction of a two-bedroom, two-bathroom home for a family of three.
   Specific: the house shall consist of living room, dining room, kitchen, utility room, two bedrooms, two bathrooms; on one floor; single car port.
   Measurable: overall size 95 to 105 sqm, of approx. square footprint, overall cost under USD 100,000.--
   Attractive: comparably low cost.
   Realistic: only if the future owner has enough skills to contribute minimum 30% of work on site.
   Timed: within 18 months, including design and planning.
   
2. Vacation of two weeks in Thailand countryside, for two people.
   Specific: the vacation shall go through three smaller cities, exclusivly using public transport.
   Measurable: maximum two nights in Bangkok, cost of EUR 500.-- per person, excl. airfare.
   Attractive: adventurous, comparably low cost.
   Realistic: with some preparation, especially, basics of Thai language.
   Timed: within 6 months, including planning.
   
3. Design and build a new wooden desk for our office.
   Specific: the desk shall provide enough area for a standard size laptop, small size laser printer, and paper work.
   Measurable: lenght 200 cm, depth 90 cm, height 80 cm; total cost less than EUR 500.--
   Attractive: doing it ourselves, it comes with comparably low cost and will be a lot of "fun".
   Realistic: given the fact that all nessesary skills, tools, and material are available, yes.
   Timed: within 2 weeks, including planning.
   

(We use the third example in later lessons as well.)

Project Stakeholders

The examples of SMART goals show that we need to investigate details in order to enable a sufficient goal definition, one that really gives enough information so that we can continue with further planning.

Who Gives Us the Details?

We get the details from those who

• have interest in,
• or are affected by

the project results or project activities.

These are the project stakeholders. Typically, they are:

• Customer: the one who is going to pay for the project result.
• End users of the project result.
• Supplier and sub-suppliers: the ones who create or provide the project result or parts of it.
• Members of the project team.
• Experts who support the project work.
• Executives and managers in the customer's organization.
• Executives and managers in the supplier's organization.
• Project manager.
• Government entities and authorities who enforce law and regulations.

Other sources for details of our project goal definition are standards, common and best practices, bodies of knowledge in all project relevant areas of expertise.

Test 2

Project Scope

The main task in the project planning phase is to create all plans which we need for implementing and closing the project. We start with planning the project scope, in two steps.

(A) Design of the result: Product Breakdown Structure (PBS)

A tangible project result needs a design. Usually, we start with a preliminary design or design draft, and refine it several times. For example 3 of page 2a SMART Project Goals, the office desk, we start with this design draft.

Then, the Product Breakdown Structure (PBS) would be:

We call this object-oriented structuring approach because it yields a decomposition of an object (the desk) into sub-objects.

(B) Work Breakdown Structure (WBS)

The Work Breakdown Structure (WBS) shall give a complete overview over all the work that has to be done in order to reach the project goal.

For setting up the WBS, we ask the question what work we have to do in order to obtain the sub-objects (the parts of the desk) and the finished project result (the complete desk). We start with the sub-objects of the PBS. In our example we could end up with something like this:

The example shows:

• The WBS must be complete, i.e. it must comprise all the work to be done to achieve the project goal.
• The lowest structural level of a WBS contains only work packages (WP's).
• We organize the work packages in groups or sub-groups.
• Every work package consists of verb (that indicates what we shall do) and object (that indicates on what we shall work).
• The WBS shall be free of contradictions (different work packages identifying the same work in different ways).
• The WBS shall be free of redundancies (different work packages identifying the same work).

As we will see later, it is particularly difficult to set up a WBS that is complete, i.e. that contains all the work necessary. For this, we need advice of experienced experts.

Since we started with an object-oriented PBS in our example we would have missed important work. Therefore, we created a group of work packages "other works" containing all the work packages that do not fit under any sub-object.

Setting up the WBS, completes planning the project scope.

Effort Estimation

Before we can plan the project schedule we have to estimate effort and duration of all the work packages of the WBS. If the WBS is complete and free of contradictions and redundancies we cannot under- or over-estimate. Thus, the resulting figures will be more reliable and a good basis for planning the project schedule and the project budget.

We do this in workshops by using the Delphi-Method, i.e. asking the experts who are responsible for each work package, how much of what resources they need for what period.

Every expert will give us three figures for the expected effort (E) and three figures for the expected Duration (D) of every work package:

• E(optimistic) and D(optimistic)
• E(normal) and D(normal)
• E(pessimistic) and D(pessimistic)

Then, we calculate the expected value of

1. Effort = (E(optimistic) + 4*E(normal) + E(pessimistic)) / 6
2. Duration = (D(optimistic) + 4*D(normal) + D(pessimistic)) / 6

Here is the result for effort and duration of the project "Office Desk", WP by WP:

Project Schedule - Network Diagram

The next task in project planning phase is to create the project schedule, in three steps.

(Step 1) The logical sequence of work packages: Network Diagram

The network diagram represents the logical sequence of all work packages. We answer the question: in what sequence do we have to do all the work?

For our desk, we only consider the work packages and arrange them into a logical sequence.

In this example, we could end up with a network diagram like the following.

Project Schedule - Gantt Diagram

(Step 2) Introducing a time reference: The Gantt Chart

The Gantt chart represents the sequence of all work packages with reference to a time line. Each work package is symbolized by a bar with a length that corresponds to its duration.

We usually set up the network diagram with some project planning software package, like MS Project. So, we can switch back and forth between the network diagram and the Gantt chart by simple mouse-click.

Since the project planning software sets the duration of each work package to a default value, we need to adjust all the work package durations to values based on our estimation. For our desk, we could get a Gantt chart like this:

In case we set up the Gantt chart manually, we make sure that we keep the same logical sequence of work packages as in the network diagram.

Project Schedule - Milestone Plan

(Step 3) Getting an overview on the top level of a large project: the milestone plan

For larger projects, we need to have an overview of the schedule for the project as a whole. We achieve this by introducing milestones that indicate significant points in our project schedule.

In our example, we could come up with the following Gantt chart with milestones:

On the top project level, we present the milestone plan that shows only the milestones with reference to the time line.

On the following pages, we will introduce the calculation of dates, total float and free float, and the critical path of a project.

Schedule Calculations - Intro

Based on the network diagram and/or the Gantt chart, we continue with calculating start dates, end dates, total float and free float of all work packages, and the critical path of the project.

We are especially interested in answering two questions:
(1) When can we finish earliest?
(2) When do we have to start the project latest?

To find the answers we begin with the forward pass and the backward pass. As a "by-product" of these calculations, we also obtain total float and free float of each work package as well as the critical path of the project.

Let us go through a small example that shows how it works.

Basis of the calculations is the network diagram which shows the logical sequence of all work packages or tasks.

Each work package contains at least the following information:

Forward and Backward Pass

For demonstrating the basics of the following calculations, we use a very small project with five work packages (WP1 to WP5) as an example. Here is the table that shows the figures for effort (in work days, wd) and duration (in days, d) of each work package:

WP name	Effort	Duration
WP1	8 wd	4 d
WP2	21 wd	7 d
WP3	10 wd	5 d
WP4	8 wd	4 d
WP5	12 wd	4 d

Forward pass and backward pass

The forward pass (going from the left to the right) yields the earliest possible finish date, the backward pass (going from the right to the left) gives us the latest possible start date.

Earliest start date of this very small project is 3, already entered into the field "earliest start" of the first work package WP1.

Latest end date is 31, already entered into the field "latest end" of the last work package WP5.

Please note:
"Earliest start" or "latest start" means "in the morning of that particular date".
"Earliest end" or "latest end" means "in the evening of that particular date".
We consider only work days, there is no work on weekends.

Doing the calculations manually for this small example gives you the opportunity to understand how most PM planning tools work. ... Let's try.

Total Float and Free Float

Total float (TF) of a work package is the duration by which we can delay that work package without delaying the project.

Free float (FF) of a work package is the duration by which we can delay that work package without delaying the logically next work package.

We calculate total float (TF) of a work package as difference between latest end (le) and earliest end (ee) of that work package, while counting only working days.

TF = le - ee

We calculate free float (FF) between two consecutive work package WPX and its follower WP(X+1) as difference between the earliest end date (eeX) of WPX and the earliest start date (es(X+1)) of the subsequent work package WP(X+1). Again, we count only working days; besides that, work starts in the morning and ends in the evening.

FF = es(X+1) - eeX - 1

The following table shows the results of our example:

Work Package	TF	FF
WP1	4 days	0 days
WP2	6 days	2 days
WP3	4 days	0 days
WP4	4 days	0 days
WP5	4 days	0 days

Critical Path

The critical path

In the small example, we have 2 possible paths through the project:

1. WP1 - WP2 - WP5
2. WP1 - WP3 - WP4 - WP5

There are several definitions of the critical path.

Definition 1:

The critical path through the project is the one along which all the work packages have minimum total float.

In our example: WP1 - WP3 - WP4 - WP5.

Definition 2:

The critical path through the project is the one along which all the work packages have free float of 0.

In our example: WP1 - WP3 - WP4 - WP5.

Definition 3:

The critical path through the project is the path with the longest total duration.

Total duration of the two paths of our example:

1. WP1 - WP2 - WP5: 15 days
2. WP1 - WP3 - WP4 - WP5: 17 days

Again, the critical path is WP1 - WP3 - WP4 - WP5.

Here is a Diagram with all the results.


We indicated the critical path in red color.

Project Budget and Cost

Most projects are based on a customer-supplier relationship. The customer cares about the necessary project budget, which consists of two parts: customer's internal cost of their own work for the project, plus the payment to the supplier. The supplier cares about supplier's internal cost and the payment from the customer. Before the project can begin, customer and supplier negotiate until both parties agree especially on the payment issue, besides all other issues.

The customer needs a combined project cost plan which is the project budget plan:
budget = (own cost) + (payment to supplier).

The supplier needs two plans: the project cost plan that contains their cost, plus a payment plan which contains the payments from the customer.

In small projects, which we carry out ourself, we just consider the project cost.

Project Cost Plan

The project cost plan shows the accumulated cost of all work, tools and material needed for, or consumed by the project, with reference to the timeline of the project.

Basis of our calculation of project cost is the Gantt chart of the small project, the estimated effort in terms of work and tools of each work package, and the estimated amount of material.

Here is the table with the estimated effort per work package.

WP name	Effort	Duration
WP1	8 wd	4 d
WP2	21 wd	7 d
WP3	10 wd	5 d
WP4	8 wd	4 d
WP5	12 wd	4 d

Our cost per person and working day is 600,- USD, tools or material are not needed in this example.

We obtain the project cost plan by adding up the accrued total cost, time unit by time unit:

Risk - Identification

After preparing project scope, schedule, and budget (in form of a cost plan) we remember lesson 1c Project Life Cycle. There we noted that major reasons for cost overrun of many projects are necessary changes during implementation phase. This means that our project plans might be very detailed, yet we cannot really plan for all eventualities.

Consequently, there will always be the risk of necessary changes.

Here we introduce the basic concepts of managing risks.

Definition of the term "risk":

With this definition in the back of our mind, we start with identifying risks for our project. Usually, we do this together with all our project team members.

Let us go back to the example of the new desk. Here is the WBS.


Which risks can we identify for that project?

1. wood plates not available
2. the saw blade breaks
3. the drill bit breaks
4. etc.

Based on this list of risks we continue with the next step.

Risk - Analysis

For each risk we can estimate the probability of its occurrence and its impact on the project.

In the example of the "desk project" we estimate both, probability (p) and impact (i) of each risk with reference to a scale ranging from very low to very high

1 = very low 2 = low 3 = medium 4 = high 5 = very high,

and we obtain the following:

1. wood plates not available: p = 2, i = 5 (probability: low; impact: delay of 3 working days)
2. the saw blade breaks: p = 1, i = 3 (probability: very low; impact: delay of 1 working day and we need to buy a new saw blade)
3. the drill bit breaks: p = 2, i = 3 (probability: low; impact: delay of 1 working day and we need to buy a new drill bit)
4. etc.

Multiplying probability and impact for each risk, p * i, helps us to prioritize the risks:

1. wood plates not available: priority = 10
2. the saw blade breaks: priority = 3
3. the drill bit breaks: priority = 6
4. etc.

Risk - Management

Now the question is: what can we do about each risk?

First Principle of Risk Management

This means, we can plan

1. preventive actions to reduce the probability of occurrence, or
2. corrective actions for the case the event happens anyway.

Both options imply that we have to integrate additional work into affected work packages or create new work packages which go into the WBS.

For the "desk project" we could come up with (starting with the highest priority):

1. wood plates not available (priority = 10), preventive action: call different hardware stores for availability of wood plates.
2. the drill bit breaks (priority = 6), preventive action: buy 2 spare drill bits.
3. the saw blade breaks (priority = 3) preventive action: buy 1 spare saw blade.
4. etc.

Before integrating each action into the WBS we need to decide if it reduces probability and/or impact of its corresponding risk far enough to justify the additional cost of action. Thus, we have to estimate the cost of each action as well.

Second principle of risk management

Repeat, repeat, repeat: Risk management is an iterative process - we need to repeat its three steps regularly throughout the duration of the whole project.

Test 3

The Control Cycle

In the project implementation phase we do the major part of the work of a project. Main goal of the project manager in this phase is to make sure that she or he stays in control of his project.

• Every work package must cover the planned scope, and only that scope.
• All who contribute follow the planned schedule.
• Each work package remains within its planned budget.

In order to stay in control of the project, the project manager - together with the whole team - will regularly compare the real work results with planned results. The following diagram illustrates this basic approach.

Conclusions:

1. In order to be able to compare actual results with required results we need a plan that contains these required results.
2. In case actual and required results are in line with each other we continue with the next work package, task or action according to our plan.
3. Are actual results not in line with required results we might need to change the plan of the corresponding group of work packages, tasks or actions. For that reason we need change management procedures to be agreed upon by all stakeholders.
4. Sometimes, changing the plan is not sufficient. Then, we might need to change requirements or specifications of those results. This can be done only with the consent of all stakeholders. Here, change management procedures are helpful again.
5. In some rare cases this is still not sufficient, we might need to change the project goal or even terminate the project as a whole. This is the most serious situation for any project, and only clearly defined termination criteria will help to manage this situation.

Controlling Tools

Now, we cover basic tools for controlling the scope, schedule and budget (or cost).

Referring to the basic control cycle let us introduce how we use our planning documents to support the comparison of actual with required results from a project management point of view.

(1) Work Breakdown Structure

Each work page of a complete WBS describes details of that particular part of the work and the required results. Consequently, we can use the WBS in order to compare actual with required results.

(one strike = work package started but not yet complete; two strikes = work package complete)

(2) Network Diagram

Similarly, we can use the network diagram to compare actual with required results - again work package by work package.

(one strike = work package started but not yet complete; two strikes = work package complete)

(3) Gantt Chart

In order to support our schedule controlling we use the Gantt chart:


We read this diagram as follows: Project status on Thursday, day 11 of that month.

WP1	started and finished on time;
WP2	started on time and not yet finished;
WP3	started on time and not yet finished;
All others	not yet started.

(4) Cost Plan

For the cost controlling we use the plan of accumulated cost (Our cost per person and working day is 600,- USD, tools or material are not needed.):


We read it like this:
By the end of day 11 of this month, planned project cost is 13,800.-- but actual project cost is 14,100.--

Usually, we summarize the findings of every comparison in a project status report.

In our example, we would have the above 4 elements, plus selected details about the work packages, external influences, risk events, other events, etc., what ever is necessary to understand the report and conclusions about the further course of action.

Change Control

As indicated in the basic control cycle, in case of deviations, changes to the original plan might become necessary. On this page we go through the event log of the office desk project and show what could be done in case of unexpected events.


Some of the deviations - and thus, the resulting changes - may be due to mistakes or misinterpretations of the original plan; others are due to external influences or events in the project environment.

However, changing the plan often leads to project delays or additional cost which we want to minimize as far as possible.

The results of a comprehensive and diligent risk analysis in the project planning phase are

• preventive actions to reduce the probability of the risk occurance, and
• corrective actions which create contingencies to cover the risk impact.

Test 4

Closure Phase

Preliminary acceptance marks the end of the implementation phase. In the project closure phase we tie up all the open ends of our project.

What is still open?

• close all open items necessary to obtain final acceptance of the project results
• support project team members in finding new assignments
• clean tools and machines and store them properly
• collect material we did not use and integrate it into our organization's storage system
• clean the workshop(s) we used
• prepare the final calculation of actual project cost
• compare final with planned values of effort and duration of each work package
• summarize which of the identified risks occurred
• summarize all changes and their impact
• compile a project documentation, incl. work reports, records of events and changes, summary of risks, actuals of effort, duration and cost
• review lessons learned

In the office desk project, we clean the workshop and the tools, collect the remaining material, store everything, and prepare the following final calculation in terms of effort and cost of material and tools:


Finally, we decide to review our most important lessons learned as our last project activity.

Lessons Learned

At the end of a project, we need to collect our most important lessons learned.

There are different levels of lessons learned:

• Project manager and team members: In order to support their personal development the project manager and his or her team members want to know in which areas they performed well and where they need to improve.
• Project stakeholders: For major project stakeholders, especially the customer, it is important to capture the project's success factors and weak areas.
• Involved organizations: Any organization involved in a project needs to keep the key data of the project and make it available for the rest of the organization so that all can learn as well.

We collect lessons learned in workshops and meetings:

• A workshop for the project team including the project manager is held to collect their most important learning for their further career.
• Major project stakeholders call for a meeting in order to discuss the project success factors and weak areas.
• We enter the project's key data into knowledge management systems if they are avalable.

In our example, the project of the office desk, we confirm our main lessons learned as:

• We need a good plan in terms of scope, schedule and budget in order to enable us to compare actual with planned results in the implementation phase.
• A profound risk analysis is integral part of project planning so that we can create preventive and corrective actions for events that could jeopardize the project or its results.
• We need to involve experts in project planning in order to support effort and duration estimation and risk analysis.
• We anticipate events in the implementation phase which we did not plan for and would call for changes in our approach to the work, of the plan, the requirements and, in serious cases, even of the goal.
• Our management of all work and eventual changes in the implementation phase needs to be based on the optimization of the triple constraint of project management: scope, schedule and budget.

Finally, the major stakeholders decide to declare final acceptance of the project results.

Test 5

Final Test