Â
Introduction:
At AMIS we have a group of Project Managers who exchange experiences and knowledge with each other. This group read the book of Lawrence P. Leach about Critical Chain Project Management and the group agreed that we would try out the ideas described in this book in our projects. The book takes the ideas from Goldratt (The goal) and transfers them from a Production environment to a Project environment. The results described in the book (projects delivered for far less (up to 40%) than the original time and budget) made us very enthusiastic.
Â
The key issue described in the book is to find the ‘bottleneck resources’ in a project, and make sure that these ones are always at work at full capacity. In case of a System Development Process it usually is a top developer or a functional designer. To make sure they can go on with their work, one has to arrange that there is a buffer of work in the chain before them, so they cannot run out of work. One must also make sure that these scarce resources are working on the things that only they can do, for making the team realize their goal (Project delivered in time and on or below budget), and nothing else.
Â
A second important advice being made in the book is that planning estimates tend to be on the ‘safe side’, meaning ‘pretty high’, and often get used up all the way and then some. This happens because when team members have to make an estimate for a certain amount of work, they build in a safety buffer, because they don’t want to ‘fail’ if they don’t make it in time. Often the team manager and/or the project manager do the same thing to the overall planning, which gives another buffer.  So one would expect that these estimates will be met during the building phase of the project. Unfortunately that is not often true. Why? Because when a project member has finished his part of the job in a certain amount of time, he tends to make it a little better/more beautiful programmed which consumes the rest of the time, and if it doesn’t works out as planned it can even cost more time than originally planned. He can also slow down or wait to deliver it till all time is really consumed.
Â
What did we do.
In the spring of 2008 we did a small project (~€200.000) with a team varying from 3 people at the start of the project to 8 people at the busiest moment of the project. During the kickoff of the project I mentioned the team that I wanted to implement several advices from the book in the project, and find out what the results are. The team had some difficulties with the assumption that they ‘wasted time’ if they finished early with a piece of work. They felt they were looked at as ‘cheaters’. I convinced them that the advices of the book are not about checking up on them all the time. Even more, I told them that according to the book, in a ccpm steered project the project members are expected to work at a normal speed, without stress, including coffee breaks and small chats with colleagues etc. etc., that sounds even better than a normal project!
Â
These are the things we agreed upon:
Â
To work as fast as possible, without ‘working towards a certain amount of hours that was planned’:
- Create a planning using 50% of the original estimates, and put the remaining 50% in a big Project buffer. Â
- Send the Project members to work with that 50% planning, and tell them they should do their best to finish it in that time using the credo’s “good is good enough†and “it doesn’t have to win an award for excellent programmingâ€. also, if they need more time, it’s not a disaster, because the 50% planning also has a 50% chance of making it. This means that a work package will often take 70%, sometimes 100%, and it can also take 40% of the original estimate to build.
To avoid that ‘scarce resources’ fall still:
- Find out what the bottleneck resources are, and create a work buffer before them. In our case it meant our functional designer and one of the developers.
- With the client cooperation we realized that the functional Designer could go on with his work all the time, because if he fell still, the whole project would shift in time
- We took care that necessary pre-work for work that the key developer should do, was ready in time by starting extremely early with it.
Client communication:
- We informed our client that we were going to work this way, which could mean that we deliver earlier as expected, and they should be ready for acceptance testing then, because otherwise we would lose the time we had won before. It was o.k. for them, and if I informed them two weeks before actual delivery, they could set up the team and the environment in time. They were enthusiastic about our approach, since there was a tight deadline, and in this way we would have more certainty about making the deadline in an earlier stage, so they were very willing to cooperate.
Â
Â
Internal communication:
- The Delivery Director and I agreed upon a project status update in the form of a very special graph, described in the book. In this graph only two, relative, values are plotted against each other, namely the project build progress, and the project hours consumption, both as a percentage of the total, see figure for an example:
This graph shows you in one glance how your project is doing: If you stay under the blue line, everything is well. The space between the blue and red line is the orange zone, actions should be taken not to end above the red line, because if you are there, your project will get an overrun. As you can see, at 60% of the project progress measures were taken, because the actual buffer usage line was directing to the red line.
- The data for this sheet I derived from my MS Project planning tool, which I use for the administration of the project
What were the experiences?
Â
Advantages
- We did a very early delivery of important pieces of the project, which gave our client certainty that we would make the deadline
- We made the deadline
- The client was very happy to see what they thought up to work in such an early stage
- We completed the project with a small overrun of 6%, due to a screen that was not thoroughly enough thought out, which cost a lot of time. But thanks to the savings on other project parts, thanks to this method, damage was minimized
- The way in which I reported (with the famous graph) illustrated in a glimpse of an eye how the project was doing
- using the data in MS Project it was easy to drill down to where the losses and gains were, which gave insight for following projects
- Some things actually completed in 50% of the time
- The way we approached the project created commitment at the client’s site to get the requirements clear as early and thorough as possible, and the flexibility in the delivery moment for testing, because they were scarce resources too. Thereby we made a very good impression with them for handling the project in this new way
- Except for the programmer working on the tough screen, there was no stress at all in the team
Disadvantages
- With the way to work according to CCPM IÂ see none
Â
It proved difficult to convince the team that I trusted them to always work as hard as they can during the kickoff session, and during the project the enthusiasm lessened in the team. I have to find a way to get that better. At the evaluation of the project the team told me that I informed everybody about the status of the project, except them (blush), so informing them might be a very good start for keeping up the enthousiasm.
Â
Conclusion
We highly recommend using the Critical Chain Project method. The above mentioned advantages show that it is not so that every problem is solved with this method, but that it is very useful in minimizing losses on project parts where nothing needs to be lost. A big bonus which I hadn’t seen coming was the impression we made on the client, and the cooperation and flexibility on their side that it created.
Maurik-Jan, nice article and good promotion for CCPM. I had the same experience with a project I executed last year. For me the most difficult part of CCPM was to argue with the customer why the whole project could not be done in 50% of the time. Since the rest was the buffer. We delivered the project 20% below budget and 1 month to early. The graph showed me that the chance of early delivery was significant. I announced this 2 months ahead. At that time we had to put a lot of effort in getting the functional acceptance team to start testing 1 month earlier. Hope to manager more of these problems in the future :-).
Regards, Robbrecht