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.

Parkinson’s Law

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.

The Method

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.

Summary

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

The PM Podcast Episode #57
Focused Performance
The Critical Chain Yahoo Group
Critical Chain and the Design Process – MIT
CC whitepaper from Boeing
More case studies
Yet another case study

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.

In the July 2007 edition of PM Network magazine, the cover story is entitled “Small Projects, Big Results”. What a great edition of this magazine, especially the Point/Counter-Point Article featuring yours truly. Anyway, back to the small projects piece. It speaks to the importance of doing sufficient planning even on small projects. I personally use a 4 tier category framework in which I apply various levels of rigor, which I wrote about here.

My only point of contention is regarding communication. Communication management seems to be taken as an implicit assumption by both Olivares and Toledo in their described approaches. Personally, I made a breakthrough on my small projects when I stopped taking communications for granted. That happened after I listened to The PM Podcast Episode 64 with Margaret Meloni as the interview guest. (That is an awesome episode, I recommend it highly) Since then, I have included a short communications plan in my small project plan template. It is a short, simple table that has fields for ‘communication activity’, ‘timing/frequency’, ‘responsible’, and ‘stakeholders’. It normally has 2 lines on it, one for a weekly status report, and a project closure report distribution where ‘timing/frequency’ = upon project completion.

Basically what this does for me is provide a reminder to communicate proactively and hold myself accountable for it. Since I’ve been doing this the major benefits have been less rework and making stakeholders more at ease. They know when to expect regular communications from me, so they feel more in the loop and I’ve found they reciprocate by communicating better with me regarding scope and limitations in the project.

There were several references in the article to regularly scheduled meetings taking 1-3 hours in length, sometimes on multiple days during the week. I disagree with this approach to communications on small projects. From my personal experience, this approach tends to yield a waste of time, fruitless pontification, and inattentive participants especially over a conference call. I have an alternative suggestion.

I have started using SCRUM at work along with my team, and I think the communications guidelines in the SCRUM methodology match my personal preferences for small projects. During the project, you have daily meetings limited to 15 minutes or less, and each team member talks in turn about 3 things:

1. Things I’ve done since yesterday’s meeting
2. Things I’m going to get done today
3. Obstacles in my way

Now, this technique in SCRUM is geared towards communication between developers on the project team. I want to suggest an adaptation for stakeholder communications on small projects.

First, meetings might be weekly or bi-weekly instead of daily. Instead of everyone providing the 3 points of information, the project manager uses these 3 points as a framework for the discussion. I suggest keeping the meeting to the 15 minute limit. Here’s the new set of points:

1. Progress since the last status meeting
2. Plans from now until the next status meeting
3. Status of risks and issues, and is there anything new?

Here is the catch. Don’t try to solve problems in the status meeting. This meeting is only for the 3 things above. Speak in terms of identification and status only. To actually address risks and issues, have a separate discussion with only those people who can contribute.

Of course, most of this can be applied to larger projects too. Communication should be like a laser; focused, efficient, and consisting of only necessary wavelengths (people and content). Instead, it usually turns out to be more like a floodlight; scattered, wasteful (of time), and involving many unnecessary parties.

The moral: Value communication on small projects. Make it explicit, planned, focused, and the best use of people’s time.

Today I listened to one of my favorite podcasts, The Project Management Podcast. Cornelius did a great job of putting it all out on the table as far as earning PDU’s are concerned. Check out the episode here.

I started reading Bas De Baar’s book today, “Suprise! Now You’re a Software Project Manager!” Bas is a fellow contributor over at PMLC, and after hearing his interviews on Controlling Chaos and The PM Podcast, I had to pick this one up.

