All projects depend on estimations. We have to estimate the time it will take to complete an activity and we need to estimate the cost that will be incurred in executing an activity, phase or project. Estimates are approximations or "best guesses" and is subject to the uncertainty with which we are confronted when making these estimates. From this we can see that the more uncertainty there is, the less accurate our guess is, and therefore the higher the risk is that our time and cost estimates will not be realistic. Should we only rely on one estimated figure, for instance "it will take 8 days to complete the activity", then we will not take the uncertainty into consideration. In short, PERT is a technique that helps us to take this uncertainty into account when compiling realistic estimates on our projects.

What is PERT (Program Evaluation and Review Technique) and how can we use it to help us on projects? PERT is a three point activity estimating technique that considers estimation uncertainty and risk by using three estimates to define an approximate probability for an activity’s cost  or duration. The three estimates used are:

• Most likely (M) - The cost/duration of the activity, based on a realistic effort assessment for the required work and any predicted expenses.
  
• Optimistic(O) - The activity cost/duration based on an analysis of the best-case scenario for the activity.
  
• Pessimistic(P) - The activity cost/duration based on an analysis of the worst-case scenario for the activity.

At activity level PERT can help us to determine a more realistic estimate. Let us take the following estimates for five project activities as an example:

PERT calculates a weighted average as the PERT estimate by using the formula : Pert Estimate = (Optimistic + (4 X Most Likely) + Pessimistic)/6. That means that we are weighting the most likely estimate by a factor of four (4) and then determining the average of the weighted most likely time, the best case scenario and the worst case scenario. In the case of Activity A that will be (5 +(4 X 7) +15)/6. The pert estimate is therefore calculated as 8 days. If we compare the PERT estimate of 8 days with the normal average of the three estimates of 9 days (5 + 7 + 15 /3 = 9) we can see that the PERT estimated is weighted towards the most likely estimate. We use a weighted average calculation because statistically we find that the largest portion of a randomly occurring population of data will be found close to the mean as can be seen from the following bell curve, also called a normal distribution curve:

This bell curve shows us that if we divide the data into 6 equal portions, then by far the majority of the instances will be found in the 2 portions next to and on both sides of the middle line (mean) while the probability of the occurrence falling in either the optimistic or pessimistic block is much lower. We divide the graph into 6 equal block by calculating the standard deviation also called the sigma (identified by the sigma symbol “ϭ”). By using the simple formula Sigma = (Pessimistic – Optimistic) / 6 we divide the graph in 6 equal blocks. From this we can see that the PERT estimating formula using (Optimistic + (4 X Most Likely) + Pessimistic)/6 is based on this natural distribution. This also gives us a tool with which we can quantify the probability of how the data will be distributed. Statistically we know that:

• 68% of the data will be found in one standard deviation from the mean in other words between the mean minus one standard deviation and the mean plus one standard deviation. We can also say that there is a 68% probability that the activity will be completed within one standard deviation from the mean. 
• We also see that 95% of the data will be found within two standard deviations or, put another way, that we can say with 95% certainty that the activity will be completed withing the two sigma range.
  
• At three sigma there is a 99,7% probability.

Lets apply this to Activity A:

From the above bell curve we can thus predict that there is:

• A 68% probability of completing the activity between 6.3 and 9.7 days.
  
• A 95% probability of completing the activity between 4.6 and 11.3 days.
• A 99.7% probability of completing the activity between 3.0 and 13.0 days.

The same formulas can be used to calculate the one, two and three sigma figures for all the activities:

If we assume that all five the activities are on the critical path and that they will all be done sequentially, then it is estimated that it will take 60.3 days to complete the project. But we also saw from the PERT calculations on activity level that there is uncertainty regarding the estimates for every activity. Therefore there is a probability that any activity can take longer or shorter than the PERT estimate to be completed. Because we do not know which activities will take shorter and which will take longer the only option is to accept that some will take less time and some will take more time to be completed. This means that it will be unrealistic to ad up all the sigma values and make them applicable to the critical path. However, there is a more realistic way to calculate the uncertainty of how long it will take to complete the entire project. We can calculate a more realistic  standard deviation for the critical path by using the formula "Project critical path Sigma = √(sum of all PERT variances)". We need to determine the PERT variances for this formula by calculating sigma square (sigma X sigma). Then we add all the PERT variances together and calculate the square root of the sum. This calculation gives a more realistic standard deviation that can be used to express the uncertainty applicable to the project due date. The following table shows the individual values of the PERT variance for every PERT standard deviation:

The project standard deviation can be calculated by determining the square root of the sum of the PERT variances. As per the above table the sum of the PERT variances is 41.8. The square root of 41.8 is 6.5. Therefore one standard deviation for the project as a whole is 6.5 days. This value can now be used to calculate the values for one, two and three sigma for the total project:

• There is a 68% probability that the project will be completed between 53.8 and 66.8 days.
• There is a 95% probability that the project will be completed between 47.3 and 73.3 days.
• There is a 99.7% probability that the project will be completed between 40.8 and 79.8 days.

In practice these percentages can be used to indicate to the sponsor that, due to the uncertainty regarding the estimates, there is a:

