All Posts in App Dev Methodologies

|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: App Dev Methodologies|Last Updated:

Are ITIL change management and organizational change management two processes or one (“Battle of the change methodologies,” Keep the Joint Running, 7/25/2016)?

Answer: No, they’re not. First of all, they aren’t processes. They’re disciplines — practices — or they’d better be, because making them processes courts disaster.

You already know why that is, but just in case: If you structure these as processes and implement them as processes, everyone involved will, in just a few short months, forget the point of it all and treat the process steps as checklist items instead. You’ll have added bureaucracy instead of achieving the “process” goals.

Second of all, between them ITIL CM and OCM are only a third of what’s needed to successfully change how an organization gets things done.

To reliably achieve intentional change, organizations have to achieve mastery … or at least competence … in six change disciplines: (1) business design; (2) application development/integration; (3) IT change management; (4) organizational change preparation; (5) change orchestration; and (6) project management.

One at a time:

  • Business design: This is where Lean, Six Sigma, Theory of Constraints, Next Best Action, and Service-Oriented Modeling live, not that this list enumerates your only alternatives. One way or another you have to be able to describe how the future is supposed to be different from the present in a way that makes clear what has to change.
  • Application development/integration: Well this is clear, isn’t it? Most business change calls for new or changed application software. What’s less clear is that how a business goes about choosing, installing, and configuring commercial software isn’t just like how it goes about designing and coding in-house-developed applications. The challenges are quite different. In this day and age, businesses have to master both.
  • IT change management: This is ITIL’s change management or something equivalent — how IT operations goes about taking application software changes provided by application teams and puts them into production without blowing up the currently-stable production environment and also without annoying everyone to death.
  • Organizational change preparation: Until very recently (until, that is, I wrote last week’s KJR) I called this discipline “organizational change management.” I don’t anymore because the work involved in what’s commonly called OCM has little to do with managing organizational change and everything to do with preparing the organization for change.
  • Change orchestration: Business change of any size and scope has a lot of moving parts. It crosses organizational boundaries, changes employee and management responsibilities, and otherwise needs to be deployed in a carefully planned sequence so that a premature change in one area doesn’t ripple downstream in ways that prevent work from getting done.
  • Project management: Yes, of course project management. The previous five disciplines generate tasks that have to be undertaken and completed in some sort of planned order by specific staff to which the tasks are assigned. Project management is how organizations keep track of the tasks and make sure they’re finished when they’re supposed to finish.

Take a look at this list without first-class optics and you’ll be forgiven for thinking it looks awfully waterfallish. It’s certainly easier to explain business change in waterfall terms: Design, build, deploy, in that sequence, with some ancillary disciplines thrown in to sand off the rough edges.

Interestingly enough, while it’s easier to explain business change in waterfall terms, actually implementing business change is a lot easier when you apply Agile concepts to the challenge. That’s because waterfall’s long-standing shortcomings don’t get any better when applied to business change instead of software development.

The shortcomings? There are two. The first is the difficulty of comprehensively designing big things and getting the details right when nobody has enough experience with it to provide suitable guidance. Imagine the challenge is designing a flying car. The early generations are likely to miss important features like “What’s underneath my car! I can’t see through the floor!”

Waterfall’s second shortcoming? It’s the risk of designing anything so big that by the time it’s actually built, the situation has changed and it’s no longer fully relevant.

Iterative, incremental business change is a lot less complicated to manage. Which doesn’t make it easy by any means. In particular, just because a business design evolves in small steps, it still has to conform to an overall plan. And just because the steps are smaller you still can’t ignore the six change disciplines.

There’s another challenge too — scaling.

No, not scaling the six disciplines up. In many respects the challenge for agile business change is harder.

You have to scale them down.

Comments