All Posts in Policies and Procedures

|In: Organizational Design|Last Updated:

Take some number, double it repeatedly, and it gets very big very fast.

Nothing grows forever, though, because there are always limiting factors, so add a feedback term to slow the rate of growth as the number approaches them. The result is a smooth, S-shaped curve mathematicians call “The Logistic.” If, however, you delay the feedback, the Logistic turns into random fluctuations.

Welcome to Chaos Theory.

Let’s leave the universe of abstruse mathematics and rejoin your world, which undoubtedly includes one or more software development or integration projects. If you adjust your previous estimate of the remaining work by your measure of what’s been done, you can project the time needed to finish the sucker. Adjust your completion date accordingly. Except it’s never that simple, because the more you complete, the more that needs to be tweaked, fine-tuned, or changed completely.

Ready for the punch line?

This is a feedback term. Add a delay to this feedback term … perhaps because you’re using an off-shore, or even an out-of-town vendor to handle the programming. What do you get?

Chaos, that’s what.

When dealing with an outside developer, distance breeds problems. When the developer doesn’t live with your project team, you communicate through written specifications and e-mails, augmented by telephone calls and maybe even an occasional videoconference. Then, the vendor schedules the work, writes the code, and eventually gets the results back to you for evaluation. All of this takes time, and meanwhile the project has moved on.

Then it’s hauled back because the tweaked modules need more tweaking — perhaps because they don’t fit into other tweaks the need for which was discovered later on, perhaps because reliance on written specifications and electronic communications channels resulted in misunderstandings. Or both.

It’s delayed feedback — with noise in the channel — and it causes chaos.

So here’s a bit of advice you can take to the bank: Negotiate contracts so that as projects move from coding to testing, tweaking and final acceptance, the vendor will have programmers on-site to make changes in real time.

Real-time feedback with face-to-face communication works far better than any alternative. And while it might cost more than leaving the programmers in New Delhi, Manila, or someplace truly remote like Altoona, it will cost far less than the alternative.

Which is a project thrown into chaos.

Comments

|In: Leadership|Last Updated:

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!

Comments