This article is Part 2 of a series of articles that describes a process used to develop a project schedule.
Using the PERT feature of MS Project and collecting three duration estimates allowed us to develop a schedule that lacked most of the “padding” that was generally incorporated into previous task duration estimates. See previous article on how we did this.
The output of running the PERT feature in MS Project translated into the project being 344 days in duration and finishing on 4/26/05.
But within the same schedule I could also see the “Worst Case” scenario. To do this, I simply clicked on the Pessimistic Gantt Option within the PERT Analysis toolbar
When choosing this option, I could see the Pessimistic Duration and Pessimistic Finish. The Pessimistic Duration was 381 days and the Pessimistic Finish was 6/16/05.
You will also notice that within this view, the current Finish and the Pessimistic Finish are side by side. I kept looking at those two finish dates. The more I looked at them, the more uncomfortable I became.
First off, there was nearly a two month difference between current Finish (generated from PERT calculations) and the Pessimistic Finish. This seemed like a long time. But then I got to thinking; this project is going to take nearly a year. This two month delay would only happen if all of the things went wrong that everyone had anticipated. And, given the track record of projects within this company, a two month delay in a year long project would actually be below the average! That made me feel a bit better, but remember, this project had to be better.
The second thing that bothered me was this two month difference was based upon known possible delays. I got to thinking a bit more, and realized that these known delays could actually be called “Risks” to my project schedule. Unfortunately, given the project management maturity level of our organization, we did not perform any formal Risk Analysis, nor was there a process for incorporating those risks into our schedules.
As I packed up my stuff to leave the office for the evening I thought: “I wish there was some way I could incorporate these risks into my schedule.” I knew the stakeholder review meeting was just a few days away and at that time the milestone and project finish dates that we show would be as good as cast in stone!
That evening found me at a local MPA (Microsoft Project Associate) meeting. The event is always a good time. I got to see a few of my peers and swap war stories. But the best part for me was the presenter. She gave an overview of “How to build a Dynamic Project Buffer into Your Microsoft Project Schedule”.
She started off her presentation by defining buffers. Buffers, also called Contingency Reserves, or Time Reserves can be incorporated into the project schedule as a recognition of schedule risk. I just about fell out of my chair! This is exactly what I needed to know. She went on to say that buffers are additional time that is added to the schedule. It can be derived by:
a) a percentage of the estimated activity duration,
b) a fixed number of work periods, or
c) developed by quantitative schedule risk analysis.
She said this information could be found in PMBOK
(3rd Edition)on page 142.
Before diving into the actual “how to” using Microsoft Project, she talked a bit about something called “Critical Chain”. She said this was a scheduling concept unearthed in a book called “The Goal”
by Eliyahu M. Goldratt. She also stated some information could be found on this concept in the newest version of PMBOK
on page 147. She made it clear that what she was about to show was “How to Build a Dynamic Project Buffer into Your Microsoft Project Schedule” and not true Critical Chain project management.
She then opened up the following schedule:
She explained that a Project Buffer gets added at the end of the critical path of a project. She then inserted the Project Buffer. She used 3 days for the Project Buffer Duration:
She changed the logic of the schedule to include the Project Buffer:
She then copied the Finish date for task 10, placed the cursor on the Start date for the Project Buffer and Pasted Special, then chose Paste Link:
Then she clicked on OK. She also made it a point to show us the little indicator in the bottom right corner of Start for Project Buffer. This indicates the cell is linked.
She then copied the Start date for Project Complete, moved her cursor to the Finish date for Project Buffer and again chose Paste Special, Paste Link:
After clicking OK, she removed the predecessor for the Project Buffer:
Next, she demonstrated how the dynamic Project Buffer works. This sample project had a Project Completion date of 2/18/04 and a 3 day Project Buffer. She changed the duration of Task 2 from 5 days to 6 days and the duration of the Project Buffer automatically reduced from 3 days to 2 days:
“Let’s have another task slip” she said, and changed the duration of Task 3 to 7 days. Again, the Project Buffer reduced:
With this second delay, we have used up all the Project Buffer. The Duration is now 0 days. So what happens if we have another slip? She then changed Task 1 in Phase B to 6 days:
Now the over-all Project Completion date slipped to 2/19/04.
“This is awesome”, I thought. Using this approach will resolve my concerns. I will create a Project Buffer for my project with a duration of two months (the difference between the Pessimistic Finish and the current Finish). I can even call this our Project Risk Buffer. This will work!! I headed home for the evening.
Be sure to read next months article about what happened when I took this concept to management.