All Posts in Organizational Design

|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: Industry Commentary|Last Updated:

One of the most popular games in the world of business is “Blame the Consultant.” No matter what actually went wrong — bad leadership, poor project management or sloppy implementation — it’s easiest to blame the consultants.

The most recent example is New York Times analyst Paul Krugman, who, in a recent editorial blamed the Enron fiasco on its leaders’ preference for guru-driven theories over business realities. Enron was, after all, led by Jeff Skilling, a former McKinsey consultant, and McKinsey is notorious for only handling the inspiration slice of the genius pie chart. Doesn’t that prove the point?

Sorry, but no. Enron’s problems apparently stemmed from old-fashioned fraud: When you show the cash but hide the debt, as has been alleged in this sorry debacle, it’s easy to post good numbers.

Krugman is, however, right about one thing: Enron built its whole business on the popular core vs context theory. If you’re unfamiliar with the terms, core activities differentiate you from your competitors, while contextual activities do not. Core/context theorists contend that you should outsource everything that isn’t core. The theory is especially popular among outsourcing companies, because … well, that’s obvious, isn’t it?

The theory suffers from two flaws, one fatal, the other merely grievous. The fatal flaw is that it’s just plain wrong: Context activities can differentiate you. Oh, not in a good way — nobody chooses a vendor because its invoices are always accurate. But context activities sure do differentiate you when you bungle them. They drive customers into the arms of competitors. And since it’s harder to manage a vendor well than to lead employees (vendors are more adept at hiding problems, and more motivated to do so), it’s hard to understand how the core/context theory leads to business benefit, except when an outsourcer has economies of scale unavailable to you.

That’s the fatal flaw. The grievous one is more basic: This isn’t a theory, it’s a hypothesis. Dig deep and you’ll find that the theorists are relying almost entirely on two high-profile test cases: Nike and Enron, both of which leave the doing-something-useful-that-creates-real-value aspects of running a business to others. Nike markets very well; Enron traded very well, or so we all thought.

Now we’re down to a single test case, and that’s awfully limited evidence on which to bet your company.

Treat this theory with caution. Outsource very selectively and only when you can quantify clear financial benefit, when you can build strong mechanisms to manage the additional risk, and when you can construct a clear exit strategy in case the outsourcing arrangement sours.

That’s the best advice I can give you. If you ignore it … please don’t blame the consultant.

Comments