Emerging Discipline of Disruption Management

Thursday, April 16, 2009 |

Interesting line of thought from Clayton M. Christensen from MIT/Sloan. Not sure I agree with Clayton's specific take on Wagoner. Also not sure whether "disruption" as an attack vector described in this article is somehow related to "disruption" as an attack vector that has been observed thanks to the ever-shrinking slack in the business cycle. The Big 3 were certainly profitable while the SUV and light truck market was booming, but were not able to cope with the sudden (or disruptive) retreat of that market thanks to oil price spikes of 2008 and credit crunch that is still with us.

Another discussion topic I think would be worthwhile to get comments on is whether service orientation of business and technology capabilities can really help deflect a disruptive attack - after all, just about every deck selling SOA I've ever seen has identified this as an intangible benefit.

Why incomplete discovery?

Thursday, April 9, 2009 |

So why would I attribute the top ten list from yesterday to incomplete discovery?

Every program (or product, or service, for that matter) has three stages of life - discovery, implementation, and operation. In reality, most of what people focus on when it comes to program/project management is the implementation stage. Maybe a bit of operations focus tossed in at the end to mollify those who will be running the results of the implementations (at least those that are not completely canceled!) It's not a surprising reality - people will do what they are incented to do.

Discovery is the stage that is usually left incomplete - or completely left out - in the rush to get to the finish line. Very few people like creating documentation, and even less like reading it. Even fewer can correlate the various bits of incomplete data into a cohesive view of the environment. And time lines are generally not built with discovery issues in mind.

Which brings me full circle to the idea of understanding the environment. First rule of information management can be summarized as "garbage in, garbage out". Is it really a surprise that when efforts base their implementations on data that is incomplete or assumptions that are no longer relevant, they fail at a prodigious rate? Invisible requirements? Scope Creep? Budget and resource challenges? Unrealistic time lines? Of course those lead to compromises in quality and features - even as those features are delivered late. So the sponsors get sub-quality features that don't necessarily match up to the features they need to deliver on their business promises, and they don't get those features in a timely manner. No wonder sponsors disappear!

OK, enough of the soap box. There are methods to quickly digest all of the environmental variables and integrate them into a cohesive road map. If only people would use them :)

It looks like the issue of incomplete discovery is quite pernicious!

Wednesday, April 8, 2009 |

Not sure if everyone can follow this link, so I'll paste the post contents from www.mutoperformancegroup.com. It seems to me that just about every item in the top 10 can be attributed to incomplete discovery - or lack of discovery work. What are your thoughts?

Reprinted from LinkedIn's Enterprise Architecture Network:

2009 Results of the Top 10 Obstacles to Project Success Survey

Here are the new rankings from the "Top 10 Obstacles to Project Success" survey. We received appreciation for our ongoing efforts, and confirmation from participants that our list captured the essence of the obstacles to project success faced by Project Managers, Team Leaders, Program Managers, and Senior Management. Here are the results listed in order of frequency;

#1: SCOPE CREEP (Same as last year!)
#2: Challenging Schedule (up from #8 last year!)
#3: Resource Challenge
#4: Minimal or Non-Existent Testing
#5: Tardy Delivery of Project Tasks
#6: Delegated Responsibility Unrelated to Authority
#7: Finance Challenge
#8: Invisible Requirements (down from #2 last year!)
#9: A Skill Set Challenged Team
#10: The Disappearing Sponsor (down from #3 last year!)

We've had some interesting changes between the 2008 and 2009 surveys. Obstacles such as the Challenging Schedule, Invisible Requirements, and most notably, The Disappearing Sponsor have moved in their ranking.
What do you think causes these obstacles? What are some potential solutions?