• 50% probability that the project will be completed within 60 days.
• 68% probability that the project will be completed within 67 days.
• 95% probability that the project will be completed within 73 days.
• 99.7% probability that the project will be completed within 80 days.

Enjoyed this article?  Leave a comment below; or  share it with your friends – Tweet, Like, Follow, or Pin it with the share buttons in the side bar

Why do we need to know how to schedule the activities in a project? Even more important - why do we need to know how to do it by hand??? The answer on both questions are quite simple: Firstly we need to know how to schedule the activities in a project to know what must happen when and in which order to ensure that we complete the project in time. Secondly we need to know how to do it by hand in order to understand what a network diagram is and how it can support us in managing the project. 

I know you most probably use a software scheduling tool to do the scheduling for you, but if you do not understand the principles of scheduling how will you ever know if the answer you get from the software package is representative of how you envisage the project to be done? Remember the software scheduling package will do all the calculations based on the information provided by you - therefore you need to understand what information the package needs and what it is going to do with it. Another important aspect to keep in mind is that the software package will use defaults or tables set up by you, the PMO or somebody else and therefore the resulting schedule presented by the software is not necessarily always a true reflection of how you visualized the project. Understanding how scheduling is done will help you to identify if the schedule presented by the software is realistic and a true representation of the project schedule to be implemented.

Please bear in mind that this discussion is based on the activity-on-node method (AON) as normally used in the Critical Path Method (CPM). Also please note that this is a discussion of the basic principles of project scheduling and will therefore not address the more complicated scheduling scenarios.

Before we look at what scheduling is all about there are a few rules that we should keep in mind. Adherence to these rules can save you a lot of sweat and tears, whether you do the scheduling by hand or using a software scheduling tool. A network diagram should have:

1. One and only one start activity.
2. One and only one end activity.
3. All activities except the first one should have at least on predecessor. (Predecessor:- a task whose start or finish date determines the start or finish date of its successor task.) 
4. All activities except the last one should have at least one successor. (Successor:- a task whose start or finish date is driven by its predecessor task.)

See the figure 1a below for an example of how the network should look:

A network diagram (or "project schedule network diagram" as per the PMBOK® Guide) consists of boxes representing the activities (or tasks) linked together with arrows representing the logical relationship (dependency) that exists between the activities. The logical relationships can include:

The finish-to-start dependency is the most commonly used relationship in network diagramming.
A finish-to-start relationship is used when the predecessor activity or activities (Activities C, D and E) can not start unless the predecessor activity (Activity A) is completed.

In the example on figure 4 activity B can not stop until activity C is completed and activity C can not stop before activity D is completed - it is important to note the direction of the arrow. Bear in mind that there is no direct relationship between activity E and activities B and D, the relationship is between E and C.

From the example network diagram in Figure 5 it can be seen that activity E (successor) can not stop before Activity F (predecessor) has started. Please note the definitions of a predecessor and successor. Predecessor:- a task whose start or finish date determines the start or finish date of its successor task. Successor:- a task whose start or finish date is driven by its predecessor task.

The lead relationships indicated in the example as per Figure 6 represent the following:

• The SS-1 day relationship between activities C and B indicates that activity B cannot start until activity C has started minus one day. In other words activity B can start one day before activity C starts.
• The FS-2 days relationship between activities B and D indicate that activity D cannot start until activity B is completed minus two days. In other words activity D can start 2 days before activity B is completed.
• The SF-3 days relationship between activities E and C indicate that activity C can not finish until activity E has started minus 3 days. This means that activity C can finish 3 days before activity E starts.
• The FF-4 days relationship between activities E and D indicate that activity D can not finish until activity E is completed minus 4 days. Therefore activity D can finish 4 days before activity E finishes.

The network diagram represents the scheduling logic of the project. This scheduling logic consists of the activities and the logical relationships or dependencies that exists between the activities. We need to determine what the logical relationship between the activities are and then use these relationships to create the network diagram for our project. 

Some relationships are fairly obvious to determine for instance you can not paint the wall before the wall is built, assuming we are referring to a bricks and mortar wall. These dependencies that are legally or contractually required or inherent in the nature of the work are referred to as  Mandatory dependencies and normally make up the bulk of the dependencies in the network diagram.

Some relationships are not that obvious to determine. If for instance you need to tile the floor and paint the walls of a room - which should be done first? If you first paint the wall and then tile the floor the tiler may get tile glue and grout on the walls. If you first tile the floor and then paint the walls the painter may spill paint on the floor or the tiles may be damaged with the scaffolding. These dependencies are called discretionary dependencies, preferred logic or soft logic. Many of the dependencies prescribed by a project management methodology are discretionary dependencies.

We must also remember that some dependencies involve a relationship between project activities and non-project activities, usually outside the project team’s control. These are referred to as External dependencies. An example of an external dependency can be the obtaining of a environmental impact assessment done by a third party.

Internal dependencies involve a precedence relationship between project activities and are generally inside the project team’s control. For example, if the team cannot test a machine until they assemble it, this is an internal mandatory dependency.

The minimum information required to build the network logic diagram is the activity (number and/or description), the activity duration and the predecessor - see Figure 8.

