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

## When great teammates get together…

Tonight I had the privilege of having dinner and catching up with a co-worker from Intel days: Rich Poliak. Rich spent numerous years at Intel in manufacturing and IT, among other roles, before switching careers to launch a restaurant. He now wants to share his quality expertise (see his site at http://solutionelements.com/).

I knew Rich mostly during my time running Intel’s Y2K program. While it ended going out with a wimper, Y2K could have gone out with a bang. From the beginning we knew our highly automated factories would not transition smoothly. We had equipment that even after the program rolled out was coming in with issues that would have stopped our factories.

As the technical assistant (TA) for Mike Splinter, then head of the manufacturing group at Intel and now CEO of Applied Materials, Rich was instrumental in making sure that the factories fixed all of their issues. After Y2K Rich moved on to data quality and other roles at Intel.

Having dinner with Rich makes me want to run a project with Rich and others who I’ve worked with throughout the years who I know can do an excellent job. Do you have such a team? I do and it’s not just Rich but a number of other people. Hope we have the opportunity to work in a project together again but, in the meantime, if you need help with quality efforts, let Rich know. He’ll do an outstanding job for you.

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

Many 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 http://www.linkedin.com/in/josesolera 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 jose.solera@pmlead.com). 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!

## 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 the IT Industry going the way of the Electric Industry?

Recently I finished reading The Big Switch: Rewiring the World, From Edison to Google by Nicholas Carr (famous or infamous author, as you see it, of “IT Does Not Matter” published in the Harvard Business Review in May 2003). In it, Carr continues his argument on the changes happening the in the IT world. According to Carr, most companies will secure their IT capabilities from big suppliers off the net (what’s known as ‘cloud computing’). He uses the electric industry of the late 1800 and early 1900 as an analogy of what will happen to IT.

In those days, most companies had their own power plants. There were no central power plants available to provide the necessary power and, even if there had been, there were no effective distribution networks. As the technology advanced, centralized power plants with broad networks became the norm. He argues that IT is going through a similar change, a case he also expanded on in Does IT Matter? Information Technology and the Corrosion of Competitive Strategy published in 2004. But is that the case? It cannot be argued that many of companies’ IT needs can be provided by third-party companies, such as salesforce.com.

While the jury is out, the electric industry is facing its own challenges. As organizations look to become more green and have the energy they need, big centralized power stations with large distribution networks may not be the best solution. Doubt it? Take a look at Fast Company‘s July issue and its article “Why the Microgrid Could be the Answer to the Energy Crisis“. It makes a good argument as to why having many of us considering putting up our own solar cells and windmills may be the way to go.

What does this mean to IT? Well, organizations will need IT, whether it comes from the wall provided by some big central provider(s) or its own to implement specific processes not supported by others.

And to PMs? Well, we still have to develop and deliver projects on time, on budget, and with the agreed-to functionality. We may just have to do it using some other organization than our own IT.

Thoughts?