CCPM. Have you heard about this project management framework? What about the concept of critical path? If you have ever been exposed to project schedules, the latter would probably ring a bell. Critical path is the shortest distance to project acceptance and completion. If the project has 10 tasks to deliver, and 8 of them are critical for acceptance, the critical path will comprise of those 8 tasks. Makes sense?
CCPM is a framework build around the critical path concept. To me it is an effective scheduling technique that enables project managers to truly plan a project instead of merely stringing tasks together to an end date. True planning calls fot a great deal of thought that should go into executing a project and steer it towards success. But to do that, we need to first understand project failure.
Why do projects fail? According to Allan Elder’s whitepaper (link below), most projects fail to meet deadlines on time, on budget, and on scope (OTOBOS) due to the following 5 reasons or diseases of project management:
(a) We are victims of “Bad Multi-Tasking“. In short, we have too many tasks on our plate mainly due to a lack of planning from the task assignor/delegator – your Manager or ‘You, Inc.’ – thus leading to bad task prioritization to procrastination to burnout.
(b) Parkinson’s Law i.e. Work expands so as to fill the time available for completion. The safety we’ve built into our estimates with an intent to avoid the worst case scenario somehow transforms into being our best case scenario. And we are not incentivized to do otherwise.
(c) The ‘Student Syndrome’ is in us and we cannot escape it. So, lets accept the fact that due to the above 2 reasons we are not going to work on that task until the 11th hour – the time we need just enough to complete the task and meet the deadline. We dont know how we do it but we do.
(d) Task Dependency for the wrong reasons. Project completion is dependent on all its tasks being completed on time (task completion date) and on budget (resource availability) but when tasks are integrated, projects get penalized due to time wastage and resources being under-committed.
(e) Task Completion ? Task Delivery. We tend ignore those sneaky little unplanned and unforeseen events that cause delays in the delivery of completed tasks. Project progress is measured based on the tasks completed and not task hand-offs.
CCPM is based on the ‘Theory Of Constraints’ methodologies and is said to have proven a high rate of project success when implemented right. I have not tried it out yet but am in the process on learning how to. Walk with me on this critical path to success and we’ll find out how to keep our projects OTOBOS.
In my follow-up to this post, I will dive more into how CCPM works. Meanwhile, please do read “The Five Diseases of Project Mangement” (PDF) to understand the above reasons in detail. This whitepaper is a keeper.
I’m back from Denver and had a good time. I had a chance to meet and talk over lunch or dinner with some great people in project management. Some of the highlights for me include:
- Meeting the other members of the PMI New Media council. I have been a long-time fan of most of their websites, and it was great to get to know them a little bit. Here’s the team that I’m excited to be a part of:
- Hal Macomber
- Reforming Project Management
- Cornelius Fichtner
- The PM Podcast
- Elizabeth Herrin
- A Girl’s Guide to Project Management
- Dave Garrett
- Project Management 2.0
- Chalyce Nollsch
- Project Management Bistro
- Jerry Manas
- Raven Young
- Raven’s Brain
- Josh Nankivel
- Chatting for a bit with Max Wideman, Tom Mochal, Dennis Stevens, and Aaron Smith and many others too numerous to mention.
- Meeting with Janice Thomas and Mark Mullaly of the VoPM study. The council had the opportunity to ask them some questions about the study.
- Meeting with Greg, the CEO of PMI. Greg discussed PMI’s strategy going forward and we were able to ask some questions and give some feedback. I suggested PMI work with thought leaders of new methodologies such as Critical Chain, Lean, SCRUM and other Agile methods, etc. It sounds like they will be doing some of this with the Virtual Communities (at least with Agile). My hope is that PMI can lead the effort to differentiate the PMBok (which is a framework/standard) from the various methodologies out there. They would be able to demonstrate where the various methodologies mesh up with the PMBoK that way, and show that these are NOT competing models. I didn’t get the feeling that Greg was ready to go seek out thought leaders in these various methodologies more broadly, but perhaps I didn’t explain myself well either.
“Just ask anybody in the organization what to change, and you will find out to what extent people are real experts at bitching and moaning…”
It wasn’t me, it was Goldratt who said it!? Wow, I hope I don’t lose my G-rating on this website.
This is just a short video clip of Goldratt explaining the interconnected components of an organization and how they work together when trying to solve a problem for increasing performance.? He also discusses the need for focusing mechanisms instead of relying on intuition of individuals, even managers who oversee the entire system, because no one can know enough about the entire chain.
I wrote earlier about a potential method of using Critical Chain-stype “mini-buffers” within an element of a traditional project management approach. Now I would like to revisit multi-tasking and how having some experience with the Agile software development methodology called SCRUM has helped me formulate some guidelines. Some of these ideas come straight from Critical Chain too, and a myriad of other methodologies all pointing to the same conclusions.
First there is good multitasking and bad multitasking. Good multitasking may be an essential part of your job. Or you may be working on something where you really need to switch gears after a little while in order to recharge your batteries. Bad multitasking is really the enemy. This can take the form of fire-fighting, or just wandering around from task to task depending on how you feel that day. Both of these reflect a lack of proactive thinking when they occur in abundance.
What’s wrong with bad multitasking anyway?
I’m glad you asked! First, switching from task to task means that even if you are putting full effort into your work, the cycle time from start to finish on any given task is going to lengthen dramatically. See the following illustration for an example.
Second, when you switch from task to task, you introduce overhead into the equation, especially when you are talking about something in a manufacturing setting (Theory of Constraints, Lean) or if you are working on a highly intellectual task. It can take a long time to either set up a production line to run something different through, or remember where you were at the last time you left off.
Remember these are just illustrations and guidelines, not an ideology to be followed blindly. Obviously, there are many examples where you can not finish a task because you are waiting on someone else, for instance. Would you sit idle for a day until they get back to you? Of course not. Prudent judgment is required here, but avoid voluntary bad multitasking whenever you can.
So how can my project team avoid bad multitasking?
Here is where my experiences and research on SCRUM come in. One of the key contributors to mad multitasking is a lack of focus and planning. With SCRUM, each morning we would have a “war room” session for 15 minutes, with a very strict agenda. This is a small piece of SCRUM but a very crucial one. The leader would ask the questions and usually take notes so that he/she can help remove obstacles and have a good sense of what the team is working on that day.
The agenda consists of 3 questions, asked of each team member.
- What did you work on yesterday?
- What will you work on today?
- What obstacles or risks do you see?
This is not a meeting to discuss technical issues or even solutions. Usually 2-3 minutes maximum per person is what should be allowed. The lead should jot down issues or discuss afterwards in more detail.
The goals of the war room meetings are to:
- Foster excellent communication
- Allow for potential synergy in collaboration (by re-using code in software development, but parallels exist in all industries)
- Make sure everyone has clear goals and plans for their work
- Ensure the project manager/lead knows exactly what they need to focus on to remove obstacles and deal with potential risks on the horizon.
Done daily or perhaps a few times a week, this means that everyone has a clear purpose of what task they are going to work on that day, and it helps them focus on that and not jump around to other tasks. This is a good way to eliminate as much bad multitasking as possible by using a proactive approach.
Today I was trying to think of ways to integrate some of the methods and benefits of Critical Chain project management into the traditional PM methodology most companies use. I wanted to pick out one element of CC that would potentially yield the most benefit without much, if any, additional overhead to the project manager. Perhaps this has been written of before, but I haven’t come across it. Most of the CC proponents I’ve come across have an all-or-nothing mentality, so they wouldn’t normally write about this kind of hybrid approach. Here’s what I came up with.
One of the deadliest risks for slipping on schedule is Parkinson’s Law, “Work expands to fill (and often exceed) the time allowed”. I don’t believe that people on the project are lying around doing nothing because they think they have so much time (like a student might). Instead, people may be doing extra analysis and working on some ideas that might yield truly useful features. Having worked as a developer in a project environment, I can say with honesty that my co-workers and I did this a lot. We were well-intentioned, and we did good work. However, I can also safely say that many of the things we worked on didn’t address a specific customer requirement. They were nice little experiments, and developers love experiments.
The difficulty in managing projects is related to finite resources, time, and budget. Effort which addresses stakeholder requirements directly yield the most value, in that they are fulfilling what you promised. Those deliverables should be addressed first and foremost. If you have time left over, then I’d say it might be OK to work on nice little experiments that may add value.
How can you ensure resources are working on the ‘meat’ before they spend time on desert? I don’t suggest micro-management. That is self-defeating, demoralizing to the staff, and time-consuming.
Instead, let’s inject a critical chain technique into how you manage this project. Estimates on tasks are usually inflated to allow for slack time in the eye of the estimator. Let’s take the CC method of removing slack and creating a buffer, and apply it to only the lower levels, either on individual tasks or series of tasks. Take the scheduled time and chop off the last 20% of it. (I wouldn’t bother with anything less than 40 hours in duration) This is now your deadline, and the time afterwards until the “official” deadline is the management buffer. Keep communication with the team open and honest, let them know what you are doing. Their goal now is to get the task done by the new due date. If they are done by then, they can spend some time doing “Google-ish” creative brainstorming and experimentation. If not, that’s when the project manager becomes more heavily involved than normal, helping to remove roadblocks and provide more resources. Of course, the PM should be doing this all along, but now is the time to redouble your efforts. It’s important to let the team know that if they go over this deadline, it’s not the end of the world. It shouldn’t even be a negative thing. It’s just an early alert system, and everyone should know ahead of time that there’s just as much chance of going over this deadline as their is hitting it on time or early. Keep the critical path in mind with your decisions, you may have to let a non-critical path task slide to address a critical one.
By managing the tasks this way, resources are compelled to knock out the things that lead to a specified deliverable first, and add the most value. It doesn’t require adjusting the official schedules, or introduce paperwork overhead. This is simply a management technique.
As a solo developer or on a team, I think it would be great to “eat our frogs first” and then either start the next task early, or have a few days to brainstorm about what we can do to add even more value. Working with a team for a short time with a blank canvas, you can pool the skills and do some great team building while generating some really creative stuff. You could also do additional testing and debugging, or start looking at the next task early and brainstorm about the best way to go about it. Or, a little of everything. Let the ones who like engineering do things to fix bugs, enhance the documentation, and make it scale better. Let the prototypers do their thing.
- Understand CC buffer management and the benefits of it (links below)
- Get your team on board by showing them the WIIFM (what’s in it for me?)
- Keep the critical path tasks in mind for decision making
- For tasks 40 hours or longer:
- Create a CC deadline by chopping off the last 20% of time from a scheduled task
- The last 20% is now a management buffer
- Check status at the CC deadline
- Not complete: Focus support efforts on the task
- Complete: Start the next task early, or have a “Google day”!
For some background on Critical Chain and it’s benefits, here are some references for you. Specifically, you need to understand why you’re doing this well enough to get your team to believe in it too. This probably won’t work well with totalitarian rule.
Hello everyone! I’m sorry it has been so long since my last post. I have been going through a job change, and the last month has been hectic with getting things shored up at my previous company and (trying) to get up to speed at the new company. I recently listened to my favorite podcast, The PM Podcast, and episode 75 is about project monitoring.
I really enjoyed this episode. Upkeep during project execution and finding problems as early as possible has always been an important topic for me. I think that is why I found interest early in the Critical Chain methodology, because it offers great ways to highlight and pinpoint problems early on. In particular, I felt the soft skills addressed in the discussion were very important. After all, you can have mountains of data, but if you don’t know how to present it well or what to do with it, it has no value. My key interests are being able to take quantitative data from something like EVM and combine it with qualitative data in order to target specific work packages, resources, or stakeholders who are having/causing issues.
I will let you listen to the podcast, but it was wonderful. Also check out the accompanying power point presentation here.
Cornelius Fichtner over at The PM Podcast surprised me a while back by inviting me to be an interview guest on his show. I was obviously flattered as he puts out the grand daddy of project management podcasts, and I’ve been listening to the show for many moons. In my opinion Cornelius’ The PM Podcast and Dina Scott’s Controlling Chaos are in a league of their own.
The interview focuses mostly on my background and the differences between the academic and working worlds of project management education. I also mentioned one of my favorite project management books, “Project Management in the Fast Lane” by Robert Newbold. It is one of my favorite because it does a great job at teaching the mechanics and “how to” of doing Critical Chain Project Management.
Take a listen, and if you haven’t already discovered The PM Podcast, I highly recommend going back to listen to past shows. Cornelius does an interview format for most of his shows, and has a lot of great guests. Don’t worry, most of them have much more project management experience than I do!
I responded to a question on the PMI member forums that I wanted to share:
Subject: Critical Chain Project Management
Does anyone have experience with this PM approach/toolset. I have run across some people proclaiming it as the savior of project management (unfortunately, the biggest proponent I met seemed to think that a Project Plan is all there is to Project Management and expressed enough negativity regarding PMI and the PMP designation that I found it hard to give credence to the validity of his information).
I am interested in any validation of its effectiveness beyond anecdotal evidence.
RE: Critical Chain Project Management
Posted by Joshua Nankivel on 01/18/2007
I personally have not had the opportunity to implement critical chain on anything except very small projects. I can give you some good resources however, citing individuals and organizations that have had success with critical chain project management.
1. The PM Podcast Episode #57. – I don’t recall specific examples Alan cited on the show, but I might be wrong. You may be able to contact Alan Elder at the email address listed on Cornelius’ site directly for some direction.
2. The Critical Chain Yahoo Group – has a lot of active contributors who utilize critical chain on a daily basis
3. This whitepaper from Boeing can be downloaded upon request, I requested and read it and it’s a really great overview of how critical chain was used in a real project. Very well written.
4. More case studies
5. Yet another case study
I would add that I have run into some people/articles that seem to be overly confident in critical chain. I think it has great potential, but it’s only a piece of the puzzle. I look forward to using it myself on larger projects in the future.
Also, one of the things I post fairly frequently about on my blog is critical chain project management. If you’re interested in critical chain even the broader scope of project management in general, I’d (of course) suggest it!
Please leave comments about this post!
I corresponded with Vladimir Liberzon after seeing a post he made on the Critical Chain Yahoo Group with a link to a presentation on?Resource Limited Project Management. The presentation deals with managing resource constraints from a Critical Chain perspective and is a good resource for people interested in CCPM. Vladimir’s company, Spider Management Technologies (I used a translator plug-in for Firefox so I could read the site links), also has a software package offering called Spider Project which deals with Critical Chain planning and other aspects. They have a demo version you can download to check it out. I haven’t yet, but plan to soon. My school-issued laptop is locked down so I can’t install anything that isn’t pre-approved by the administration, so I’ll have to try it out on my home PC when there’s some magical time I can conjure up where I’m not at either school or work all day.
Check out Vladimir’s presentation here.