That is correct. I don’t understand the conclusion that IT will assume responsibilities of other functions or that there is some unique quality of manpower. It would be helpful to tell me how your reached that conclusion.

We are explicitly taking a bottom-up approach in presenting the model. Let me make three points:

1. Most organizations can’t effectively plan top down. This is the problem with many CMMI and OPM3 implementations. Just wanting to be agile doesn’t make you agile. In top down methods, we may think we are making the strategic choices – but most the strategic options and choices exist where the rubber meets the road. With appropriate capability at the bottom, the top down planning is not productive.

2. Our model doesn’t ask for a manager to operate outside of their sphere of influence. The small teams aren’t deciding what markets to go after, what the product parameters are, how support operates, how sales operates, what message marketing is selling. These will be determined at the right level as the model moves up. As new capabilities exist, there are new bargains at the next level.

3. The entire point is to make a sustainable model that can be replicated. Sustainability occurs when the you can reliably deliver at the small team level – this is missing in the implementation of many approaches. We don’t talk about how to identify and implement the next most important capabilities. But, we don’t expect this to be implemented in a linear fashion. We expect it to be implemented in the fashion that makes sense and is adoptable within each organization.

Thanks for the feedback. This is a great discussion.

Interesting idea. However, you are approaching this with a bottom-up perspective and thus will make IT assume responsibilities of other functions. Yes, you will be able to effectively prioritize what is available, but only from the ones you have. There should be an alternate process to bring the best ideas together before you can prioritize and the software developer has only very little to contribute. I think this system maybe efficient, but not easily replicated and sustained because of the unique quality of manpower required.

Here is an Top-down approach to Business Agility:
http://www.businesschange.com/agility.htm. Please let me know your thoughts.

I have some thoughts at this point to use the heat map construct: Border is Value, Fill is Velocity, the stop light is context. Special cases (constraint, type of deficiency) will be icons.

The scale or ranking needs a bit of thought.

The output needs to be an actionable and situation specific strategy that identifies which capability to create/act on next to improve performance and/or support scale.

Dennis

A couple of suggestions on where to expand this.
1) I would suggest that you can come up with a way to quantify context, and you might even want to put it on a scale of 1 to 10, but it might also be a blend of a few factors that don’t roll up elegantly into a single score, but you could then use that to explicitly plot on the axis the different levels of value you will get with varying degrees of velocity.

2) Somewhat related to that, I wonder how much consistency there is in the relationship between Context and Value. Is the relationship linear? I highly doubt that, but it’s probably also not logarithmic.

And of course this overlays very elegantly on the business capabilities work you have talked about in the past.

That’s my $.02 on where to go next with this idea. Great stuff.

-Ric