CBPM | Project Management Leadership

More CBPM & Agile Thoughts

We had some good discussions in LinkedIn’s “Project Acceleration through Commitment-Based Project Management“group with respect to my prior blog. One individual indicated that CBPM should be viewed as another Agile framework, just like Scrum. That idea reinforced my thoughts about CBPM and the fact that it fits properly within the Agile philosophy.

CBPM focuses on getting deliverables done with as few “drag” (non-value or low-value) activities as needed. The owners determine how to deliver on their commitments, including making sure that any dependencies on other deliverables are understood and taken into account. Management oversight is minimal.

The inspect aspect of Agile is addressed via the discussions that owners and customers have on the deliverables and the final say that the customer(s) has/have on whether the deliverable is done or not done. This feature, the need for owners and customers to discuss the scope and status of deliverables, is a variation of the Agile inspect process at the end of an iteration.

Iteration-wise, CBPM is not fixated in any length of the iterations or cycles. The goal is to complete deliverables of value as quickly as possible. Due to its origins in the hardware business, there’s less emphasis in wrapping up a set of deliverables into a release or sprint, although that is very viable.

CBPM is an Agile framework that has some key capabilities (i.e., support for non-software projects) that other Agile frameworks may not. This does not mean that it is not usable in software efforts. As a matter of fact, it can easily be applied to software efforts, even to those run under the waterfall method (gnashing of teeth here! 😉

If Intel can plan and deliver some of the most complex products in the world using CBPM, almost any project can use it.

CBPM and Agile — a brief comparison

Recently I’ve become re-acquainted with Agile methodologies. I say “re-acquainted” because in the 1990s, when I was running the Intel Inside (R) Program system development we sort of fell into now what would be called Agile. We time-boxed, had rapid iterations/releases, had customers working with us at all times, provided value to our customers as fast as possible.

A friend of mine indicated that there might be an opportunity to help as an Agile coach so I dug into it, attending Agile Palooza on 8/14 in Charlotte, NC and reviewing the numerous books that I have on the subject. It struck me that there are a number of similarities and some differences between the two approaches.

Deliverables and Features

Readers familiar with CBPM (Commitment-Based Project Management) as described by Timm Esque in No Surprises Project Management and presented in various workshops, blogs, etc. know that CBPM focuses on deliverables, items of value to a user or customer, whether it is the ultimate customer or an intermediate one. Tasks that get us there are ignored as far as the overall planning and tracking is concerned. The individual is responsible for figuring out what tasks need to be executed to complete the deliverable.

Agile focuses on features, which I would classify as a synonym for a deliverable. There’s a difference, though, in that these features are for the ultimate customer. Agile seems not to address the intermediate deliverables directly. They, instead, are handled as part of the development process.

Planning

Agile does just enough planning to figure out the next release and, more specifically, the next iteration or sprint. There’s an overall vision of where the project is going and there is some longer term planning but it’s pretty fuzzy.

Similarly, CBPM focuses on detailed (at the deliverables level) planning for the next 6-8 weeks, the commitment horizon. It does look further down but the plan dates are estimates, not commitments.

Release/iteration

Agile groups features into iterations that, in turn, are grouped into releases. At any one time the software developed by an Agile team is production-worthy as of the last iteration that was completed (ideally, every day as the constant recompilation and testing of the code ensures that the code works. If it doesn’t, it has to be fixed before any additional work takes place).

CBPM does not necessarily group deliverables into releases. This is an option that the team may choose to do. However, with its focus on weekly measuring performance in terms of items completed as per the commitment, the weekly results could be viewed as a release. However, there is no logic behind this grouping so this comparison is weak.

Burn-down/up chart and PAC

Agile uses a burn-down (or burn-up chart) to track the completion of features against the plan. Similarly, CBPM tracks performance against a committed set of deliverables. While there are small differences in the details, both charts reflect the same information: how well is the team performing against the plan.

Application Areas

Agile has been applied mostly to software efforts. There have been some discussions on its application in other areas (see Jim Highsmith’s Agile Project Management for a very good discussion) but, overall, it’s application is mostly in software projects.

CBPM, on the other hand, started with hardware projects (designing Intel’s semiconductors, specifically chip sets, the chips that support the microprocessor) and has been applied to construction, manufacturing, aerospace, education, software, and other projects.

Preliminary Conclusion

There are many similarities between the two approaches and some differences. It is possible that both may benefit from each other so I’ll keep investigating to determine where best to adapt practices from one approach to the other approach.

CBPM Workshops and the Challenges of Marketing

I’ve scheduled two CBPM, one in Durham, NC on May 29 and one in Santa Clara, CA on June 12. While setting up the workshops was not easy, marketing them has been more of a challenge.

For various reasons I cannot use PMI chapters to market the sessions, at least not for now (yes, I’m working on that). So, I’ve relied on emails and social networking sites to get the word out. The jury is out as to how well these approaches will work vs. using PMI chapters. I’ve also communicated with prior attendees who may have co-workers who are interested.

I guess I’m hitting the typical challenges of most startups: you have a great idea but trying to get the word out is a challenge. Thoughts? Suggestions welcome!

Continuing updates and upcoming workshop

I’m working to schedule a “Project Acceleration through Commitment-Based Project Management” in May in the Raleigh/Durham, NC area. This class, which I’ve delivered already three times in California, has received outstanding reviews each time. The goal is to have the participants leave being able to run their projects using CBPM. More details to follow in my web site at http://www.pmlead.com.

I continue working with my client. We had to do a reset on their project due to issues outside the project that impacted their availability. Good progress is being made and resets do work when necessary. It is not necessary to run a full map day to do it. Instead, work through the deliverables matrix focusing on upcoming items and getting new commitments.

While it is not ideal to do a reset, sometimes it is the only way to bring reality into the project. Otherwise all deliverables will be late and the approach will have less of an impact — that is, being late will be the norm and the PM cannot leverage that tool to ensure progress.

Another item: just listened to a podcast on Agile project management and hear “we don’t use Gantt charts” in Agile. Sound familiar?

Let me know how it is going with your use of CBPM and what questions & suggestions you have.

Update on Commitment-Based Project Management

It’s been a while since my last blog here, although I have a few in UC Santa Cruz Extensions. But today I wanted to give a brief update on the use of Commitment-Based Project Management, CBPM for short.

In January I presented the approach to a standing-room only audience at PMI Silicon Valley. There was tremendous interest and one of the attendees brought me into his company to consult and train on the approach. I visited in February, we ran a series of map days, and came up with a challenging but doable plan. Unfortunately, attention was taken off the effort due to other priorities and four weeks later, when they asked me to come again, things were late and we had to do a reset.

What this shows is that while coming up with a good plan is a great start, we all know that you have to stay on top of the effort or things will slip, regardless of how good the method is. I’m working with them to reset the plan and get the execution back on schedule.

In the meantime, I heard from one of the PMs who worked in my project with my prior employer and he’s been able to use CBPM successfully there, although he is forced to use MS Project to capture the plan and track the project. Don’t get me wrong, while I think MS Project can be overkill, it has some great features that are needed, such as the ability to capture dependencies. My spreadsheet allows the user to enter dependencies but it’s not the best approach. Something to mull about in my spare time on how to fix.

I have added Cost Performance Index and Schedule Performance Index calculations for Earned Value Management to the spreadsheet. Let me know if you are interested in this version. I’m still investigating how to automate it even more and I’m making some progress with VBA for Excel but that’s slow going.

How are you using CBPM? Let us know!

Why do we need a critical path? We dont!

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 doesnt 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, theres 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. Dont 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, its 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, thats 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. Theres 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, Im 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 thats 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 theres 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 Esques No Surprises Project Management.

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:

The plan is put together by the team, not by the PM or upper management.
The interdependencies become highly visible to everyone during the plan development process.
CBPM focuses on deliverables, not on tasks. The customer doesnt 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.
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 theres disagreement, the customer of the deliverable has the final word.
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.
Its very clear who owns (the supplier) what deliverable in the matrix.
Its very clear who needs the deliverables (the customers).
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.
Status is visible in the deliverables matrix. Its on time, late, or done. Red indicates late and no one likes their items being late.
The PAC (Performance Against Commitments) chart clearly indicates how well the team is doing.

Whats your experience with CBPM? Let us know.