From the information displayed in the table with the scheduling data (Figure 8) it is easy to compile the network diagram (Figure 9). We must keep in mind that the durations allocated to the activities at this stage may be fairly high level estimates as the resources may not necessarily been allocated to the activities yet and as such the durations may be subject to adjustment once the resources are assigned to the activities. See my post "From Stakeholder to Budget" for more information in this regard.

Once the network logic is sorted out we can start to calculate the early start and early finish dates for every activity - and this exercise we call a forward pass. But what do we mean by "forward pass", "Early Start Date" and "Early Finish Date"?

Forward pass:- A critical path method technique for calculating the early start and early finish dates by working forward through the network diagram from the project start date or a given point in time.
Early Start date (ES):- the earliest possible point in time when the uncompleted portions of a schedule activity can start based on the schedule network logic. The early start date of the first activity in the network diagram is set as equal to zero. In a FS relationship as is the case with the example in Figure 10, The early start date of the successor(s) activitie(s) are set as equal to the early finish date of the predecessor activity.
Early Finish date (EF):- the earliest possible point in time when the uncompleted portions of a schedule activity can finish based on the schedule network logic. The early finish date of an activity is calculated by adding the activity duration to the early start date. (EF = ES + Duration).

Let's look at a simple example of a forward pass:

In order to calculate the early start and early finish for every activity we start at the beginning (start activity) and work from left to right until we reach the end activity. There are more than one method that can be used to calculate the early start and early finish dates for each activity - we will here only discuss the most commonly used method that also happens to be the easiest method to use.

• Start:-The start activity kicks of the project. In this example the start activity is a milestone with a duration of zero days. The project starts on day zero and due to the fact that the start activity has a duration of zero, the early start and early finish for the start activity will both be zero.
• Act A:- This activity has a FS relationship to the start activity meaning that as soon as the go-ahead for the project is obtained, this activity can start. If the approval is obtained on day zero then the earliest that act A can start (ES) is on day zero. Using the formula EF = ES + duration we can calculate the EF date for this activity. EF = 0 + 2. The EF is therefore day 2.
• Act B:-This activity also has a FS relationship to the start activity meaning that as soon as the go-ahead for the project is obtained, this activity can also start. If the approval is obtained on day zero then the earliest that act B can start (ES) is on day zero. Using the formula EF = ES + Duration we can calculate the EF date for this activity. EF = 0 + 5. The EF is therefore day 5.
• Act C:-This activity has a FS relationship with act A. Therefore if the earliest act A can finish is on day 2, then the earliest act C can start is on day 2. The EF is calculated as 2+6=8 using the formula (EF=ES+Duration).
• Act D:-This activity has a FS relationship with act A. Therefore if the earliest act A can finish is on day 2, then the earliest act C can start is on day 2. The EF is calculated as 2+7=9 using the formula (EF=ES+Duration).
• Act E:-This activity has a FS relationship with act A as well as with act B. The FS relationship stipulates that act E can not start unless both the predecessors (A and B) have been completed. Act A can be completed at the earliest on day 2 and act B can be completed at the earliest on day 5. Therefore due to the fact that act E can not start before both A and B are completed, the earliest act E can start is on day 5. The EF is calculated as 5+5=10 using the formula (EF=ES+Duration).
• Act F:-This activity has a FS relationship with act B. Therefore if the earliest act B can finish is on day 5, then the earliest act F can start is on day 5. The EF is calculated as 5+2=7 using the formula (EF=ES+Duration).
• Act G:-This activity has a FS relationship with act B. Therefore if the earliest act B can finish is on day 5, then the earliest act G can start is on day 5. The EF is calculated as 5+3=8 using the formula (EF=ES+Duration).
• Act H:-This activity has a FS relationship with activities C, D and E. The FS relationship stipulates that act H can not start unless all the predecessors (C,D and E) have been completed. Act C can be completed at the earliest on day 8, act D on day 9 and act E can be completed at the earliest on day 10. Therefore due to the fact that act H can not start before C,D and E are completed, the earliest act H can start is on day 10. The EF is calculated as 10+2=12 using the formula (EF=ES+Duration).
• Act I:-This activity has a FS relationship with activities E, F and G. The FS relationship stipulates that act I can not start unless all the predecessors E, F and G) have been completed. Act E can be completed at the earliest on day 10, act F on day 7 and act G can be completed at the earliest on day 8. Therefore due to the fact that act I can not start before all three the predecessors (E, F and G) are completed, the earliest act I can start is on day 10. The EF is calculated as 10+3=13 using the formula (EF=ES+Duration).
• Finish:- The finish activity is, just like the start activity, a milestone with zero duration. The finish activity is dependent FS on act H and act I. The earliest H can be completed is on day 12 and for I it is day 13. The finish milestone therefore falls on day 13.

We have now completed the forward pass of this example. What information did it make available to us?

• The earliest day on which every activity can start and finish.
• The shortest time span within which the project can be completed namely 13 days.

Once we have completed the forward pass we can do the backward pass to calculate the latest day on which every activity can start and finish. Let's look at what we mean by:

Backward Pass:- A critical path method technique for calculating the late start and late finish dates by working backward through the schedule model from the project end date.

