PROJECT MANAGEMENT TRAINING AFRICA
  • Home
  • About us
    • Who are we?
    • Our Trainers >
      • Dave Fourie
      • Rudie Richter
    • Our Clients
  • Courses
    • PMP/CAPM exam preparation
    • CEPM - Construction and Engineering Project Management
    • Best Practice Project Management
    • MS Project 2010, 2013, 2016 and 2019
    • Quality management on Projects
    • Risks management on Projects
  • Downloads
  • Publications
  • Contact Us

What is PERT and how can we use it?

8/3/2015

5 Comments

 

How can PERT help us?

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.

So what is PERT?

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.

How can PERT help us at activity level?

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:
Let us assume that we obtained the following three estimates for Activity A. Optimistically we can complete the activity in five (5) days. Pessimistically we estimate that it can take us up to Fifteen (15) days, while most likely it will take us only seven (7) days.
Picture
Activity level PERT
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:
Picture
Bell Curve or 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:
Picture
Bell curve for 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:
Picture
Activity estimating uncertainty

How can PERT help us at project level?

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




5 Comments

Is project risk a laughing matter?

27/2/2015

0 Comments

 
Head protector
No - it is not! But that should not stop us from approaching this serious matter with a touch of humor.

This post is a lighter look at risks on projects – a.k.a Porcius the Project Manager's plan to protect himself against the possible phenomenon of a pernicious meteorite pelting him on the pate.
The following discussion between Porcius and his trusted team leader Brutus was overheard the other day:

Risk Identification

"Brutus, do you realize that our project to develop the Pate Protector will be very negatively impacted if anything bad happens to me?" Porcius sighs.

 Although he has his doubts about the marketability of this 'revolutionary' steel helmet that is supposed to protect people against meteorites falling from the sky, Brutus knows better than to enter into a mud wrestling contest with Porcius. "Sure will be Mr Porcius - what kind of disaster do you think may occur" he politely inquires without adding out loud the ‘hopefully’ that springs to mind.

"Well, one thing I am particularly concerned about is the very thing that we are trying to avoid – the possibility of a meteorite hitting me on the head before I can complete our project" Porcius responds. 'Wonderful' Brutus thinks, but says "What a terrible thought Mr Porcius." and softly adds in his mind ‘The idiotic idea that is, not the event occurring.’

“It seems to me that you have identified a risk on our project, Mr Porcius.” Brutus says and adds “I have read somewhere that it is estimated that the probability of that occurring is 1 in 700,000.” With an expression on his face that can easily be mistaken for genuine concern for Porcius’ welfare Brutus thinks ‘Unfortunately there is no confirmed case of anybody ever dying as a result of a meteorite strike to the head.’

“Yes, I have also read that, and that is why I am so concerned.” Porcius responds. Still with the look of genuine concern on his face Brutus asks “How do you foresee that it will impact the project if it happens, Mr Porcius?” Porcius thinks so long before responding that Brutus begins to wonder if Porcius’ private brainstorming session did not perhaps create an intracranial lightning bolt causing a short circuit in his brain.  Brutus quickly discounts the idea as it would require Porcius to have a working brain in the first place. Eventually Porcius’ thoughts comes back to earth and he responds “Extremely high my dear Brutus, extremely high!”

“I cannot agree with you more Mr Porcius” Brutus says with a blissful smile on his face while dreaming of all the positive impacts that it can have on the project. Coming back to the discussion at hand he says “Depending on the size of the meteorite you may be lucky to walk away with only a nasty headache Mr Porcius, but on the other hand if it is a size-able meteorite you may be vaporized. Worst case scenario is that all life on earth may become extinct.”

Brutus drifts into his own make believe world. ‘Just think of it – a small pelt to the head may just cause the much needed spark between his two remaining brain cells. On the other hand if he is vaporized I may take over the project and it will be the first time that this project will have a real project manager. If the worst case scenario happens and all life on earth becomes extinct we would have a problem – there would not be anybody left to sell the Pate Protector to.’

