Agile and CBPM

The question comes up: is CBPM Agile?

The answer is a definite yes. It follows the directions of the Agile Manifesto. It values rolling plans over crafted plans. It is based on regular interactions with project team members and stakeholders. It’s focus is on delivering (“working software” if it’s a software project).

It does not require a cycle such as Scrum, though. In that sense, it’s closer to Kanban, another agile method.

Key points of CBPM:
1. Develop the plan together
2. Make it a rolling plan. In other words, don’t over plan as things may change. Plan just enough to move forward, inspect results, adjust, and lengthen plan.
3. The persons doing the work are the only ones who can commit to a deliverable date.
4. The recipient or customer of the work is the one who says whether it meets expectations. In other words, agree up front on the expectations.
5. CBPM is agnostic with respect to product development methodology. In other words, it can be used for software, hardware, construction, medical devices, etc. Domain-agnostic! Much harder in software-based agile methods.

Why Does CBPM Work?

I continue to apply CBPM in my current work while at the same time using Scrum for our software delivery. CBPM addresses those situations that are not as easy to adapt to an iterative approach.

It continues to amaze me how effective CBPM is at getting projects planned and to successful completion. One of my current projects has over 370 deliverables, not including the user stories for rewriting the application, which are being managed through Scrum. Yet the project is doing extremely well and is on schedule.

So, once again, I wonder why CBPM and other Agile methods work? A few things come to mine:

  1. CBPM and Agile methods are not deterministic but adaptive. That is, we as planners and team members, know that whatever plan we make will change. With that in mind we only plan enough to get us going and to more or less know how long it’ll take us to get there. We re-plan on a regular basis to adapt to changing conditions. By not planning in detail we avoid waste (lean concept) in planning for items that will change.
  2. We use the entire team to plan the effort. There’s no “mind behind the curtain” approach to doing planning. In this way we get many minds looking into the problem, identifying things that otherwise would have not been identified until much later. Also, we leverage the expertise of those who are going to do the work.
  3. We focus on what’s important: delivering a product to a customer. Task analysis are optional and typically up to the individual doing the work. While Scrum encourages team to decompose tasks and assign hours to them, tracking the work that remains, this is not a necessary activity. In CBPM there’s no focus at all in effort as the owner of the item is responsible for figuring out what needs to happen and getting it done by the committed date.
  4. Transparency: in CBPM and other Agile methods it is clear who owns an item and where it is. There’s no hiding behind complex Gantt charts. Ownership is clear. Status is clear.
  5. The PM is no longer the center of activity. In CBPM owners and users of deliverables need to talk to each other. In Agile the entire team is responsible for the delivery of a successful product. Reporting and accountability are where they should be.
  6. There’s a clear definition of what “done” means. In CBPM the owner and the user of a deliverable need to agree on what being done means. In Scrum every team has one or more definitions of done (user story, iteration/sprint, release, project). BTW, 99% done is not done!

There are probably numerous other reasons. Add yours!

BTW, both a one-day CBPM workshop and a two-day Scrum/Agile Project Management workshop have been scheduled for July in the Research Triangle Park area of North Carolina. Come join us if you want to learn more about these approaches.

CBPM — Going Strong

It’s been a while since I last blogged here so wanted to bring you up to date on what’s been going on.

Last week I had the pleasure to co-present with Timm Esque at NC PMI’s Annual Event. We had over 140 people present, with lots of interest. Our theme was “Agile is not just for software projects” and there was lots of interest with a number of follow-on requests for the Excel tool (let me know if you would like the latest version).

In June I started working for a local company as their Agile evangelist. While they are fully into Scrum, I will be working with their infrastructure team to use CBPM in their projects. Scrum is a hard fit for non-software projects.

Also in June I presented my one-day workshop at PMI Silicon Valley. I’m currently tentatively scheduled to teach this workshop in January with NC PMI. Timm and his business partner are teaching a workshop in November. While not published yet, we are doing a survey and the first 30 respondents will get a free copy of Timm’s No Surprises Project Management book.

How are you doing with CBPM? Let us know.

Where’s Project Management Going? Musings

A friend sent me a note today asking for a few minutes to talk about the future of project management. We are scheduling the time to talk, but his message and some of the insights he provided got me thinking.

He indicated that Gartner is seeing a leveling off of demand for project managers and an increase in demand for program managers. Why? Well, I think the bloom is off the PMP (Project Management Professional) rose. Too many projects continue to struggle if not outright fail even with PMPs at the helm. The PgMP (Program Management Professional) rose is just budding (New and Improved!) and I guess people feel that program management is what is needed to make projects successful. But, is that the case?

Program Management, as it is currently approached, continues to rely on predictive and prescriptive planning and lots of control, the approaches that have not been so successful in the past. As all of us with experience in project and program management know that no project survives first encounter with reality to borrow a phase from the military (Patton or Eisenhower? Actually, a Google search provides lots of other sources, including some older than these two outstanding generals, so let’s leave it at that.)