Late Finish date (LF):- the latest possible point in time when the uncompleted portions of a schedule activity can finish based on the schedule network logic. The late finish of the last activity (Finish activity) is set as equal to the early finish of that activity as calculated by the forward pass. In determining the late finish dates of every other activity we simply ask the question "If the latest the successor can start is day X and the FS relationship stipulates that it can not start until all of the predecessors are completed, then what is the latest date on which the predecessor(s) can be completed?"

Late Start date (LS):- the latest possible point in time when the uncompleted portions of a schedule activity can start based on the schedule network logic. The late start of every activity is calculated by the formula LS = LF - Duration.

Let's look at how we do the backward pass. In order to calculating the late start and late finish dates for every activity we start at the end (finish activity) and work from right to left until we reach the start activity:

• Finish:- As stated, the LF of the last activity in the network diagram is set as equal to the EF of that activity. In this case (Figure 11) it is day 13. As this finish activity is a milestone with zero duration the LS will be the same as the LF as calculated by the formula LS = LF - Duration.
  
• Act H:- If the latest date of the finish activity is day 13, then the latest act H can finish will be day 13 as there is a FS relationship between act H and the finish activity that stipulates that the finish activity can not start until act H is completed. The LS = LF - Duration, that is 13 - 2 = 11. The latest act H can therefore start is day 11.
• Act I:- If the latest date of the finish activity is day 13, then the latest act I can finish will be day 13 as there is a FS relationship between act I and the finish activity that stipulates that the finish activity can not start until act I is completed. The LS = LF - Duration, that is 13 - 3 = 10. The latest act I can therefore start is day 10.
• Act C:- If the LS date of act H is day 11, then the latest act C can finish will be day 11. The LS= LF-Duration, that is 11 - 6 = 5. 
• Act D:- If the LS date of act H is day 11, then the latest act D can finish will be day 11. The LS= LF-Duration, that is 11 - 7 = 4. 
• Act E:- There is a FS relationship between act H and act E as well as between act I and act E. Therefore act E can not finish later than the start dates of either act H or act I. The LS of act H is day 11 and that of act I is day 10. Therefore the latest act E can finish will be day 10. Finishing act E on day 10 will provide for act I to start on day 10 and will not be a problem for act H starting on day 11. The LS= LF-Duration, that is 10 - 5 = 5. 
• Act F:- If the LS date of act I is day 10, then the latest act F can finish will be day 10. The LS= LF-Duration, that is 10 - 2 = 8. 
• Act G:- If the LS date of act I is day 10, then the latest act G can finish will be day 10. The LS= LF-Duration, that is 10 - 3 = 7.

• Act A:- There is a FS relationship between act A and activities C, D and E. This means that act A can not finish later than the late start dates of any of these three successor activities. The late start dates are C equals day 5, D equals day 4 and  E equals day 5. Therefore the latest act A can finish will be day 4. The LS = LF-Duration, that is 4 - 2 = 2.
• Act B:- There is a FS relationship between act B and activities E, F and G. This means that act B can not finish later than the late start dates of any of these three successor activities. The late start dates are E equals day 5, F equals day 8 and  G equals day 7. Therefore the latest act B can finish will be day 5. The LS = LF-Duration, that is 5 - 5 = 0.
• Start:- There is a FS relationship between the start milestone and activities A and B. That means that the start activity can not occur later than the latest of the start dates of either act A or B. The LS for A equals day 2 and that for B equals day 0. Therefore the latest date for the start activity is day 0.

We have now completed the backward pass and in doing so calculated the latest dates on which every activity can start or end.

The Critical Path is generally the sequence of schedule activities determining the duration of the project and is:

• The longest path through the project. 
  
• The path with the least float.

See figure 14 for the critical path of our example project:

On this project it would be a good idea to watch carefully over Act B, Act E and Act I. If there is any slippage on any one of these three activities it will delay the project end date.

A project can have multiple critical paths and critical paths can also change due to progress made or not made on the project. If for instance in the above example act A that has initially had 2 days of float, for some reason is only completed on day 6 and not on the latest day 4 as originally planned, the critical path will then be as follows (see figure 15).

How many days float does activity E have?

a) 6 days
b) 10 days
c) 0 days
d) 9 days

For the model solution please go to model answer

Enjoyed this article?  Leave a comment below; or  share it with your friends – Tweet, Like, Follow, Pin it with the share buttons in the side bar

The objective of this presentation is to discuss the compressing of a project’s schedule in as simple and easy a way as possible.

What is schedule compression?

Whenever we find ourselves with a project schedule that indicates that the estimated project finish date is later than the finish date required by the project stakeholders we need to find ways to compress the schedule. In other words we need to find ways to be able to complete the project within the required time frame. There are numerous ways or strategies that can be followed to do this, of which the most commonly used techniques are:

• Fast tracking.
• Crashing.
  
• Resource reallocation.
  

What is fast tracking?
Fast tracking is a schedule compression technique where we change the logic of the project schedule by overlapping critical activities rather than working them strictly in sequence. For instance, if we have a project scheduled as follows:

According to the schedule it will take 18 days to complete this project. If it was a requirement that the project must be completed within 15 days then we should find a way to compress the schedule from 18 to 15 days – that means we must somehow save 3 days.

Fast tracking is a technique where we run two or more activities concurrently and not in sequence as currently scheduled. There are some aspects that need to be kept in mind such as:

