This is the second of a 5 part series using probability and other tools to successfully plan and manage projects.
Part 2 – Project Plan creation using Probability
Part 3 – The Mechanics of using Probability to build a project plan
Part 4 – An easy way to capture actuals and manage the plan
Part 5 – Post-Mortem – or using data to improve the planning process
In my first blog post, I walked you through the process of using probability to create a task estimate. Remember: “At its heart, an estimate is a prediction of the future, specifically predicting the number of hours it will take to complete the task.” Well, a project plan is prediction of the future, specifically predicting the time it will take to complete the project.
For task estimating we used this formula:
( (1 * Best Case/Optimistic) + (4* Most Likely) + (1* Worst Case/Pessimistic) ) / 6
So using that formula, let create an example of using this tool to build a project plan. Here we have 3 tasks, two of the tasks we expect are going to take about 100 hours each, and other one will take 80 hours.
|Degree of Confidence|
|Task||Best Case||Most Likely||Worst Case||Mean||Std Dev||50%||70%||90%|
Once we complete our analysis, we can set the desired degree of confidence and have the number of hours calculated for us (blog post 3 will provide the spreadsheets with the formulas). Please note: Task B has a prediction of 95 hours with 50% confidence but 162.6 hours at 90%. This is due to the greater uncertainty in the upper-bound of the estimate.
Building a Plan
Now were this get really interesting is when we put this into a plan. For this example, both A&B must be complete before C can start. I am starting with what the 50% degree of confidence as my starting point (another item to note, if I would have used the most likely estimates, my probability would be less than 50%). So, with 50% probability, I have a project duration 26-ish days and a critical path of A-C.
Now if I use the estimates for 70% probability, I have a project with 30-ish days and a critical path of B-C. The reason the critical path changes is task B has a much wider range of probabilities. So, if we are seeking more confidence in the estimate, the higher the predicted amount of work for that task.
Using probability gives you, the Project Manager, much more flexibility in creating the plan, and understanding the impact to dates within the plan.
Working with a Fixed Date
There are a couple of additional uses with this method. Let’s say you are given a date. (For our simple example, let’s say you are told it must be complete in 24 days.
Doing a little fiddling around, I determined that I would have to set my probability to 40% to create a plan for 24 days. This gives the project manager another tool to help justify dates to a potentially skeptical leadership team.
The last item deals with contingency. One the criticisms I receive with this method, is, “Work expands to fill time”. In other words, if I give someone 50 hours, it will take that person 50 hours. If I give them 70, then it will take 70. Especially if the long-tail to the right (worst case) doesn’t pan out. I think that is fair. So, what I will do is negotiate with a leadership team, the probability they are comfortable with. Using our examples, we will make that 70%. However, I will build the plan at 50%.
The 50% plan shows an end date of Feb 13. The 70% plan shows an end date of Feb 21. Here is the example of that plan. I am using the hours calculated with the 50% plan, but have added 6 days of contingency to take care of the outlier issues.
I hope this technique gives you an additional set of tools to help with estimating tasks and determining project durations. The next post will include examples of the spreadsheets and project plans I use with everything set up to make it easy for you to use. I have also included the table that allows you to determine the standard deviation to use with your selected degree of confidence.
Using and BC of 20, WC of 35 and Expected Value of 24:
MEAN: ((20 + (4*24) + 35) / 6) = 25.2
|Degree of Confidence||Standard Deviation||Calculated Work|
About Murray Ray
Murray is a Senior Consultant at Statêra and has run software and professional services organizations in Telecommunications, ERP, CRM and Contact Center Analytics. He has been building software for the Internet as long as there has been an internet, and takes special pride in building software that people actually like to use.
Prior to joining Statera, Murray has worked with many technology companies over a 25 year career in commercial software development and client services leadership. He has helped guide several software companies through their growth phase to acquisition.
 We are using the STDEV.S formula (calculating the Standard Deviation in a sample)
 See table at the end of this blog post to determine the number of Standard Deviation’s to use for a given probability
 In the project plan, I have set the tasks to Auto Schedule, Fixed Work, and each Resource has a 40 hour calendar.
 I will discuss the use of contingency in another blog post