All Posts in Metrics

|In: Career Management|Last Updated:

Somewhere in the business you support is a manager who needs to do things more effectively. The alternatives:

  • Shovel a request into the IT request queue.
  • Ask Clyde, who’s “good with PCs” to do something magical with Excel.
  • Bring in a local IT services company to build a system that helps do things more effectively.
  • Find some inexpensive off-the-shelf software that will help do things more effectively, then badger IT into allowing its installation.
  • Contract with a SaaS vendor whose software will help do things more effectively and don’t tell IT anything about it.
  • Sigh a great sigh and give up on making things happen more effectively.

The first bullet is The Right Way To Do Things.

The remaining bullets are all some form of end-user computing (EUC) or the dreaded shadow IT.

Except for the last bullet, that is. The Great Sigh is a key reason entrepreneurships are able to beat, or at least hold their own against their giant competitors.

Let’s add a dimension to this mess exciting array of alternatives: The backbone and hub of your enterprise technical architecture is one of the major commercial ERP suites. What the manager needs would, most logically, be implemented as a customization to one of the ERP suite’s modules.

Nope. Can’t have that. So option #1 — the right way to do things — is off the table, leaving only end-user computing (EUC), Shadow IT, or sighing deep sighs on the table for our sadly un-mythical manager to choose from.

Compared to the rest of the population, KJR’s readers are, disproportionately, metrics nerds, so let’s add a nerdy metrical dimension as well.

The metrics your average business manager cares about in this situation are, in descending order of importance:
1. Cycle time: Start the stopwatch the moment the manager first develops a reasonably clear idea of what’s needed. Stop it when the software is in production and the manager’s employees are doing things the new way. More than anything else, managers want this cycle time to be short.
2. Quality: No, not being bug free, although that’s nice too. Quality isn’t just the absence of defects. It’s also adherence to specifications – whether the software does what the manager needs it to do. By this definition, the plain-vanilla version of the ERP suite’s module is a low-quality solution. It doesn’t do what the manager needs it to do, because if it did, the manager wouldn’t be submitting the request. Q.E.D.
3. Fixed cost: This is the initial spend – how much the manager will have to pay for the solution. This matters because above a certain amount the software becomes a capital acquisition, which means the manager would have to go through the company’s CapEx approval process … a governance process that makes the IT request queue seem downright friendly and inviting in comparison.
IT’s priorities, presumably reflected in your company’s IT request governance, are quite different, usually along the lines of:

1. Financial Value: Amortize the fixed project costs over some reasonable number of useful years of software service. Add the expected cost of ongoing maintenance. Subtract from the business benefits that will come from doing things the new way. Divide by total cost to turn the result into a percentage. (Yes, yes, multiply by 100. Don’t be pedantic. Oh, I forgot — you’re a metrics nerd too. Okay.)

If the result is a positive number, rank it against all the other requests that have to compete for IT’s time and attention.

2. Political Value: Don’t be shocked. Also, don’t be outraged. The Financial Value undervalues a lot of what are, in polite company, called “intangible benefits.” (In less polite company they’re called “warm fuzzies”; also, “Don’t be ridiculous!”)

As minor matters like customer satisfaction usually fall into the intangibles bucket, there’s often value in political value — for someone standing up for what matters most, even if it’s hard to put a number to it.

3. Strategic Value: Some projects are part of the strategic plan — they advance the strategy. Others aren’t part of the plan but they are consistent with strategic intent. There are no others — any manager worth his or her salt knows how to write the obligatory two-paragraph account of how their pet project fits into the company strategy.

Compare the two sets of priorities and it should be clear why, for most managers, and especially for smaller efforts, EUC and shadow IT are the preferred ways to go.

Doing things the so-called right way might make a manager a good corporate citizen.

But EUC and shadow IT are what get the annual bonus.

Comments

|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