• In order to shorten the project (to save the 3 days of the duration) we will have to shorten the longest string of activities, called the critical path (indicated in red). That means that two or more activities on the critical path will have to be overlapped.
• Activities selected for fast tracking should have a duration longer than the number of days that is required to shorten the schedule. It will not be sufficient to run two activities, one with a duration of two days, concurrently and hope to save three days off the schedule. The most that the schedule can be shortened will be two days and therefore another or an additional activity should be selected for compression.
• Care should be taken if the activities selected for fast tracking share the same resources. If it is the same resource working on both activities then that resources may become scheduled to work more hours than what is humanly possible for the period of the overlap.
  

In the example schedule above the best candidates for fast tracking would therefore be activities A, B, C and D. Some of the possible scenarios could include:

• Executing activity A and activity B concurrently. That will save a maximum of two days.
  
• Executing activity B and activity C at the same time. That will save a maximum of five days.
  
• Executing activity C and activity D simultaneously. That will save a maximum of four days.
  
• Overlapping activity A and activity B with one day, activity B and activity C with one day and activity C and activity D with one day.
  

The most important aspect that should be kept in mind is that fast tracking can introduce more risk into the project. If the project was originally scheduled in such a way that activity B cannot or should not start before activity A is completed, then it is safe to assume that there must have been a very good reason for this to be the case. For instance if activity A is the unloading and safeguarding of the rifle on the shooting range and activity B is handing it back to the shooting instructor I am sure you will appreciate the risk if you are the shooting instructor and I am attempting to do both activities at the same time!

The bottom line is fast tracking should only be done if the risk introduced by changing the order in which activities are executed, can be managed.

Above is an example of the same project fast tracked by overlapping activity B and activity C by three days. The project is now scheduled to be completed in 15 and no longer in 18 days. Bear in mind this is only valid if:

• The nature of activities A and B are such that the overlap is physically possible.
  
• The risk can be managed.
  
• The overlap is not causing an unmanageable schedule overload for the resources involved.
  

What is crashing?
Crashing is a technique used to shorten the estimated schedule duration for the least incremental cost by adding more resources. Crashing works only for activities on the critical path where additional resources will shorten the activity’s duration. Bear in mind that not all activities can be completed in a shorter timeframe if more resources are added. Activities where a lot of communication and creativity is involved (for instance creating the WBS) will most probably take longer if more resources are added. On the other hand some activities are excellent candidates for crashing for instance an activity where one labourer is scheduled to dig a trench of 100 meter long in four days. Using 2 labourers could possible shorten this activity to 3 days. Using 4 labourers could possibly bring it down to 2 days etc.

Care should be taken when estimating what impact the adding of resources on the duration will have as it is not just a mathematical calculation where we can assume by doubling the number of resources we will halve the duration. The measure of compression can for example be impacted by:

• Whether the nature of the activity lends it to be compressed by adding more resources.
  
• The type and number of resources added.
  
• How much of a learning curve the new resources will have as things can at first get extremely slow before it starts to speed up. 
  

Let’s look at an example of a project estimated to take 18 days to complete:

If in the above example the project needed to be completed in 15 days and we decide to use crashing, how could we do it? When selecting the best activities for crashing we should keep in mind that:

• As with fast tracking, only shortening activities on the critical path will result in compressing the duration of the project.
  
• Again, the longer the activity the bigger the potential for compressing it.
  
• The cost vs. duration compression ratio will not be the same for all activities. The objective is to implement the most economical alternative.
  

If for instance in the example above, we decide to assign two additional resources to activity B. We also estimate that if there are three resources assigned to activity B then the activity can be completed in 4 days as compared to 7 days if only one resource is assigned. This would mean that we now estimate to complete the project in 15 days as per figure D:

When selecting activities for resource reallocation we should take into consideration:

• The activity to which the resources are moved must be on the critical path.
  
• The activity from which the resources are moved must not be on the critical path.
  
• The resources moved must be appropriately skilled to complete the activity to which they are reallocated to.
  
• There may also be a learning curve for them on the new activity.
  

If in the above example (Figure E) we have decided to move 2 resources from activity G to activity B then the schedule could typically look as follows:

In the above case Activity B is compressed from 7 to 4 days due to 2 additional resources assigned to this critical activity. Activity G will now take 4 and not only 2 days to complete due to two of the resources taken away from this activity. The net result is that the duration of the critical path (and therefore for the project) is reduced from 18 to 15 days. The duration of the non-critical path F, G, H and J is extended with 3 days with the result that the amount of float on this path is reduced from an original of 9 days to 4 days after the resource reallocation.

Any one or a combination of any of these techniques can be used to do schedule compression – keep in mind however that if a second round of compression is required, the first step is always to confirm what the latest critical path is as the previous compression could have created a new critical path. 

The objective of this presentation is to make Earned Value Management (EVM) as simple and easy as possible, therefore we will only discuss the basic and most commonly used formulas. So let’s have a look what EVM is all about.

What is Earned Value Management?

EVM is a method for measuring project performance. It compares what is actually happening on the project against the approved baselines and helps us to answer questions such as:

• Where are we on the project money and time wise?
  
• Will we make it within budget and schedule?
  
• What do we need to do to get back on track?

