All Posts in Organizational Effectiveness

|In: Architecture|Last Updated:

Three threads, one conclusion:

Thread #1: In a recent advertorial (“Stop Using Excel, Finance Chiefs Tell Staffs,” Tatyana Shumsky, 3/31/2018), The Wall Street Journal proved once again that, as someone once said, if you ignore the lessons of history you’re doomed to repeat the 7th grade.

Dan Bricklin first invented the electronic spreadsheet back in 1979. It was immediately and wildly popular, for some very simple reasons: It was incredibly versatile; you could use it to think something through by literally visualizing it; and, when IT responded as it usually does to requests for small solutions — not a good enough business case — users could ignore IT and solve their own problems, right now.

The Wall Street Journal’s story tells the usual tales of spreadsheets gone wild, with their high error rates and difficulties in consolidating information. What were those fools thinking, using Excel for <insert Excel-nightmare-case here>!?!

I was nowhere near the place and I can tell you exactly what they were thinking. They were thinking they had a job to do and the alternatives were (1) Excel, and (2) … uh, Excel.

The business case for the solutions extolled in The Wall Street Journal story was that the Excel-based solutions caused problems. Had users not solved their problems with Excel first, they’d still have no business case.

When Excel is the problem you can be sure the pre-Excel problem was much bigger.

Thread #2: One of my current consulting areas is application portfolio rationalization. It’s usually about enterprise applications that number in the hundreds, but sometimes clients want to consolidate desktop applications that, in large enterprises, easily number in the thousands, not including all of the applications masquerading as Excel spreadsheets.

It’s a shocking statistic, and a support nightmare!

Only it isn’t a shocking statistic at all. A typical Fortune 500 corporation might have 50,000 or more employees. With 50,000 employees, what are the odds there aren’t at least a couple of thousand different processes that might be improved through automation IT will never get around to?

It isn’t a support nightmare either. For the most part the applications in question are used by a dozen or fewer employees who are almost entirely self-supporting.

Support isn’t the problem. Lack of control is the problem. And, in highly regulated industries, lack of control is a real problem corporate compliance needs to solve. It needs to document not only that a given business function’s outputs are correct, but that its processes and supporting tools ensure they’re correct.

On top of which, information security needs to ensure applications with gaping holes are kept off the network, and that applications stay properly patched so that as new vulnerabilities are detected, new vulnerabilities are addressed.

All of this is certainly harder when each business function solves its own problems, but it’s hardly impossible.

And it’s much easier when IT is an active partner that helps business functions solve their own problems.

Thread #3: Once upon a time I was part of a team that redesigned our company’s CapEx governance process. We hit upon a novel idea: that our job wasn’t to prevent bad ideas from leaking through. It was to recognize good ideas and help them succeed.

It turned out we were on target. What we found was that bad ideas that needed screening out were few and far between. Good ideas explained badly? We saw plenty of those.

Tying the threads together: Large enterprises have lots of moving parts, which means small problems are real, worth solving, and too numerous for IT to handle on its own. Users engage in “rogue IT” to make their part of the business more effective, because they can and they should. IT ought to find a way to help their good ideas succeed instead of assuming they’re all pursuing bad ideas that have to be stopped.

The KJR solution: create a Certified Power User program (CPU — catchy, isn’t it?). Certified Power Users will understand the basics of normalized design so they can use MS Access instead of spreadsheets when they have a database problem to solve. They’ll know how to evaluate solutions professionally, so they don’t buy whatever looked flashy at a trade show. They’ll also know how to keep solutions patched, to minimize vulnerabilities.

And, they’ll keep an inventory of the small solutions they create and share it with IT.

In exchange, they’ll have administrative privileges for their PCs, and those of the users they support.

When you’re trying to persuade, “Let us help” is a more powerful message than “No you can’t.”

Comments

|In: Office Politics|Last Updated:

This week’s profound advice: Be plausible.

I was “talking” to Quicken’s chat support. I’d been trying to add a new investment account — something I’d done several times without trouble over the twenty plus years I’ve used Quicken.

The quick and accurate diagnosis: I’ve been using Quicken Starter Edition. That feature now requires Premier. The last update I applied removed it from Standard.

If Quicken sold cars instead of software and I bought a Quicken Standard, three years later, during a scheduled oil change, its mechanics would remove the turbocharger because the Standard no longer comes with one.

Look, kids, when you sell a product, the buyer decides if its features justify the price. Having paid that price, removing some of the features fails the plausibility test.

Speaking of plausibility, I recently had to renew my Minnesota driver’s license. Minnesota was one of the last holdouts for the TSA-mandated REAL ID, so sadly, REAL ID compliant driver’s licenses won’t be available in Minnesota until October of this year.

But that’s okay, because in the meantime I can get an Enhanced driver’s license, which isn’t a REAL ID license but is REAL ID compliant. It gets better: An Enhanced license but not a REAL ID license lets me drive in Canada, Mexico, and Bermuda.

Terrific — I want one! Especially for Bermuda in January! Only … I’m sorry, Mr. Lewis, but here at the Hennepin County Government Center building in downtown Minneapolis, the Minnesota DMV isn’t equipped to provide these. To get an enhanced license you’ll have to go to the Minnesota DMV office conveniently located in the nearby suburb of Plymouth.

I’m sure there’s a logical reason for this. I’m sure some committee somewhere looked at the available budget, drew coverage map alternatives, debated, erased, and re-drew until the budget was exhausted and so were the committee members.

And yet, right there at the surface where people walk up to the service desk, this is utterly implausible. It simply makes no sense that the location serving the largest number of people who need driver’s licenses doesn’t provide the most complete set of services. No amount of explaining will make it appear remotely plausible, no matter how much actual thought and logic went into these decisions.

How about you?

Take a common approach to IT governance: For IT to implement a solution, the business areas that want it have to submit a request that includes the business justification. An IT steering committee of some kind evaluates the requests, sorts them into priority order, and decides who gets some or all of what they asked for and who doesn’t.

If you’re on the inside of designing this sort of governance it probably looks like it makes sense.

But imagine you’re on the other side of the metaphorical IT services order counter. You’re a member of a five-person workgroup, you’ve found inexpensive or open source software that will make the five of you, say, 20% more effective at what you do. You add up the time needed to learn the proposal process, fill out the required forms, and defend it at the next steering committee meeting.

It’s more time than you or IT would need to just do the job.

Only you can’t because IT locks down PCs so you can’t, and IT can’t because your project is too small for the steering committee to worry about.

The loud and clear message from IT: We won’t do it for you and we won’t let you do it yourself, either.

So you kludge together something in Excel instead.

It’s utterly implausible.

It’s also easy to fix, which makes the reality even more implausible.

The fix comes in three parts. Part #1: For existing applications, go Agile. Whether they’re epics, features, or enhancement-scale requests, they all go into the backlog as user stories. The product owner sorts them. Problem solved.

Part #2: For small new needs, the IT Steering Committee allocates pools of IT developer hours. Requesters “spend” out of their pool. See how easy this is?

Part #3: Information Security sets up an application screening group. When someone in the business identifies a potentially useful application, the screening group evaluates whether, where, and how it might pose a risk. The default is a green light, which is given unless InfoSec identifies and explains the risk, so the requesting organization knows what to look for when researching alternatives. Nuthin’ to it.

And that’s the point. Avoiding implausibility isn’t hard. As the poet said, “O wad some Power the giftie gie us, to see oursels as ithers see us!”

That’s all it takes.

Comments