ManagementSpeak: The existing packages are too expensive, we’ll do it in-house.
Translation: We can’t afford to pay what it costs, so lets underestimate the cost to get the team going, once they’re committed we can overrun the budget.
IS Survivalist Harvey Lockie reveals a popular management strategem.

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, even though 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 Extreme Programming (XP) and the Rational Unified Process (RUP) — 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 — processes, the roles employees play in the business, the skills they need, and probably 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 the software is doing anything useful until they’re performing business the new way.

Don’t give up. The logic in favor of prototyping is even more valid when dealing with serious business change, because the cost of a business design being wrong is far higher than the cost 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!