It is important to note that EVM does not measure in days, weeks or months - It measures in monetary terms. 

How do we determine Planned Value (PV)?

We need to know what portion of the project is scheduled to be completed by the reporting date – normally referred to as “today”. 

 As time moves on we will see that the PV becomes more. Let’s now assume that the timeline has moved on and that by today we have scheduled 50% of the activity to be done. The PV will now be 50% of the BAC, which is $20K. At 75% scheduled the PV will be $30K. Once the reporting date is the same or later than the scheduled finish date of the activity it means that the total activity was scheduled to be completed by this date. Therefore the PV now becomes and stays the same as the BAC = $40K. The planned value is therefore that portion of the BAC estimate of the activity that is scheduled to be done by the reporting date.

How do we determine Earned Value (EV)?

EV is also based on the BAC of the activity. EV is determined by calculating what portion of the BAC has been done, irrespective of what portion was scheduled to be done. 

Let’s assume that we have an activity that we estimate will cost $40K to complete. (BAC). Let’s also assume that we have already completed 25% of the activity by the reporting date. The EV will then be 25% of the BAC, which is 25% of $40K = $10K. The passage of time does not change the EV – only the amount of progress made in completing the activity. Let’s now assume that we have completed 50% of the activity. The EV will now be 50% of the BAC, which is $20K. At 75% completed the EV will be $30K. Once the activity has been 100% completed it means the EV now becomes and stays the same as the BAC, in this example $40K. The earned value is therefore that portion of the BAC of the activity that is completed, whether it was scheduled to be done or not.

How do we determine Actual Cost?

How do we determine the variances?

How do we calculate the variances on the project? In other words how do we determine how our time and cost performance measures against our baselines? Let’s assume that we have a project with the following measurements: We have planned to do $40K worth of work (PV), we have done $40K worth of work (EV), and it actually cost us $40K to do the work (AC).

Even without the use of formulas we can see that in this example the project is exactly on schedule and on budget, but let us look at the variance formulas.

 What will the schedule variance (SV) be?  SV is determined by comparing what we have done (EV) with what we have planned to do (PV). Therefore SV = EV – PV. In this example SV = $40K -$40K and that equals 0. In other words no schedule variance as we are on schedule.

How would we determine the cost variance? CV is determined by comparing what we have done (EV) with what it cost us to do it (AC). Therefore CV = EV – AC. In this example CV = $40K - $40K and that equals zero indicating that we have no cost variance as we are exactly on budget. 

How do we determine the Indices?

Let’s assume again we have a project where the PV, EV and AC are exactly the same on $40K. From the variance analysis we saw that the project was on schedule and on budget. For calculating indices we again only use PV, EV and AC – but as we are now looking at the relationship between them and not the variance, we divide EV by PV for the Schedule Performance Index (SPI) and divide EV by AC for the Cost Performance Index (CPI). Here we see that SPI = EV / PV and that gives us $40K / $40K = 1. A SPI of 1 means that our schedule progress on the project is exactly as we have planned. Therefore we are progressing at 100% of the rate scheduled. CPI = EV / AC and that gives us $40K / $40K = 1. A CPI of 1 means that for every $1 we invest in the project we are making $1 worth of progress. Therefore we are exactly on budget

How can we use EVM to do forecasting?

The most commonly used forecasts are:

• ETC – how much money do we need to complete the rest of the project?
  
• EAC – how much will the project cost us in total?
  
• VAC – how much will we be over or under budget at the end of the project?
  

How do we determine the Estimate to Completion?

We see the EAC is higher as our previous forecast. The reason for this is that up to now our cost performance was not too good (CPI = 0.91) and therefore if we continue this trend we will need a larger budget for the project.

If we know what ETC is we can add what we have already spent (AC) to the ETC to arrive at a forecasted EAC. Let us assume that we re-estimated the ETC to be $35K and AC is $33K. Therefore we will forecast an EAC of $68K for the project.

As previously stated re-estimating the ETC can be more accurate but also more time consuming. This method takes our experiences on the project to date into account and the forecasted ETC also takes applicable risk responses and corrective actions into consideration.

How much will the budget to be over or under (VAC)?

Variance at Completion, what we normally refer to as how much will we be over or under budget at completion, is calculated by subtracting EAC from BAC. Therefore VAC = BAC – EAC. The forecasted value of the VAC will obviously depend on our forecasted value of EAC. If for example BAC = $60K and EAC = $68K then VAC = $60K (BAC) - $68K (EAC) indicating that we forecast the project to exceed the approved budget by $8K. Using one of the other methods to calculate the EAC, we will obviously calculate a different value for VAC.

Please take note that there are much more to EVM – this discussion only covered the most basic aspects.

So we have compiled a Work Breakdown Structure (WBS). Great! – so what? How does this help us? How can we use this to get to a realistic budget for our project? Let’s start at the beginning.

From Need to WBS.

The main ingredient for identifying what is required from the project is to identify the project’s stakeholders. Easier said than done – there are only a potential of almost 7,3 billion stakeholders out there. The trick is to identify those stakeholders that most probably can and will influence our project. But that’s another story and let’s assume that we got this one covered. Once we have identified our key stakeholders we can find out what they need from the project. We can even be very efficient and unpack the needs into project objectives, the project objectives into requirements and magically get all key stakeholders to agree upon these requirements. At the end of the day we need to be able to define what this project is all about. That top block of the WBS. Call it what you will - the end objective, scope statement, work to be done or whatever.