Not only is an encounter with reality detrimental to a project plan, but there are those agents (people!) who many times don’t follow the prescribed plan! So, since PMPs are not successful, let’s go with PgMPs that have a much harder job to do (as per PMI, a program has two or more projects and possibly some operations that managed together provide more benefit than managed independently). Do we think they’ll be successful? Personally, I do not.

Those of you familiar with my writings know that I prefer adaptive, flexible, Agile plans (Scrum and other Agile methodologies for software, CBPM for non-software as well as software projects where more “traditional” Agile approaches are not possible) to prescriptive, predictive plans. You also know that I put a lot of value on leadership. Even though Scrum teams are supposed to be self-leading, a leader is still key to provide the space necessary for them to be successful, whether it is a ScrumMaster or upper management.

In my view, project leadership is what is needed and what will start taking a much more significant role. This may not be good news for those who rely on the tools of project management but it is what is necessary to be successful.  But remember, soft skills are very hard to acquire and use successfully!

More CBPM & Agile #2


I keep digging into other Agile approaches and comparing them with CBPM. Recently I attended a two-day CSM (Certified ScrumMaster) workshop, took the test and now have my CSM designation. There seems to be more and more recognition about this designation, similar to where the PMP was a few years ago. Having that designation has led to some new contacts.

But how does it compare with CBPM? Scrum, like CBPM, emphasizes the importance of the team, the need for frequent deliverables, and the constant monitoring (by everyone in the team) on progress and the identification of challenges and how the team can help overcome them. Scrum emphasizes iterations of 2-4 weeks (typically). CBPM, with its constant review of progress, could be viewed as either iteration-less or having weekly iterations. Either way works. While Scrum plans for each iteration CBPM plans out through the commitment horizon, modifying as appropriate.

A key difference in origin: most Agile approaches came out of software development. CBPM came out of semiconductor design. As such it is able to more easily be used with non-software projects than most Agile approaches. Not to say you cannot use Scrum with non-software projects, but the connection to software is very tight and I haven’t seen much documentation on how to use it with non-software.

I continue researching some of these approaches as some of the concepts may be of value to CBPM practitioners. Stay tuned!

BTW, a CBPM session has been scheduled for June 19th in Santa Clara, CA. Another one will be held either on June 18th or June 21st in San Francisco.

Mathematical Explanation of why CBPM (and Agile) works

Just got from Amazon SDLC 3.0: Beyond a Tacit Understanding of Agile by Mark Kennaley. I have seen it mentioned in one of the Agile emails I get on a regular basis and sounded interesting: where do we go from current Agile?

As readers know, CBPM (Commitment-Based Project Management) is also an Agile framework that can help team deliver not only software but also hardware and other types of projects (it’s been used in semiconductor development, factory design, rocket design, radiation dosimeter development among other efforts).

So, I started the book thinking I was going to get a lot of words, some nice pictures, etc. Then I got to chapter 3 and I thought I was back at West Point in my EE3xx (can’t recall the number) Control Systems class! Here it was, including Laplace and Fourier transforms, stuff that I once knew about but could not remember much of!

Well, it turns out that while software development projects (the book is focused on Agile methods that are used for software development. However, the findings apply to CBPM which also does hardware as mentioned above) are chaotic in nature, they are still predictable, controllable, and can be modeled.

The model uses a proportional control (resources), an integral control (summation of past errors — test of deliverable), and a derivative control (how fast an error is changing).

Adding too many resources to a project (proportional control) to catch up make the project later (remember Frederick Brooks and The Mythical Man-Month? If no, time to read it!). It also leads to out of control situations as resources try to “help”, making things worse. Not providing resources doesn’t let the project reach it’s result.

Assessing how well the product meets requirements is the integral control. With CBPM checking weekly (derivative control), the error added in one week is minimized, controlling how far out of spec the solution gets. Traditional project management, with its limited, late in the cycle checking, has to deal with a potentially very large error.

Little did I know that my electrical engineering course work would come back so much later to be helpful! If you are interested in why CBPM (and Agile) works, take a look. It may give you ammunition next time your boss wonders why you are checking results so often.

Besides this chapter, there’s a lot of other good “stuff” in the book. So take a look.

Do you need a map day if you have a WBS or SOW?

This thought came up recently when one of my clients brought me in to do a map day. They already had a very detailed SOW (statement of work) that they had provided to the client. The SOW was almost a Work Breakdown Structure. How would this work?

In many of the map days I’ve been in, the teams have a broad idea of what they are supposed to build but not a detailed understanding of it. So we build the WBS/SOW on the fly.

In this case, we already had the SOW. This provided us with the opportunity to do a tremendous amount of pre-work. I took the SOW, populated the deliverables matrix with it, came up with abbreviations and pre-printed the Post Its with the information. What I lacked was owners and users and, in most cases, any kind of dates.

Using these pre-printed Post Its, I led the discussion. We focused on the first year to make sure we could meet the commitment for the first year. Lo and behold, we were done in about 1/2 of the time that it usually takes for a map day! In this case I would call it a map 1/2 day! We did find some items in the SOW that were not deliverables; we found a few things that were missing, but not much.