Risk Analysis

“I suppose the important question is what are we going to do about it?" Porcius replies. “I agree Mr Porcius, but would that not require us to first clearly define what we understand as the risk?” Brutus responds. “Sure Brutus, how does this sound as a definition of the risk: Due to a meteorite hitting me (Mr Porcius) on the head, the project will have to be completed without the expert knowledge of the project manager with the result that the project timeline will be delayed and the budget will be negatively impacted”

"Sounds good to me" Brutus responds, "and now that we agree on what we see as the risk what do you think the possibility is that it may happen?"  Porcius thinks for a moment. "I agree with the 1 in 700 000 chance that it may happen, and although that is only a 0.0001% probability I am still concerned that it may happen.” “And the impact to the project if it happens?” Brutus probes. “The project will definitely be delayed by at least 6 months” Porcius thinks out load, “and then the costs will most probably also escalate by at least 25%.”

“Okay Mr Porcius” Brutus says and sums up the discussion thus far with “now that we agree on the risk, the probability of occurrence and the impact we can come up with a plan of action to address it – I propose that we work through all the possible response strategies and see which one or combination of responses will be the best, do you agree?”

Risk Response

“You are right – “how can we avoid the risk?” Porcius responds. “We can go and work underground for instance in an old mine shaft” Brutes offers. “But that may be highly expensive and time consuming with the added possibility that the mine may collapse on us.” Porcius contemplates this for a moment. “I do not believe a total avoidance strategy is really required or feasible” Porcius replies. “Especially taking the new risk of a probable shaft collapse into consideration. Let’s have a look at a mitigation strategy.”

“You mean just bringing the probability and or the impact down to an acceptable level?” Brutus enquires. “That’s right, it should be less costly and less time consuming” Porcius replies. Brutus thinks for a moment. Then another moment ......... and another. “This is a tough one” he says. “It would have been nice if we already had the Pate Protector, then you could have worn it Mr Porcius.” Porcius is deep in thought and does not respond. At last his brain cell fires “I could document all my ideas and then, should I get struck by a meteorite, you can take over” Brutes smiles ‘now we are talking!’ he thinks while putting on his humble face. “A brilliant idea Mr Porcius – although it does not address the probability, it surely will lessen the impact.”

“What about transferring the risk?” Porcius wonders out loud. ‘This is going to be interesting’ Brutus thinks. “How do you propose doing that Mr Porcius?” he enquires while trying to ban the smirk from his face. Fortunately Porcius has his hands full trying to manage his own single thought and therefore does not notice Brutus’ sheepish grin. “I could appoint you as my meteorite guard with the responsibility to ensure that I will not be struck by a meteorite” Porcius beams. ‘What worries me the most is that I know he does not have the capacity to joke” Brutus thinks. “I have a slight variation on that brilliant idea Mr Porcius – let’s appoint a professional meteorite guard, else I may not have the time to be your team leader.” “Good point” Porcius agrees, “Let’s see if we can find one.”

“That leaves us with the last response strategy namely accepting it” Brutus observes. “You know what” Porcius replies, “I am beginning to get second thoughts about the need to address this risk – I think we must just accept the possibility and live with the consequences” Brutus stares at Porcius dumbfounded – ‘when and how did he manage a second spark between those two brain cells?’ He recovers quickly and grabs the opportunity with both hands “As always, you are right Mr Porcius – shall I go and get us some coffee?” Brutus hurries away to get the coffee before Porcius has the chance to apply his mind to the positive impacts that this risk may have on the project. Why would he discuss this if he can blissfully daydream about it….



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

0 Comments

Project scheduling made simple

24/1/2015

0 Comments

 

Why Scheduling?

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.

The Basics of scheduling

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:
Network diagram
Figure 1a: How a network diagram should look
  • One and only one start
  • One and only one end
  • No activities with no predecessor or successor ( except Start and Finish)




