How to avoid chaos
Proximity to developers can be the key to making sure that your project stays on track
MANAGEMENTSPEAK: We’re going to guarantee delivery of a quality product.
TRANSLATION: We’re aren’t ever going to deliver a product.
— An anonymous IS Survivalist clearly delivered a quality product: this week’s translation.
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.
