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:
- 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.
- The business analyst asks what the system should do.
- The business manager tries to figure out what it should do.
- 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.
- 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.
- 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.)
- IT's trainers teach the end-user community how to operate the software.
- 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.
- 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.