When plotting a network diagram by hand it is also good practice to ensure that:
  • All links (dependencies or relationships) are indicated by an arrow. Not just a line  - an arrow with a arrow head indicating which activity is dependent on which.
  • All links start or end either at the front or the end of the activity - never somewhere in the middle.
  • The network flows from left to right - not making a 90 degree turn and then flows either up or down.
  • Early start and finish dates calculated from the forward pass are displayed above or at the top of the activities. 
  • Late start and finish dates calculated from the backward pass are displayed at the bottom or below the activities.
  • The  Early Start (ES), Early Finish (EF), Late Start (LS) and Late Finish (LF) is indicated on the network diagram in the positions as indicated in figure 1b:
Figure 0: Information layout
Figure 1b: Information layout

The building blocks of a network diagram

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:

Finish-to-Start (FS)

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.
 For instance if activity A is obtaining of approval to erect a new building, then activity C (clearing the site), activity D (obtaining the building material) and activity E (obtaining the builders) can commence once the approval has been obtained. 
Figure 2: Finish-to-Start relationship
Figure 2: Finish-to-Start relationship
Bear in mind that the FS relationship does not specify that Activities C, D and E must start once activity A is completed - it means they can start if there are no other constraints delaying the start of these activities.

Examples where the successor(s) cannot start until the predecessor(s) have been completed (FS relationship) include:
  • The final testing (successor) cannot be done until the product is completed (predecessor).
  • The new policy may not be implemented (successor) until it has been approved by management (predecessor).
  • The walls of the building may not be erected on the slab (successor) until the strength of the foundation slab has been verified (predecessor).
As can be seen from figure 2, activity H can not start unless activities C, D and E are completed. Finish-to-Start relationships are seen as the default and are therefore normally not indicated as FS on the network diagram.

Start-to-Start (SS)

In a Start-to-Start relationship the successor(s) cannot start until the predecessor(s) have started for instance:
  • Project management (successor) can not start on the project until the project go-ahead (predecessor) is obtained.
  • Observing the work process (successor) can not start until the worker starts executing the work process (predecessor).
  • Leveling the concrete (successor) can not start until the pouring of the concrete (predecessor)has started.
Figure 3: Start-to-Start relationship
Figure 3: Start-to-Start relationship
In the example in figure 3 there is a SS relationship from activity D to activity C as well as from activity D to activity E. This means that activity C cannot start unless activity D has started and likewise that activity E cannot start unless activity D has started. Please note that there is no relationship between activity A and activities C and E. The completion of A does not directly trigger the start of C and E as the start of C and E is dependent on the start of D. 

Finish-to-Finish (FF)

A Finish-to-Finish relationship means that the successor(s) cannot finish until the predecessor(s) have finished for instance:

  • Project management (successor) can not finish on the project until the final sign-off for the project (predecessor) has been obtained.
  • Leveling the concrete (successor) can not finish until the pouring of the concrete (predecessor) has stopped.
Figure 4: Finish-to-Finish relationship
Figure 4: Finish-to-Finish relationship
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.

Start-to-Finish (SF)

The start-to-finish relationship is the least used relationship in project scheduling. In this type of relationship the successor(s) cannot finish until the predecessor(s) have started for instance:
  • The previous shift (successor) may not finish until the new shift (predecessor) has started.
  • During a relay race the previous athlete (successor) in the relay may not stop until the next teammate (predecessor) starts running with the baton.
Figure 5: Start-to-Finish relationship
Figure 5: Start-to-Finish relationship
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.

Lead

Lead is the amount of time (i.e. number of days) whereby a successor activity can be advanced with respect to a predecessor activity.
Figure 6: Lead
Figure 6: Lead
An example where lead can be used is if you want to start the painting of the building two days before the plastering of all the walls are completed. This can be defined as a FS-2 days relationship.

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.

