All Posts in Industry Commentary

|In: App Dev Methodologies|Last Updated:

Back when re-engineering was all the rage, a reported 70% of all re-engineering projects failed.

That’s in contrast to the shocking failure rate I ran across a few years later for CRM implementations, 70% of which failed.

On the other hand, the statistic tossed around for mergers and acquisitions is that 70% don’t work out.

On the other hand, the most recent numbers for large application development projects show that, in round numbers, 70% have results in the disappointing to failed completely range.2015ChaosStudy

At least, that’s the case for large application development projects executed using traditional waterfall methods, depending on how you count the “challenged” category.

And oh, by the way, just to toss in one more related statistic, even the best batters in baseball fail at bat with a failure rate of just about 70%.

What’s most remarkable is how often those who tabulate these outcomes are satisfied with the superficial statistic. 70% of re-engineering projects fail? There must be something wrong with how we’re executing re-engineering projects. 70% of CRM implementations fail? What’s wrong with how we handle these is a completely different subject.

As are the M&A, application development, and baseball at-bat percentages.

But they’re not different subjects. They are, in fact, the exact same subject. Re-engineering, customer relationship management, mergers and acquisitions, and hitting a pitched baseball are all intrinsically hard challenges.

And, except for hitting a baseball, they’re the same hard challenge. They’re all about making significant changes to large organizations.

Three more statistics: (1) Allocate half of all “challenged” projects to “successful” and half to “failed” and it turns out more than 75% of all small Agile application development projects succeed; (2) anecdotally, 100% of all requested software enhancements complete pretty much on schedule and with satisfactory results; and (3) during batting practice, most baseball players hit most of the balls pitched to them.

Okay, enough about baseball (but … Go Cubbies!).

Large-scale organizational change is complex with a lot of moving parts. It relies on the collaboration of large numbers of differently self-interested, independently opinionated, and variably competent human beings. And, like swinging a bat at a pitch, it’s aimed at an unpredictably moving target.

The solution to the high organizational change failure rate is very much like how to not get hurt when driving a car at high speed into a brick wall: Don’t do it.

The view from here: Extend Agile beyond application development, so large scale change becomes a loosely coupled collection of independently managed but generally consistent small changes, all focused on the same overall vision and strategy.

Turns out, I wrote about this quite some time ago — see “Fruitful business change,” (KJR, 5/26/2008) for a summary of what I dubbed the Agile Business Change (ABC) methodology.

I’ll provide more specifics next week.

* * *

Speaking of not providing more specifics, here’s this week’s Delta progress report:

Gil West, Delta’s COO, has been widely quoted as saying, “Monday morning a critical power control module at our Technology Command Center malfunctioned, causing a surge to the transformer and a loss of power. When this happened, critical systems and network equipment didn’t switch over to backups. Other systems did. And now we’re seeing instability in these systems.”

That’s all we have. Two weeks. Three sentences. Near-zero plausibility.

Leading to more information-free speculation, including lots of unenlightened commentary about Delta’s “aging” technology, even though this can’t have had anything to do with it. Delta’s actual hardware isn’t old and decrepit, nor is anyone suggesting the problem was a failed chip in its mainframes. Delta’s software may be old, but if it ran yesterday it will run tomorrow, unless an insufficiently tested software change is put into production today.

Nor does a loss of power cause systems to switch over to backups. It causes the UPS to kick in and keep everything running until the diesel generators fire up. Oh, and by the way, much smaller businesses than Delta are smart enough to have power supplied by two different substations, entering through two different points of presence, feeding through different transformers, so as to not have a single point of failure.

But because nobody is insisting on detailed answers from Delta, it’s doubtful we’ll ever know what really happened.

Which, in the greater scheme of things, probably doesn’t matter all that much, other than leading us to wonder how likely it is to happen again.

Comments

|In: Cognitive Enterprise|Last Updated:

OODA loops aren’t limited to competing strategies, and there’s more to an enterprise being cognitive than making use of OODA loops.

Sorry for starting in the middle. Regular readers will recall Colonel John Boyd’s OODA loop. For the rest, it stands for Observe, Orient, Decide, and Act, after which you review the results of your Action … you Observe, starting the cycle again.

OODA holds sway in time-bound competitions, where whichever side has the faster OODA loops wins, because the faster side’s actions invalidate the slower side’s observations, orientation, and decisions, forcing it to start over.

But OODA isn’t restricted to competitions, and in fact it’s a decent general-purpose model for cognition, which is why The Cognitive Enterprise — the book I co-authored with Scott Lee on this subject — uses OODA as a general-purpose way of making an enterprise more cognitive.

Time to take a step back, because OODA is a mechanism — a way for enterprises to become more cognitive. It isn’t the essence. At the heart of the concept is that the enterprise acts with intention — it’s akin to an organism that has a purpose and acts so as to achieve it.

Look at two enterprises, one industrial, the other cognitive, as a customer, from the outside in. An industrial enterprise looks like what it is — a collection of processes you as a customer have to figure out in order to do business. If the processes aren’t designed to deliver what you want to buy, you either live with the frustration or take your business elsewhere.

A cognitive enterprise, in contrast, interacts with each customer as if the interaction was a person-to-person conversation. The ability to act with intention in ways that adapt to each customer’s needs is what lets entrepreneurships survive while surrounded by much larger competitors. Cognitive enterprises figure out how to make entrepreneurship scale — not only when it comes to strategy, but throughout.

Take, for example, Amazon’s “Customers Who Bought This Item Also Bought …” and Netflix’s “Because you watched …” features. They’re excellent examples of enterprises being cognitive, right down at the level of one-on-one customer interactions. They follow the OODA model quite nicely, too — they observe what you shop for, interpret your behavior so as to infer your preferences (they orient), decide on what to offer you, and then show you the offer in a persuasive way.

Down at the level of individual customer interactions, the most successful companies right now all seem to be as cognitive as they can be.

Your challenge: Quite obviously, no business of any size can achieve cognition without a lot of information technology, some of which interacts with customers directly, the rest of which supports employees who interact with customers directly.

Is your IT department ready to provide it?

* * *

And on a completely different topic, there’s Delta.

In case you somehow missed the story, Delta had a complete systems meltdown last week, grounding its fleet and stranding thousands of travelers for days.

Delta initially blamed the problem on a power outage, leaving all of us who know anything at all about the subject scratching our heads.

You don’t get to run a data center at the Delta scale without having sophisticated power management. Decades ago, when I was directly responsible for some of this, we made sure we were getting power from two separate substations so that a single transformer failure wouldn’t affect us; this in addition to our UPS and backup generators.

And, we tested all of the above from time to time to make sure they worked — this in a relatively small, 2,500 employee corporation.

Among the many puzzling aspects of this story, two stand out.

The first is that Delta’s explanation of what happened seems to change every day. First it was a power outage. Then it was a transformer. Then it was a failed electrical component that took down the transformer that provided power to the data center. That’s the transformer, not one of the transformers, which would mean Delta’s power distribution system was built with a single point of failure.

Then, maybe, there was a fire in the data center, too.

Which brings us to the second source of puzzlement: I’ve read few complaints about Delta’s ever-changing account of these events, but lots of speculation as to what might have been the “real” problem, even though Delta’s ever-changing account of things is an observable fact while the speculation — which includes the usual Strongly Held Opinions about Why Delta Should Be Ashamed of Itself — is largely fact-free opining.

The view from here: Let’s find out why Delta should be ashamed of itself first.

Comments