How to become the new business analyst needed in IT

Last week we discussed the bad news for traditional techies -- the fact that IT projects no longer exist. These days, every project is about improving the business or there is no point in launching them.

[ Also on InfoWorld.com: Get Bob Lewis's continuing IT management wisdom in his Advice Line blog and newsletter. | Find out why running IT as a business is a train wreck waiting to happen. ]

Oh, there are still plenty of companies where everyone inside and outside IT think they have IT projects. Here's what happens in these retrograde enterprises:

1. Somebody in the business (a business manager, perhaps) has a bright idea about how they can automate part of their operation. They contact IT, which sends over a business analyst.
2. The business analyst asks what the system should do.
3. The business manager tries to figure out what it should do.
4. The business analyst writes a requirements document, which the business manager can't make heads or tails of but signs anyway because otherwise nothing will get built.
5. The business analyst writes a system specification that IT developers use to either configure and integrate a commercial piece of software, or develop a custom application, or modify and enhance an existing system.
6. When the software is finished, the business analyst performs user acceptance testing. (I have, by the way, laid this out to dozens of IT audiences over the past several years, and what's scary is how seldom I get so much as a chuckle. If you also see no problem with this statement, read it again, carefully, and ask yourself who should be performing user acceptance testing. Hint: It isn't called business analyst acceptance testing. That would be BAAT, not UAT.)
7. IT's trainers teach the end-user community how to operate the software.
8. The software goes into production, where the end-users try their best to get it to do what the old system did -- or if there was no old system, what they're accustomed to doing manually.
9. Or the business requester looks at the software, concludes it's useless, and gets into an argument with the IT team as to whether the fault lies in the requirements and specifications or in the software itself.

Here's your challenge: Identify the step where it all went wrong. You have a minute. I'll wait.

Ready? If you answered either Step 1 or Step 2, you pass.

Step 1 is a problem because the businessperson isn't thinking about how to improve how the business should run. He or she is starting with the assumption that automation is always the way to improve things. It isn't, which leads us to a side step that could also double as the title of a spy thriller: the Eddington's solution.

Eddington's is a Minneapolis-based restaurant chain. It sells very good soup in three quantities: cups, bowls, and "bottomless bowls," with as many refills as you want.

Eddington's solved the problem of keeping track of which customers are entitled to refills and which ones aren't without the use of any information technology at all. The company used (drumroll, please) different-shaped bowls.

Which leads to the question: Would a traditional IT business analyst have suggested different-shaped bowls -- solving the business process problem -- or would the business analyst have worked with Eddington's owner to determine the system requirements, used the requirements to develop a system specification, and from there lead the restaurant chain into bankruptcy, thereby depriving large numbers of lunch-goers the opportunity to enjoy soup and breadsticks (also very tasty).

This is why Step 2 is the other correct answer: Even if the business executive makes the mistake of starting with the assumption of automation, it would be OK if the business analyst handles this step properly. Here, she or he hasn't. The conversation in Step 2 is about what the software should do. It's a terrible topic because it isn't where business managers are supposed to be experts.

Some business analysts have figured this out. When someone starts out talking about what they need in the way of information technology, the analyst tells them to hold off on that and instead explain what it is about how the business operates now that's a problem, and how they'd like it to operate instead. "Your job," they explain, "is to understand what 'runs better' looks like. My job is to work with you to figure out how to make 'runs better' happen, and as part of that to help figure out what roles information technology should play."

Which is why there are no IT projects. IT projects deliver software that satisfies requirements and meets the specs. Making the business run better? That's someone else's problem, and as nobody has had the conversation about what "runs better" looks like, it's unlikely to happen except by accident.

One more thing: This explains why Step 7 also leads to disaster. Explain how to operate the software, and each end-user will figure out how to do his or her job with the program independently, leading to an excitingly diverse database in no time at all.

Training should be how to do their jobs the new way using the software -- a very different matter.

Here's how truly enlightened companies (management-speak for "companies whose leaders agree with me") handle things: Business analysts don't even start by asking what "runs better" looks like. They ask what "runs better" means, because "better" can have six different meanings: reduced overhead cost, reduced marginal cost, shorter cycle time, increased throughput, higher quality, or additional "excellence."

Just to make sure we're using the same words the same way:

• Overhead cost is the cost of turning on the lights, before any work gets done.
• Marginal cost (also called "incremental cost") is the cost of processing one more unit of work.
• Cycle time is how much time is needed for one unit of work to move from the start of the process to completion.
• Throughput is the number of work products delivered in a unit of time.
• Quality is either the absence of defects or adherence to specifications. Quality is what you notice when you don't have it.
• Excellence is the presence of highly desirable characteristics: tailoring, customization, a rich set of features, and so on. Excellence is what you notice when you do have it.

These all trade off with each other in complex ways. To improve quality, for example, businesses often have to invest in infrastructure, raising overhead costs. Along with that they often simplify and standardize features, reducing excellence.

Want excellence? You very well might if, as we've been discussing the past few weeks, your business wants to cater to the luxury trade, however it's defined. But with excellence comes complexity, variability, higher marginal costs, poorer quality (or, more likely, even higher marginal costs to achieve quality), and reduced throughput.

Remember the distinction between processes and practices? As a general guideline, if you want quality, you want a process, but if you want excellence, you need a practice.

The point: Defining "better" precedes making it happen.

And so, there are no IT projects, only projects that improve overhead cost, marginal cost, cycle time, throughput, quality, or excellence; pick no more than three.

Once you've picked them, you're ready to talk about how.

This story, "How to become the new business analyst needed in IT," was originally published at InfoWorld.com. Read more of Bob Lewis's Advice Line blog on InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.