All Posts in Strategy and Tactics

|In: Industry Commentary|Last Updated:

Excellence is fragile. Dumb mistakes, in contrast, are more durable than Kevlar. It’s a universal law. For evidence, look no further than Microsoft Outlook.

Try this: Go to July 4th. If Independence Day isn’t already listed as a holiday, enter it as an all day event. Then click Tools/Options, the Calendar Options button, then the Time Zone button. Make sure “Show an additional time zone,” is checked, and set up a different time zone from the one you’re in. Click the Swap Time Zones button followed by Okay until you’re back in Outlook, and guess what: Part of Independence Day occurs on either July 3rd or July 5th, depending on your time zone choice.

Way back when Microsoft first designed Outlook, someone decided it would be clever to treat all-day events and midnight-to-midnight appointments the same way. Every subsequent version has inherited this bonehead design decision, which makes calendar management quite annoying for travelers who schedule events and telephone calls in multiple time zones, and want to show up or dial when they’re supposed to.

But wait. It’s worse! When Palm designed the original Palm Pilot, it ignored time zones altogether. You schedule meetings in local time, change the clock when you change time zones, and that has to do.

For entirely mysterious reasons they designed it this entirely incompatible way, even though they also designed it to synchronize with Outlook. The result? Change time zones in Outlook, the clock on your PDA, synchronize, and your calendar starts to look … wrong. And every subsequent version of the Palm PDA has inherited this bonehead design decision.

You’d think neither Microsoft nor Palm ever figured out that people travel.

I’ve found two PDA-based products that claim to fix the problem. One instructs me to never change the time zone on my PC, only the system clock. And by the way, it’s only reliable if I only enter appointments in my PDA, never in Outlook. No thanks.

The other would be fine if it weren’t for those pesky all-day events, and if it worked. Synchronize a few times and both all-day events and regular appointments act like gerbils — they mysteriously multiply. Make that cockroaches, because sometimes you can’t get rid of them: No matter how many times you delete them they just reappear.

The point of this column isn’t to gripe about Outlook and Palm (well, okay, that’s one point, but there is another, larger one). It’s to encourage you to encourage your managers to encourage everyone who works for you to pay attention to the consequences of their design decisions, because bad design never goes away. Quite the opposite — bad design inevitably creates a cascade of ever-more-fragile workarounds that eventually turns even the finest system into a shambles.

For example: Imagine you start up an on-line clothing store. As part of your systems you implement a customer database. In it you define “customer” as an individual: First name, last name, address and so forth.

After a couple of years you discover that sometimes, more than one customer lives at the same address. You’re selling to households and you never suspected. What to do?

Deadlines are tight and other priorities compete for attention so you take the easy way out — you create a Households table and write a program that sweeps the database once a night, recognizes new households, and populates the Households table accordingly.

Two years later you start selling embroidered clothing to businesses that stock up “trinkets and trash.” Now you also have to handle whole corporations, with multiple contacts, as customers. The pressure hasn’t let up, so you handle this situation much as you handled the Households problem.

The result: Every software change from this point forward has to take these kludges into account, increasing your costs while slowing down your ability to adapt to changing circumstances.

The moral of this story is simple: When you find that some of your design assumptions have changed, in the long run it’s better to adjust the design to your new circumstances than to make the quick fix.

Microsoft’s (and Palm’s) challenge is finding a financial motivation to fix the time zone problem, because it’s hard to see how doing so will sell any more software. Yours is a bit different: While “pay it now or pay it later” is easy for an engineer to understand, pay-it-now dollars are much more tangible than pay-it-later dollars.

Understanding the principle is the easy part. Helping the business make the right decision is a lot harder.

Comments

|In: Leadership|Last Updated:

Consultants are attracted to Mission Statements the way flames attract moths. They always seem like such a good idea … until you get started. Almost inevitably, the roomful of people deteriorates into a squabbling mass. Some are fighting to make sure what they do is included; all argue passionately about the placement of commas and whether “happy” or “glad” is the more appropriate adjective.

I proposed a solution a long time ago (“Mission statements: Their cause and cure,” January 29, 1996) and updated it in Leading IT: The Toughest Job in the World. (Short version: Focus on concepts, not phrasing; make sure each concept is viewed as an alternative, not an embellishment; and insist that each concept describes ends, not means.)

It’s time to wrap up our discussion of organizational optimization. It began with a proposition from the KJR Manifesto: That to optimize the whole you have to sub-optimize the parts. Then we figured out that “optimize” has to be with respect to only one system variable. And last week we found that for real-world businesses, optimization is really a chimera anyway because there’s no practical way to understand a business and its markets well enough to figure out what “optimum” even means.

What business managers need to do, it turns out, is to set their sights a bit lower — to improve. Since “form follows function,” is the touchstone of organizational design, just as it is for any other design discipline, if you want to know what constitutes improvement you have to know what you’re trying to accomplish. That means understanding the enterprise’s mission, vision and strategy. Then you can craft your own organization’s mission, vision and strategy so they further those of the enterprise.

This is why consultants facilitate Mission Statement drafting sessions. It isn’t because we find Mission Statements … and Vision Statements, and strategies … appealing because we lack better ideas for padding our contracts (well, okay, some consultants do that, but at IT Catalysts we would never stoop that low — it would hurt our lumbar vertebrae). It’s because clients hire us to help them improve organizational performance, and we can’t until we know in which direction “improve” lies. (Just to make sure we’re on the same page: Mission is about the present — what you’re supposed to do. Vision and strategy are about the future: Where you’re going and how you’re going to get there.)

Were it not for the future, this wouldn’t be all that difficult. With clarity about what you’re trying to support and how you’re supposed to support it, you can be pretty clear about what you need to improve so you support it better.

But you can’t ignore the future. Businesses have strategies, strategies are about change, and that makes things messy. You and all the other parts of the whole have to figure out how to change in ways that are sufficiently well orchestrated that the business doesn’t tear itself apart, but not so carefully orchestrated that it loses all elasticity. You also have to figure out how to allocate your budget and staff so you don’t stop supporting the present, but also don’t support the present at the expense of the future. There is no magic formula. There is, however, Guideline #2 from the KJR Manifesto: Big solutions that work great generally start as small solutions that work acceptably.

Strategies start with a design and a plan. The successful ones start with an additional item: Recognition that the design, the plan, or both might be flawed.

That being the case, the plan should, if at all possible, be organized into small steps, not giant leaps. Each small step is defined in terms of improvement to one or more parts of the enterprise. Following each small step you reconnoiter, to make sure the design, plan, and company are all holding together.

To illustrate the point, imagine you and a friend decide to attend a Halloween party in one of those two-person horse costumes. Now imagine that the first thing you and your friend try to do is gallop around a path with a lot of twists and turns.

You might make it. More likely, one of you will zig while the other zags, tearing the costume apart. If that happens, both of you will be at fault, for trying to go too far too fast.

But while you both might be responsible for the problem, only one of you will end up looking like the back end of a horse.

Comments