The one question was handling the higher levels of the SOW. My first approach was not to plot them but then I realized that people need the grouping to get a better picture of how things fit together and their timing. We needed to watch out for putting dates on higher levels that were not supported by the lower levels but this became obvious.

Once we had this information, I updated the spreadsheet and immediately had a tracking tool. Because of contract requirements, I exported the matrix to MS Project.

So, next time you have a map day, check to see if there’s a WBS or a SOW available. It will save a lot of time and your team will appreciate it. But to answer the title’s question, you do need a map day. Maybe a 1/2 if you are lucky!

Project Management presentation to OR students

Yesterday I had the honor of speaking at a graduate-level class of Prof. Salah E. Elmaghraby at NC State University. Most of the students were mathematicians or engineers by training. All of them are in Operations Research and had recently discussed PERT/CPM approaches to project management and how to reduce uncertainty.

Prof. Elmaghraby asked me to talk to his class as a practitioner of project management and to comment on my experience as compared to the theoretical approaches that most students are exposed to.

After discussing my career, I quickly reviewed Commitment-Based Project Management (CBPM), an approach I’ve written about here before. CBPM relies on the team members making commitments to deliver “deliverables” (actual items) to each other and eventually to the customer on the date they commit to and to the level of functionality agreed-to with their “customer”. The project manager enables these commitments and facilitates the planning and tracking of them but stays away from the details (i.e., tasks). In addition, the PM encourages owners and customers to talk to each other rather than rely on the PM to play interference.

Prof. Elmaghraby found the approach interesting and refreshing as it acknowledges that there’s uncertainty and deals with it by planning just enough to move forward and committing to near term items while estimating when the overall effort will be concluded (but not a commitment).

I found the opportunity to speak with these graduate students very valuable and beneficial by having to explain a different approach to sharp students.

There’s definitely more to project management than the standard approach and much more research on effective methods is needed. I was glad to make this connection and look forward to future discussions with Prof. Elmaghraby and his students.

Project Management – Easier Than It Seems -> Focus on Results!

project-acceleration.jpgMany project managers make life difficult for themselves by focusing on the PM process rather than the PM results. They worry about documents, forms, Gantt charts, sign offs, etc. While all of these are important, many (probably all) customers of a project care a lot more about results than about the process. As long as the team performs in a legal and ethical manner, and now in the world of SOX with enough documentation to ensure adequate oversight, they don’t care about the process.

This is my experience in numerous projects, large and small. For the Intel Inside(R) Program system, we never received any “formal” requirements nor were we given time to gather the requirements. Instead the system “needed to be built in three months!” If you know much about co-op marketing, there are numerous areas that a system needs to address, in particular due to the large financial quantities it was going to pay (50% of an ad placement could be in the hundreds of thousands of dollars in certain publications).

So, what did we do? I brought in modelers to train and guide the users (marketing, finance, and sales) on modeling the desired system.  I brought in internal audit from the beginning to make sure that we built it based on their expectations. This was a difficult endeavor as internal audit was not used to being asked to act in a consulting role at the beginning of a project rather than being “fault finders” at the end, but it worked. We implemented an Agile framework, developing three releases in parallel (pipelined), each taking three months and a production release every month.

Once we started delivering (nine months after starting, not the three months that was desired — that’s a story for another blog) and the machinery got moving, there was no need for documents, Gantt charts, or other PM devices beyond the ones we needed to manage the project. The customers were more than satisfied with the results.

There are other examples in my experience that validate this approach. How about in yours?

Thirst for Other Approaches

I spoke last Monday (9/28/09) at North Carolina PMI’s Annual Event on Commitment-Based Project Management (CBPM for short) and the impact it can have to accelerate projects. With close to 100 people in the room, there was lots of interest on this approach.

As many of you may know,  CBPM is based on work done at Intel to develop its semiconductor chips. Faced with a vicious cycle of commit-fail to meet-decommit in its projects, a different approach was taken by the chip set business (chip sets are the supporting chips for the microprocessor — without them, new microprocessors cannot go to market. Hence their criticality). Timm Esque in his Excellent No Surprises Project Management, describes the situation and how it was overcome. For those of you in LinkedIn, there’s a group called “Project Acceleration thru Commitment-Based Project Management” that you may want to join. Also, in my profile, I have posted a presentation and a file describing the approach. Go to to access.

Out of this 100 or so people who attended, 18 have requested my Excel  spreadsheet used to manage the approach (if you want a copy, send me a note at The spreadsheet makes it easy to track deliverables by highlighting who owns each deliverable, when are they committed to delivering it, who uses it, and what’s the status. A few other capabilities, such as SPI and CPI as well as a Performance Against Commitment (PAC) chart are available with it.

It was refreshing to see the amount of interest on this approach, an alternative to the more traditional project tools. Maybe you want to give it a go?

Have a great day!