All Posts in Policies and Procedures

|In: Leadership|Last Updated:

I have a confession to make. I like Microsoft Access. In fact, I like it a lot.

The Microsoft Jet database engine is a disaster, but Access itself lets me snap together simple applications in not much more time than it takes me to think through the design. Sure it lacks some niceties, like decent support for recursive data structures. The lack of a macro recorder is simply baffling. Some features blow up inexplicably. Still, all in all Access generally stays out of the way, letting me do what I want to do without a whole lot of trouble.

Microsoft Access lets end-users design simple systems simply. So why do so many IT professionals complain when end-users do just that? Because many of these end-user-developed systems succeed, that’s why. By becoming too successful they become production applications … fragile production applications that require duplicate data entry, disagree with the system of record, disagree with other independently-developed Access applications that have succeeded, and sometimes just plain blow up. Did I mention that the Jet database engine is a horror?

These problems don’t just cause headaches for IT. They cause headaches for the business as well: A workgroup that used to work inefficiently using pencil-and-paper techniques now can’t work at all until its “production prototype” is up and running again; and a department that gets different answers to the same question depending on which database it queries never knows the right answer. To be fair, these same workgroups gave different answers to the same question when they used pencil and paper, too. It just took them longer to disagree.

Many IT organizations, seeing only the cost of the mess and not the business benefit of the automation these applications provide, simply ban Access. I formed the mythical Value Prevention Society (VPS) earlier this year as a place for them to congregate.

Enlightened IT organizations take a different approach to the problem. I’ve outlined some elements of their operation in earlier columns: Train power users in data-design; expose production data to MS Access and Excel (read only, please); and provide advisory services to end-users engaged in developing applications that use these tools.

By themselves, though, these steps mere ensure each individual application behaves as well as possible. It doesn’t solve the problem of having hundreds, or even thousands of them floating around colliding with each other.

A tangle of Access applications is nothing for IT to sneer at, of course. In many companies, IT has created its own tangles that are still in production as well. All that’s happened is that end-user-developed Access applications reveal the core problem of enterprise architecture at a different stratum of the organization. IT architects know that optimization of the parts doesn’t result in optimization of the whole — often the result is the opposite. A portfolio of individually sound, best-of-breed applications can still yield an icky applications portfolio. Which points to the solution for the Access tangle.

When enterprise architects analyze an applications tangle, they work with business areas to settle on a portfolio of go-forward applications, and create a coherent integration strategy. Then they develop a decommissioning plan for the other applications.

Do something similar for the Access tangle. Get close enough to the business to know which Access applications have reached “tangle” status. But instead of choosing some as go-forward applications, use the tangle to provide the specifications for a new, production-grade application to replace the whole shebang. My guess: IT should be able to replace an Access tangle with half the effort it would have taken to be involved at the beginning.

Last week’s column pointed out that there’s no such thing as an IT project. It’s always about changing the business. That’s still true.

What’s attractive about the Access Tangle Replacement Methodology (ATRM) is that the business change takes place before IT ever gets involved.

Comments

|In: Leadership|Last Updated:

It’s always about changing the business.

There is, you’re probably tired of reading, no such thing as an IT project. It’s always about business change. Sadly, many IT organizations are stuck in the old way of thinking. Their life cycle is still waterfall: Feasibility, requirements, external design, internal design, construction, testing, and implementation. It’s up to the affected departments to figure out how they should run differently while IT goes about its business.

More enlightened organizations do it differently. In place of “feasibility” (a meaningless term: It’s always feasible; the question is whether it makes sense) they start with a business plan. In place of requirements, external design and internal design they undertake analysis, functional design, and specification. Much better: Analysis looks at the current state of the business; functional design is a high-level look at the desired future state that references the current state to make sure nothing important gets lost.

But it’s not quite good enough, because it’s backward. Analyze, then design does seem like the logical order of events, largely because it is the logical order of events. Logic, though, isn’t always what it’s cracked up to be.

What’s the problem?

Okay, we’re going to redesign the company’s whole order entry process. You’re on the team. The business plan looks good. The project launches, the team is pumped, and what’s the first task it undertakes? Not the fun stuff. Analyzing the current state sucks the energy right out of the team.

Sometimes, it never returns.

Design the future state first. Doing so will float all kinds of questions that can only be answered by analyzing the current state. The team will then dig into analysis of the current state with a solid purpose behind it. Logical, no?

So far so good. But there’s still one remaining issue we have to deal with: Most process re-engineering projects begin with a tacit assumption that the current state is a bad design. Usually, that’s just plain wrong. Also, it’s insulting to the process managers who must become champions of your project in order for it to succeed.

To explain, I have to reveal one of the deep secrets of the consulting gurus: It’s easy to make the current state look awful.

There’s nothing to it, in fact. All you have to do is move the boxes around so as many lines cross as possible, while including every logical branch and exception in a single flow chart. Compared to that ugly mess, the elegant concept that is your functional design is clearly superior.

Except, of course, that it isn’t. At some point in the proceedings you’ll have to build in provisions for every one of those logical branches and exceptions. The fact of the matter is that most “legacy processes” are nowhere near as bad as they seem. Many are really quite good, given the limitations of the technology on which they are built; even the worst are simply an accumulation of necessary decisions made one-at-a-time over a long span of time.

Take this reality into account when you formulate your business plan (or “Feasibility Study” if you insist). I’ve seen multi-hundred percent savings forecasts, produced by very senior (and expensive) consultants, simply evaporate during the slow march from great concept to hard reality.

So whether you’re leading the team or you’ve brought in outside experts, here’s some advice you can take to the bank: Assume everyone has been smart. That will force you to ask the really important question: What will your project bring into the situation that will enable serious improvement? Because there’s one thing I’ll guarantee:

Even the best process designers have a hard time improving on a process that works if they don’t change the rules.

Credit where it’s due: The recommendation that you don’t automatically assume something you don’t fully understand was done wrong came from Carlton Vogt, author of Enterprise Ethics (www.enterprise-ethics.com). Carlton’s opinions are always worth reading … including, I hope, the one here.

Comments