In the introduction, Bas touches on many key points that I could relate to, and some that I am not sure about yet. Bas makes several references early on regarding how important it is to focus on the stakeholders in any project. He discusses the relationship and progression of interests, expectations, and requirements (which he terms “The Flow of Stakes”. I found this part very interesting as my last post was about soliciting good requirements, and a project I am involved with right now is having some issues creating great requirements.

He also touches on the delineation between project management and software development. This piqued my interest as I currently work on many small software development projects in which I am one of or the sole developer, in addition to managing stakeholder requirements and simplified project management. As I mentioned in my interview with Cornelius on The PM Podcast, once I started applying formal project management methods to my projects, my productivity increased dramatically. I can see the parallel with what Bas is asserting, because essentially I just split my software developer role into 2 roles. Now I am a project manager AND a software developer, even though I’m in the same job as before. By forcing myself to separate the two roles, I have become more proficient at both. I understand my expectations for each role better, and can focus on one mode of thought at a time instead of trying to both functions at once. (If anyone is wondering, I am not schizophrenic, I have just admitted the duality of my job and confronted it!)

Bas provides simple, elegant figures throughout the first chapter to illustrate his discussions. These are very helpful in understanding him fully. If the introduction is any indication, this should be a good read. I’ll keep you posted!

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!

The PM Podcast Episode 065: BS and MBA in Project Management

I listened to Cornelius Fichtner’s new PM Podcast episode today, How do risk attitudes affect your project?

As usual, Cornelius provides great content in this episode. The interview with Janice Preston was very insightful and helped me with the concept of risk management. In school, they teach you that risk management is almost like it’s own little module that you do while planning and insert into the project plan. Sometimes they talk about updating and reviewing it regularly. I’ve never heard them talk about it in the context of the risk attitudes of project stakeholders.

You really need to listen to this episode if you haven’t already, but one aspect I liked was the classification of 4 distinct risk attitudes:

1. Risk Seeker – enjoys and seeks uncertainty in search of greater opportunities, can be overly optimistic and not take possible negative consequences seriously.
2. Risk Averse – uncomfortable with uncertainty, doesn’t like risk
3. Risk Tolerant – reasonably comfortable with uncertainty, but usually sticks head in the sand and ignores them
4. Risk Neutral – analyzes risks and weighs negative/positive possible outcomes and probabilities objectively.

From my experiences with project managers, it appears to me that the majority are Risk Tolerant. I say that based on how little time and effort is usually put into analyzing and planning for risks. I can also identify with these classifications because of people I’ve worked with on project teams. Some people seem to have their heads in the clouds and look for risky solutions when a more proven approach would do (Risk Seeker), and others are conservative to the point of seeming cynical (Risk Averse).

Risk Neutral is the goal. Personally, I’d say I’m more of a Risk Seeker right now, but the knowledge and experience I’m gaining are directing me more towards the direction of Risk Neutral. The tools and techniques of risk management are doing that for me by forcing me to look at uncertainty in more of a formal SWOT analysis where my exuberant optimism can be subjected to some logical scrutiny.

Be sure you head over to The Project Management Podcast and check out this episode.

I posted the response below to a post about project management podcasts on this project blog, and wanted to share. I especially want to give a shout out to Dina and Cornelius, and any other experienced project managers that have been contemplating a podcast or even a new blog. I think it would be excellent to do a series of shows like what I describe below, almost like a soap opera for project managers!

Josh Nankivel wrote:

I really enjoy both the PM Podcast and Controlling Chaos. I think both Cornelius and Dina do an excellent job of getting great guests and having discussions with valuable content.

Perhaps it’s because I’m a student and haven’t been in a PM role for many years like some people, but I don’t find their shows long.

Personally, I’d like to see another show with a different format that follows a story line from the beginning to the end of a project. It would be great to be able to get inside the head of the project manager and stakeholders, and tell the story from alternating narrators. Each episode could focus on a specific phase of the project or milestone, with the end of the show being the success (or failure) in reaching the milestone.

I think a project manager with a lot of experience under his/her belt, and who is a good storyteller could pull off this type of show rather well.

Josh Nankivel

http://www.PMStudent.com

Please leave comments about this post!

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!

Cheers!

Josh Nankivel

Please leave comments about this post!

Published Jan 13, 2007

It’s amazing how many wonderful people there are out there. I’ve reached out to several people who have all been so willing to mentor and help out a newbie like me. I’d like to give a shout out and thanks to the following, and keep the list updated so I always remember the great people that shouldn’t be taken for granted.

Tamara, Mazaryk, Draven, Ryker – My Family
-for putting up with all of my activities (work, school, reading, blogging) that take time away from them. I couldn’t do any of this without their support.

Brian Bernhard, P.E. – Professor
-for being my favorite project management professor and turning me on to Critical Chain project management; for sharing his wisdom, enthusiasm, encouragement and teaching in a way that encourages independent thought and innovation

Cornelius Fichtner, PMP – The PM Podcast, The PM Prepcast
-for giving many helpful suggestions and mentoring me regarding project management and blogging, and producing one of my two favorite podcasts

Dina Henry Scott, PMP – Controlling Chaos
-for being ever helpful with encouragement and info, and producing one of my two favorite podcasts

Jack Vinson, Ph.D. – Knowledge Jolt, Inc., Knowledge Jolt with Jack
-for fielding my Critical Chain questions and directing me to answers, and helping me with getting the word out about my blog

Larry Leach, PMP – Advanced Projects Inc.
-for his contributions to the Critical Chain Yahoo group, and giving me permission to post his NASA presentation on CCPM and EVM

Michael R. Wood – The Helix Factor
-for introducing me to “The Helix Factor” and his other books, and his valuable contributions to the Gantthead.com community