| About InfoWorld : Advertise : Subscribe : Contact Us : Awards : Events : Store |
 |
||||
|
||||
 |
||||
 |
|
|||
 |
||||
|
|
|
||
|
|||||||||||||||||||||||||||||||||||||||||
 COLUMN
The value of a test drive MANAGEMENTSPEAK: The existing packages are too expensive; we'll do it in-house.
-- IS Survivalist Harvey Lockie reveals a popular management stratagem. I WONDER IF any skill remains relevant by the time we've mastered it. Take prototyping as an example. The idea has been around as long as engineers have been designing gadgets, but we in IT resisted the notion for decades -- although business users clearly would have preferred it to the "waterfall" methodologies we insisted on -- secure in our conviction that the prophets of methodology knew whereof they spoke. If it isn't justice it's at least a delicious irony: Just as the apostasy of prototyping -- built into the heart of such disciplines as XP (Extreme Programming) and the RUP (Rational Unified Process) -- has replaced our faith in waterfall methodologies, events have overtaken us. In the old world of information technology, we automated previously manual processes. Prototyping worked fine for the business because the work being performed didn't change in any fundamental way. There is, however, no longer any such thing as an IT project. Every project we're involved in is about business change. We're redesigning the business -- the processes, the roles employees play in the business, the skills employees need, and probably the reporting relationships and a bunch of other aspects of the business besides. What good is a software prototype when it will only make sense in the context of a different way of doing business? Sure, we can produce one and give it to end-users to play with, but what will we learn by doing so? Nothing. The end-users won't have the faintest idea as to whether or not the software is doing anything useful until they're performing business the new way. In fact, one of the bigger problems with process re-engineering is the difficulty of bench-testing the new process. Don't give up. The logic in favor of prototyping is even more valid when dealing with serious business change, because the costs of a business design being wrong are far higher than the costs of a software design being wrong. Which is why it's so important to build a pilot implementation -- in effect, a prototype of the new way of doing business -- into any software project. A business prototype has to be small enough to be controllable and tweakable, while also being both real and complete enough to provide a useful test of the new way of doing business. Satisfying these criteria is far from easy. That, however, isn't what concerns me about the discipline. What concerns me is what we'll have to become good at once we've mastered this! Send a prototype e-mail to RDLewis@ISSurvivor.com. Bob Lewis is president of IT Catalysts ( www.itcatalysts.com ), which helps companies improve IT effectiveness and strategic alignment. Discuss this article in our online forums MORE > SPONSORED WHITE PAPERS 
SPONSORED LINKS
|
|||||||||||||||||||||||||||||||||||||||||
|
||||||||||
|
||||||||||