From WBS to work package

Once we have identified the highest level of the WBS we can start figuring out what all the work is that needs to be done in order to ensure that we meet all the requirements of our stakeholders. We therefore start unpacking this top block into lower levels - always asking “what does this block consist of?” and the answer giving us the next level of detail. We can continue with this exercise until we get to the point where it does not make sense to unpack the lowest level block any more – sometimes called the Work Package level. We have reached the level where we can quite easily define what this little portion of the project is all about, give it to someone to do and monitor that it gets done properly.

From Work Package to Activity

The problem with a work package is that we all think that we agree what we mean by it while in essence each of us only agree on our own version of the truth! In order to ensure that we all agree on the same version of the truth we need to unpack the work packages into the activities required to do the work. This we normally call a WBS dictionary. There are other things we should also define in the WBS dictionary such as a more comprehensive description of the work package, the skills requirement, the acceptance criteria, etc. The main objective from a planning perspective is that we need to get to a list of all the activities required to complete the project.

From Activity to Network diagram

What is the minimum we need to sort out in which order we are going to do the work? We need the activity, its duration (that may depend on the specific activity effort required and the number resources available) and the logic – for instance which activity must be done before, after or together with which one. We can now start putting the network diagram together. Why do we need this Network diagram? – Because it would be quite handy to know how long it will take us to complete the project and which string or strings of the activities will determine this duration. If activity C can only be done after activity B is completed and activity B can only be done once activity A is completed we obviously need to keep a keen eye on activity A, B and C to ensure we get it all done in time!

From Network diagram to project schedule

If we know the logical order in which the activities need to be executed, the resources required for each activity, when these resources are available, when we will be working on the project and when not, etc., it is quite easy to calculate the exact dates on which each activity is planned to start and be completed. These dates, and especially the final date, is what our key stakeholders are so interested in. It is normally here were all the fun and games begin as the stakeholders sometimes believe these dates are cast in concrete while in real life they are our best guesses of multiple aspects that can influence these dates. But we need some order and therefore we agree to stick to these dates.

From project schedule to budget

Knowing when every activity will be executed, which resources (human, equipment, material, etc.) will be needed and what the cost of each of the resources are puts us in the position to calculate how much each activity will cost us. We can also now roll these cost up to phase and project level and presto – we have half a project budget. The other half is that we also need to figure out how much money we need when on the project – a spending cash flow projection. For this we need the project schedule. Once we know how much the project is going to cost us and at what rate we are going to spend the money we are in a better position to control the project cost. Only a better position – not total control as there are these little inconveniences on projects we call change requests, risks, issues, and anything else Murphy can think of to spice up our lives that can play havoc with our estimates.

The short cut

With the help of project management and scheduling software tools we have become used to rolling most of these steps into one. It’s quite nice to quickly hop onto the software tool and start defining the activities, linking them together, assigning the resources and printing the WBS, schedule, budget, etc. - only to realize that we forgot to define who the stakeholders are. Not that they are important – they are only the reason for our project!

Four of the common project management terms that seem to cause huge confusion with many project professionals are Assumptions, Constraints, Risks and Issues. The reason for the confusion may have its origins in the close relationship between these four terms. Another reason may be that as project managers we are sometimes tempted to employ C.Y.A strategies to protect ourselves.

Assumptions

Making invalid or sometimes ridiculous assumptions are one of our favourites in our C.Y.A strategy. For instance: “We assume that management supports our project.” How about asking them? And if we are worried that their support will not last the whole project then we should revisit our stakeholder management strategy to ensure their continuing support! A problem with assumptions in everyday life is that in order to continue with life we are forced to make them every day – without assuming that somebody will find this discussion interesting I may as well stop writing it. What we do not do in everyday life is to document our assumptions and for effective project management that is a big problem. So what is a valid assumption in project management? If we look at the standard definition of an assumption we find (a) it is something that cannot be proved to be true or false. That eliminates all the things we know already exist. If we are uncertain we can find out and it may or may not be a limitation (constraint) to the project. And (b) it is something that we need for planning purposes. That means that the assumption must in one way or another have an impact on our project planning.

A valid assumption may therefore be assuming that the exchange rate between the local currency and a foreign currency will stay within a certain range.  We cannot prove it to be true or false at this stage and we need some conversion figure for project cost or income estimations. From this we can see the close relationship that assumptions have with risks. What if the exchange rate moves outside this assumed range?

Constraints

This one should not be a problem. We either have enough time to do the project or we don’t. If we don’t have enough time, money, skills or whatever it is a constraint and we must find ways to complete the project successfully within the boundaries of these constraints – this we normally do by working smarter or getting the limitation relaxed.

Risks

A close relative to assumptions. Risks are, just like assumptions, also based on uncertain future events. The important aspects of risks are (a) uncertain future event and (b) impacts positively or negatively on one or more of the project’s objectives. Many risks can be uncovered by playing devil’s advocate with our assumptions. What if the assumption is not true? What is the probability of it (the risk) happening? What will be the impact on which of the project’s objectives if it happens? One of the typical risks on a project can be defined as: “Due to the complicated nature of the project, the key sub-component to be delivered by a vendor may be of unacceptable quality causing rework that will result in delays, cost overruns and / or stakeholder management problems.”

