IT | Project Management Leadership

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:

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

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.

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.

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?