Why do we need a critical path? We don’t!


I just facilitated a map day for another project at my company. The project manager who requested my help insisted that he needed to collect start dates and durations for each deliverable so that he could build a critical path. By the way, duration for a deliverable is an oxymoron: a deliverable doesn’t have duration. It is something that is built out of numerous tasks. The tasks that build the deliverable have durations. Commitment-based project management, which uses map days, relies on deliverables and individuals committing to deliver them by a certain date. It does not rely on task management.


That little technicality (deliverables don’ have duration) apart, there’s a bigger issue. This map day was for a software development project. In my experience building a critical path for a project to any level of detail is an exercise in futility. Don’t get me wrong. There is definitely a “critical path”. The problem is figuring out what it is in time to do anything about it. By the time you do, it’s changed!


Why is that? Well, software development is of an exploratory nature, not a deterministic nature. In many cases, what really needs to be done is not known until the effort starts and someone looks into it. Either that or spend an enormous amount of time analyzing and designing everything and run the risk that by the time you are ready the business has changed and no one needs what you build. Also, and sometimes more important, how long something will take will depend on the individual doing it. Studies have shown that some developers can be 10 times (yes, that’s 10 times not 10%) more productive than other developers. So that fancy estimate done up front can be thrown out the window.


Every software development project is a custom project. While the tools and techniques are reused, the work to be done is customized. There’s no need to have the same deliverable built multiple times. Just copy it! This means that not two deliverables and their supporting tasks are the same. You can approximate using prior experience, experts, etc. but those estimates may be way off the mark. One of my early assignments as a consultant was to build an inventory report in COBOL (yes, I’m a dinosaur). The manager estimated a whole week for me to do it. I did it in ½ a day! How! I used the COBOL Report Writer utility, something the manager was unaware of. Similarly, many other developers get creative in their work to move on to other work.


Finally, in most software development projects, the project manager knows the least about technology, tools, and methods. There is no way she could know as much. Her job is to plan and run the project not to spend time improving her coding skills.


The same is not true of deterministic projects, such as construction. It is well known how long it will take to pour concrete for a foundation and how long it will take to dry. And if you need two foundations, you need to do it twice. It is also well know what it will take to build a house and the order of steps. Construction projects are well defined. In these cases, building a critical path makes more sense (even then, construction projects are many times late, but that’s another story).


Commitment-based Project Management relies on the individuals doing the work to make the commitments as to when they will be done. They use their experience and expertise to commit to a date that is more reliable than any estimate done in more traditional ways.


The job of the project manager is to monitor the completion of these deliverables on a regular basis and making sure that whenever there’s a delay, the impact is understood and corrections made to bring the effort under control.


Different than the traditional PM approach? You bet. Practical? Yes. Effective? Most definitely. Give it a try. Contact us if you would like assistance. For further information, refer to Timm Esque’s No Surprises Project Management.


Project Manager or Project Leader?

leader-1.jpgI’m starting to see a few discussions about the role of leadership in project manager. For example, see Cinda Voegli’s latest post. But this seems to be more the exception than the rule. Most of the commentary on PM revolves around the management aspects of the job.


As a PM who side-tracked into leadership development for about three years plus with lots of training at West Point and work with Scouts, I see leadership as a major force multiplier for any endeavor. Why is that?


A leader does many things but two key ones are communicating the vision and empowering the team to carry it out. In other words, “here’s what we have to do and I trust you to do it. Just let me know when you are done, if you need my help, or if you are having trouble.” This approach is very different from traditional project management, where the PM constantly monitors all of the tasks and their status.


Can it work all the time? No, but neither does the traditional PM approach. We need to balance our approach based on the task to be carried out and the readiness of the follower. See Blanchard’s Situational Leadership II on how to apply it. Most followers are much more mature and ready to carry out an activity than we traditionally give them credit for. Give it a try!


By empowering the team and letting them know the objective the project leader gets off the middle of the road (a “roadblock”!) and lets the team perform. This is what I mean by a force multiplier!

What makes CBPM work?


CBPM (Commitment-Based Project Management) works because it empowers the team members. It allows them to commit to a date they can believe on not one the project manager made up.

This is the most important reason why it works, but there are other supporting reasons:

  1. The plan is put together by the team, not by the PM or upper management.
  2. The interdependencies become highly visible to everyone during the plan development process.
  3. CBPM focuses on deliverables, not on tasks. The customer doesn’t care about all of the work team members have to do to deliver an item. S/he only cares about the deliverables. In a similar fashion, team members only care about deliverables they need to be able to do their work, not all the other work that other team members have to do.
  4. A deliverable is done or not done. None of this “80% done” (which means that 80% of the effort remains, following the 80-20 rule). No grayness here. If there’s disagreement, the “customer” of the deliverable has the final word.
  5. Since the “customer” of a deliverable has the final say, this approach encourages the “supplier” of the deliverable to know what the “customers” want by communicating with them.
  6. It’s very clear who owns (the “supplier”) what deliverable in the matrix.
  7. It’s very clear who needs the deliverables (the “customers”).
  8. Knowing who owns it and who needs it improves communications. The PM is not the keeper of the deliverable status. The suppliers and customers need to talk to each other.
  9. Status is visible in the deliverables matrix. It’s on time, late, or done. Red indicates late and no one likes their items being late.
  10. The PAC (Performance Against Commitments) chart clearly indicates how well the team is doing.

What’s your experience with CBPM? Let us know.