Lag

A lag is the amount of time whereby a successor activity will be delayed (i.e. number of days) with respect to a predecessor activity. For example once the wall is painted with the primer coat (predecessor) the primer coating needs 2 days to dry (lag) before the final coat (successor) can be applied. The lag relationships indicated in the example as per Figure 7 represent the following:
  • The SS+1 day relationship between activities C and B indicates that activity B cannot start until activity C has started plus one day. In other words activity B can start one day after activity C has started.
Figure 7: Lag relationships
Figure 7: Lag relationships
  • The FS+2 days relationship between activities B and D indicate that activity D cannot start until activity B is completed plus two days. In other words activity D can start 2 days after 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 plus 3 days. This means that activity C can finish 3 days after 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 plus 4 days. Therefore activity D can finish 4 days after activity E finishes.

How do we create the Network Diagram?

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.
Figure 8: Scheduling data
Figure 8: Scheduling data
Figure 9: Network logic
Figure 9: Network logic
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.

Forward pass

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:
Figure 10: Forward pass
Figure 10: 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.

The backward pass

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:
Figure 11: Backward pass
Figure 11: Backward pass
  • 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.

Calculating float

Float, Total Float, Slack or Total Slack is defined as the amount of time that a schedule activity can be delayed or extended from its early start date without delaying the project finish date or violating a schedule constraint.

Float is calculated by the formula Float =   Late start – Early Start, or Late Finish – Early Finish 

Figure 12: Calculating Float
Figure 12: Calculating Float

The float as indicated on the network diagram can be verified by the data in the following table as per figure 13.


According the data we can see that act A can start on day 0 and finish on day 2. It can also start on day 1 and finish on day 3. At the latest it can start on day 2 and finish on day 4.
 Figure 13: Table of float calculations
Figure 13: Table of float calculations
Should it however start on day 3 and finish on day 5 it will have a knock-on effect on the activities further down the line with the effect that the project will only be completed on day 14. We must remember that if we use the float on one activity it can change the float on successor activities. 

Determining the Critical Path

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:
Figure 14: The Critical Path
Figure 14: The Critical Path
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).

Figure 15: Changed Critical Path
Figure 15: Changed Critical Path

Exercise

How many days float does activity E have?

a) 6 days
b) 10 days
c) 0 days
d) 9 days
Scheduling Exercise
Scheduling Exercise
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
0 Comments

SCHEDULE COMPRESSION MADE SIMPLE

12/1/2015

1 Comment

 
Picture
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.
Picture
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:
Picture
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:
Picture
The most important aspect to keep in mind with crashing is that it will add to the cost of the project. We can therefore only consider crashing if we will be able to get the additional funds approved. For this reason we aim to do it as cost effective as possible. Looking at the following table it is clear that the most economical alternative would be to crash activity B as the crash cost is only 833 USD per day saved.
Picture
What is resource reallocation?
Resource reallocation involves moving resources from non-critical to critical activities with the objective to shorten the critical path. This technique does not change the scheduling logic (such as fast tracking does) nor does it require additional resources to be assigned to the project as is the case with crashing. It is used to shorten the estimated schedule duration by more effective utilization of the existing project resources. Let’s assume that we have a project as schedule in Figure E. We are again faced with the requirement that we must compress the project duration by 3 days. This time we decide to use resource reallocation:
Picture
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:
Picture
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. 

1 Comment

Earned Value Management made simple.

3/1/2015

15 Comments

 
What are the building blocks we need for EVM? We need three basic pieces of information to do the calculations:
  • What have we scheduled to do up to date? – (PV)
  • What have we actually done up to date? – (EV)
  • What did it the work we have done actually cost us? – (AC)

Picture
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. 
To determine this we need:
  • The project schedule indicating which portion of the project activities are planned to be done by this date as well as 
  • The estimated cost of each activity – The Budget at Completion or BAC of the activity.

