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

Is it PM or Leadership that’s needed?

We need both the tools and techniques of project management and the skills, attributes, etc. of leadership. I’ve been working with one client. They have an excellent team but are not “performing” yet. This is typical of teams put together in an organization. They are still forming yet they are expected to perform. This challenge requires more leadership than project management skills as the question is how to get the team to quickly jell and move into the performing realm.

We’ve agreed that I’ll do a workshop on teamwork, one based on Patrick Lencioni’s Five Dysfunctions of a Team. This will be a great start although it won’t solve everything as the leaders need to be cognizant of their actions and expectations to support the improved team performance.

Most organizations take for granted that once a project is authorized it should be running at full speed immediately. Reality is that it takes time to figure out what to do, staff up, get the team to perform, and then get to a good situation. What are your experiences?

From “Good to Great” to Fallen

The May 25th, 2009 issue of Business Week’s cover story was about a new book by Jim Collins, author of Good to Great, on how a number of the companies that he and his team had followed in Good to Great had fallen from their high perches.

Collin’s new book, How the Might Fall, describes the stages of decline he and his team discovered:

Hubris born of success

Undisciplined Pursuit of More

Denial of Risk & Peril

Grasping for salvation

Capitulation to irrelevance or death

Very interesting reading but what does this have to do with project management? Well, as PMs we need to be cognizant of the business and understand how our efforts can help or hurt the business grow and stay alive. We should expand our reading beyond pure PM materials. I’m ordering my copy of How the Mighty Fall right now. If you haven’t read Good to Great, I recommend you do.

Its the People, Std!

Update: Read a related CIO magazine article: “Six Attributes of Successful Project Managers“.

The more work I do with projects, the more I realize that many PMs dont get it: the hardest part of project management is the soft part: the people skills. Most projects flounder not because the PM doesnt have the technical hard skills but because s/he doesnt have the soft skills.

Let me give you an example: I was asked to go help a project in which the customer was sending emails to senior VPs as to how messed up our organization was. He told his team to ignore us whenever possible. And it got worst from there.

So, I came in and started talking to the PM and the customer to get a sense of what was going on. Was the team not delivering? Well, they were, sort of, but promises had been made and not kept and the customer had not been informed before hand! Yes, you can argue with me, they didnt follow the communications plan (hard skill). But you should not have to have a communications plan that articulates each and every small activity to be successful. Use your common sense! If you are going to miss the deadline, dont wait until it happens. Tell the customer right away!

Once we started improving the communications, the storm calmed and things improved dramatically.

So, I was on the phone with David Schmaltz, author of The Blind Men and the Elephant yesterday discussing this situation. His experience, just like mine, is that most project failures are due to people issues. PMs focus on getting the plan developed (WBS, activity definition, activity sequencing, and on and on) while not worrying about the setting up a vision; making sure that the team knows where they are going, why it is important, and what is expected of them. Whats up?

My belief is that the soft skills are very hard and most people have trouble with them because they are hard to articulate. Yet weve been doing them all of our lives! As little kids we knew if our mother was upset without saying a word! Why cant we sense the same from our customers?

David is pulling together a group of similarly minded people. Hes started with a group in Facebook called ProjectCommunity (no space in between Project and Community) and has a site at http://www.projectcommunity.com. Come by and join in the discussion!

As a bonus, my two basic rules of PM:

Under promise and over deliver
If you are going to slip, slip once and slip big.

Go out and have great projects!

Jose Solera, MBA, PMP

Project Manager or Project Leader?

Im starting to see a few discussions about the role of leadership in project manager. For example, see Cinda Voeglis 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, heres 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 Blanchards 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!

Successful CBPM Workshop!

Last Saturday, May 17^th, I held a day-long Commitment-Based Project Management (CBPM) workshop in Mountain View at Symantecs facilities (thanks, Symantec!) We had 38 people in attendance and it was obvious the energy in the room as we discussed and role-played how to conduct a map day. At one point we were running almost two hours late (but we recovered)!

It is obvious to me that theres a need, a desire for an easier and more effective way to manage projects. Life as a PM is challenging enough without adding all of the details and paperwork that sometimes we think we have to deal with (or someone insists we have to deal with it!)

CBPM handles a lot of the details by putting the responsibility where it belongs: with the people doing the work. By empowering the team and trusting them but having the necessary verification tools (i.e., deliverables matrix and PAC) a PM can easily monitor a project and be successful without being overwhelmed and overloaded with details.

This was the third workshop Ive run (the two prior ones were at Symantec). Im working on scheduling future ones. PMI Silicon Valley is already discussing when we should have the next one. Cornell Universitys Johnson Graduate School of Management is also looking into their calendar to determine when we can run it. PMI Phoenix, San Francisco, and North Carolina have been approached. Do you want host a workshop in your company or group? Just let us know!

Jose Solera, MBA, PMP

Made to Stick Secrets of getting your message across

I just finished reading Made to Stick: Why Some Ideas Survive and Others Die by Chip Heath and Dan Heath. If you want to carry your message across; if you want to sell your story; if you want people to follow you, this book is for you.

Why do some stories stick (e.g., urban legends such as the razor blades in the Halloween candy; Its the economy, stupid) while others die? This book tells you how to do it.

Next time you are faced with selling a concept, like when Stephen Denning was demoted and put in charge of Knowledge Management, something no one wanted to hear about yet he not only sold the concept but made it one of the top priorities at the World Bank, refer to this book. It is that important!

Jose Solera, MBA, PMP

Leadership … a few comments

My last role at Intel was leading a leadership development effort for a large group in the IT organization. I learned a lot about leadership, its development, and what it takes for such a development effort to succeed in an organization (not easy). As I surfed our blog site, I looked for leadership articles and was not able to find any that address a few key concepts that I think are critical for all leaders and, in our case, project managers. (This blog was first published on 28 March 2008 at http://svprojectmanagement.com/). Continue reading Leadership … a few comments