Issue / Problem / Benefit

An issue or problem is something that has already happened and requires our attention. As in the previous example, if the risk occurred namely that the sub-component delivered is of unacceptable quality, it is not a risk anymore. It is now a problem that needs to be dealt with. Issues are not always risks that have materialized. Issues can be anything that happened that is causing a problem or a benefit to the project. However, most of the times when we analyse the issue, we may find that it was a risk that we should have identified – but then again, we know hindsight is an exact science.

How do they impact each other?

Let’s look at a simple example of how these different aspects relate to one another.

Constraint: Lets imagine a project where we have identified a limitation that we do not have enough funds to finance the total project. One of our solutions to this problem may be that we plan to finance the latter part of the project by generating income from the sales of a scaled down version of the product while enhancing the product to meet all of the requirements.  

Assumption: One of the critical assumptions we made in the above scenario is that we will be able to generate enough income to fund the latter part of the project. Asking the “what if” question can in turn help us to identify a risk.

Risk:  From the analysis of above assumption we could have identified and defined the threat (negative risk) as: “As a result of a competitor releasing a similar product before us, the sales of the scaled down version of the product is slower than anticipated with the result that we cannot raise enough funds to complete the project.” We need to analyse the probability of occurrence and impact of this risk and, if required, define a plan of action on how to cope with this risk.

Issue / Problem: If this concern we have with a competitor beating us to the finish line occurs, we will be confronted with slow (or possibly no) sales and therefore not enough income to finance the latter part of the project. If we have identified this issue previously as a risk then we would hopefully already have a plan to address the problem.

How does this impact our project?

Murphy’s Law stating “There is never enough time to do it right the first time, but there is always enough time to do it over” comes to mind. Sometimes we are so busy fighting fires that we do not allow ourselves the time to do a proper job and not doing a proper job in the first place is the reason why we are fighting the fires!

Ever wondered what the relationship is between the 47 PMBOK® project management processes on the one hand and the 10 knowledge areas, process groups and project phases on the other hand? The simple answer is that they are all slightly different views of the same 47 processes. No matter what we do as project managers on our projects we will most probably be busy with one or more of the 47 processes. Please bear in mind that these 47 processes are not the alpha and the omega of project management, but can be considered to be good practice on most projects most of the time.

What do the 47 project management processes describe?

According to the PMBOK® guide project management processes are linked by specific inputs and outputs where the outcome of one process becomes the input to another process but not necessarily in the same process group - a constant loop like the circle of life. Take for instance the process of identifying stakeholders that in practice can rely on inputs from almost any of the other processes and can also be the input to almost any of the other processes such as those involved with requirements, quality, communications, risk, procurement or stakeholder relationships. Each process can also consist of various activities required to execute the specific process and these activities represent the work to be done to complete the project.

What do the 5 project management process groups describe?

It may best to first describe what process groups are not - process groups are not project life cycle phases. It is a logical grouping of the 47 individual project management processes into groups describing the initiating processes, planning processes, executing processes, monitoring and controlling processes, and closing processes. The 47 processes in the process groups may be executed and may be recurring within each phase of a project. Take for instance the initiating and closing processes - each phase of a project needs to be initiated and closed. All of this still does not tell us why we need the process groupings. The process groups reminds us that no matter what we do on a project it will be initiated, planned, executed, monitored and controlled and eventually closed down. These process groups and their processes guide us to apply appropriate project management best practices during the project to drive the project to completion in a controlled manner.

What do the project life-cycle phases describe?

There sometimes seem to be confusion between project phases and process groups and they are then incorrectly seen as one and the same. A project life cycle normally consists of a series of phases and activities that a project passes through from its initiation to its closure and can differ from project to project depending on its area of application. It provides the basic framework for managing the project, regardless of the specific work involved, by defining how the project team envisages to start, plan, organize, carry out and close the project. A phase can contain processes and their accompanying activities from any or all of the process groups or knowledge areas. The detailed planning phase of a project for instance can contain processes from all ten the knowledge areas and from all five of the process groups. One of the easiest ways to distinguish between a process group and a project phase is by considering the process group monitoring and control. Although it is a valid grouping of processes required to track, review, and regulate the progress and performance of the project it does not make sense to have a specific phase for these activities as they are executed from the start to the end of the project.

What do the 10 knowledge areas describe?

The 47 project management processes are grouped into ten separate areas of specialization of which the project manager needs knowledge, specific skills and experience in order to accomplish the project goals. Each of these knowledge areas require the project team to define how aspects from the related processes in the knowledge area will be planned and managed on the project - normally through the use of an appropriate management plan for the specific knowledge area. Again, the knowledge areas defined in the PMBOK® Guide are not the be-all and end-all of project management, but those areas of specialization required by most projects most of the time.

How do they all integrate and interact?

·         The five process groups contain the 47 project management processes.

·         The 47 processes are made up of activities.

·         The activities are the detail of the phases of the project.

·         Executing the 47 processes also require knowledge and skills of the 10 knowledge areas.