Let’s assume that we have an activity that we estimate will cost $40K to complete. (BAC). Let’s also assume that we have only scheduled 25% of the activity to be done by the reporting date. The PV will then be 25% of the BAC, which is 25% of $40K = $10K.
Picture
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. 
Picture
So what do we need to calculate EV? – We need to know:
  • The estimated total cost for each activity (BAC) from the budget, and 
  • The progress made with completing the activities (percent complete) – this we get from the  progress reporting.

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?
The Actual Cost is the amount that it actually cost to do the work that was done to date.  AC is not based on BAC. AC does not depend on what portion was scheduled (PV). AC is influenced by EV in as far as that there should not be a value for AC if EV is zero, in other words only when some work is done there should be values for AC and EV although these two values can differ vastly as AC can be less, the same as or more than the EV amount.

Picture
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. 
Picture
Let’s now assume that we have a project where we:
  • Planned to do $20K worth of work (PV).
  • Have done $30K worth of work (EV).
  • The work actually cost us $40K.

In this case the SV = $30K (EV) - $20K (PV) that gives us $10K indicating we are ahead of schedule.

The CV = $30K (EV) - $40K (AC) that gives us minus $10K indicating that we are over 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
Let’s assume that the measurements on our project are now PV = $40K, EV = $30K and AC = $33K.

The SPI = EV / PV. Therefore it is $30K / $40K = 0.75. The SPI of 0.75 indicates that we are only progressing at 75% of the rate as per the authorised schedule. We are therefore behind schedule.

The CPI = EV / AC. Therefore it is $30K / $33K = 0.91. The CPI of 0.91 indicates that for every $1 we invest in the project we are only progressing 91 cents worth of work. We are therefore over budget.

Picture
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?

Picture
The Estimate to Completion (ETC) is a forecast of how much money we need to complete the project.

If we have a forecast of how much money the project is going to cost in total (the EAC figure), we can subtract how much we have already spent on the project. In other words ETC = EAC – AC. We will see just now that there are various ways we can forecast the value of EAC.


In the example above the BAC is $60K and the forecasted EAC is $66K. Therefore $66K (EAC) - $33K (AC) = $33K (ETC). In other words our latest estimate is that we need $33K to complete the project. 

Another way is to re-estimate all the work that still needs to be done on the project. This can be more accurate but also a much more time consuming estimate. Should we not have enough of the original budget left to cover the forecasted ETC, we will have to decide what corrective actions are required, if any.

How do we determine the Estimate at Completion?

The Estimate at Completion is a forecast of how much we at this stage estimate the total project will cost. One way to calculate EAC would be to determine what the estimated worth of the uncompleted tasks are (BAC – EV) and then add what we have already spent on the project (AC) to that. That would give us a formula where EAC = (BAC – EV) + AC.
Picture
In the example BAC = $60K, EV = $30K and AC = $33K. Therefore EAC = ($60K – $30K) + $33K = $63K. This method assumes that all uncompleted work will be done at the budgeted rate in other words the future CPI will be 1.

Calculating EAC = BAC / CPI is also frequently used and here it is assumed that what we have experienced on the project to date will continue into the future. This method gives an EAC of $65.9K.  

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.

15 Comments

From Stakeholder to Budget

20/12/2014

3 Comments

 
Picture
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!

3 Comments

Four misunderstood terms - Assumption, Constraint, Risk and Issue

19/12/2014

1 Comment

 
Picture
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!
1 Comment

The 47 PMBOK® project management processes made simple

14/12/2014

8 Comments

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

8 Comments

    Author

    Dave Fourie - freelance project management trainer.

    Archives

    March 2015
    February 2015
    January 2015
    December 2014

    Categories

    All

    RSS Feed

    Subscribe and be the first to be informed of new blog posts and free downloads!

    * indicates required
    Email Format
Powered by Create your own unique website with customizable templates.