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.

PMing is simple but not easy

The more I manage projects the more I realize that while it is simple it is not necessarily easy. Yes, I know. If you’ve been managing projects you know this already. But allow me to share my thoughts.

What’s the objective of project management? To deliver the results of the project (product, service, etc.) to a satisfied customer. Yes, there are other constraints (time, budget, scope…the golden triangle). But sometimes we focus too much on these three at the expense of the ultimate goal: a satisfied customer. If we focus on that goal, the rest is simple.

But it is not easy. Other items compete for our attention: “do you have a Gantt chart? Is it up to date?” “Where are we in the project?” “Will it be complete on time?” “John Doe thinks he is a stakeholder. How do we handle him?” “Your resources are being pulled into other higher priority projects in spite of what was promised.”

This is why it is not easy. So what do we do?

We focus on the goal of satisfying our customer and respond to all other challenges by framing them around this goal: how do we respond to this challenge in such a way that gets us closer to the goal? Thinking this way may lead us to what some think are counter-intuitive responses such as when some things slip. If we only react to the slip without assessing the impact to the goal we may overreact. I have faced this situation and by asking this exact question have realized that it was not a crisis.

What are your thoughts?

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.

The Lazy Project Manager Meets Lean

lazydalpha.gifJust finished reading The Lazy Project Manager and the Project from Hell and I’m planning on reading the predecessor, The Lazy Project Manager. It stroke me that a Lazy PM is a lean PM. Here’s why.

Throughout my career I’ve realized that maximizing the amount of work not done or, in other words, not doing what is not absolutely necessary is essential to keep my sanity and deliver on our projects commitments, was key. I called myself “lazy”. So, when I saw these books I thought I had found corroboration to what I do. And, yes, that is the case. But there’s another, more PC-way  should we say, way of looking at it: it’s call Lean which is the hot buzzword. Let’s see what lean says with respect to work: eliminate waste. That to me sounds like the same thing. So I guess I’ve always been a Lean PM (even if my weight is less than ‘lean’) even when I called myself lazy.

Time to adjust my labels!

BTW, the first book is/was free at Amazon. It has some good info but it’s also a marketing tool for their Lazy PM and the Project from Hell workshop they sell. Forewarned.

Updates from the Agile PM Front

For the last year I’ve been driving Agile adoption and use at a small but impactful organization. We sell services and data access for the railroad business in North America and, while in IT, 90%+ of our work is product related.

Early this year I initiated three major efforts: a mainframe migration — about 40 applications to be migrated over four years to a Java/Oracle environment, a Master Data Management (MDM) consolidation of our customer data, and a replacement and reengineering of our Single Sign On (SSO) services. This is in addition to still driving Agile, UX, and a brand-new services strategy that is being defined.

For the mainframe migration project we are using pure Scrum as it fits very well with the effort to be undertaken. The existing application is reviewed with the Subject Matter Expert (SME), functionality assessed; some functionality eliminated; rearchitecture decisions reached; and work defined through user stories.

The SSO and MDM effforts though are not pure software development. SSO entails acquiring a new engine, assessing how to replace the existing one, then taking the steps to deliver this functionality. User Stories (Scrum) are a bit cumbersome for this approach.

The MDM effort includes data modeling and data loading through ETL (Extract, Transform, Load) processes, the definition of data governance and quality processes, and the development of a simple application to view the data. Besides the application development (we are using Scrum for it) the other parts are cumbersome through user stories and Scrum.

Instead of Scrum we are using a modified and simplified CBPM processes. Rather than a full day planning process (Map Day) we undertook one to two hour sessions to define what we knew and got the ball rolling. As the teams are small the users for each deliverable were not defined. While modified CBPM is still very successful. We just implemented our new SSO engine and protected the first migrated application this week. For MDM we have a preliminary loading of the data and a first version of the application. The challenge with MDM has been understanding the data and how it has been loaded into the existing source systems, something that would have taken a long time through traditional data analysis processes

So, don’t be afraid to mix and match approaches and even modify them. Keep to the spirit of Agile.

Driving Agile into an Organization

Agile has exploded into organizations doing software development. Scrum, XP, and other methods (and combinations) are used by many organizations. Non-software organizations use approaches such as CBPM (see my other posts).

Recently I joined an organization that had brought in Agile (mostly Scrum) a couple of years back. While most projects were using this approach, there was no energy behind. In what is a common approach, they had launched it and left it to its own devices. Still, teams were successful with higher quality products and more satisfied customers. But management and the people in the organization thought there was more to be done.

Enter Jose. I started by assessing, along with a small team, of the situation. We ran an internal survey to confirm our findings. The #1 finding was the need for training. But how to bring the training in with limited funds? And what else to do?

We decided to deliver short (1-2 hour) sessions on specific Agile concepts (writing user stories, using Rally, our software development management tool, estimating and planning, etc) as well as doing some longer sessions (I had done a day-long session outside so brought that one in).

Attendance is very high, with no empty chairs.  We’ve scheduled an external vendor for a two-day workshop for product owners. And we’ll be launching a coaching program in the near term.

Response has been very positive and we look forward to improved results.

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.

Methodology wars … not!

Recently I reengaged with Agile methodologies, attending a ScrumMaster workshop conducted by LitheSpeed in DC (highly recommended if you are looking for a ScrumMaster workshop). Took the test and passed it.

I have been reading a lot about Agile, so nothing really new in the workshop. But I did get a sense that there are divisions among the various Agile practitioners (some of you may go “duh!”) There are the XP, Scrum, RUP, Lean practitioners that decry that their way is the only way. They all agree that waterfall doesn’t work (I too, although I’ve made it work by layering CBPM on top of it, making it somewhat Agile!)

Mark Kennaley’s SDLC 3.0: Beyond a Tacit Understanding of Agile does a very good job of tying the various Agile methodologies together, showing how to leverage the various strengths. To me, this is the way to go. In my experience, it is rare that one set of tools/methods can address any one situation. I pick and use what makes sense at the time, changing in mid-stream if necessary. Mr. Kennaley’s approach is refreshing and I’m sure there are many other Agile practitioners who feel the same way.

SDLC 3.0 also points the way forward from here. So, if you are interested in Agile and how they can work together, you may want to pick up Kennaley’s book.