Keep the Joint Running
by Bob Lewis
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.