Accept responsibility to make your online project work

By David Walker (Google profile)

Most online projects fail because their business managers won't accept responsibility for them. They place their project's destiny in the hands of people who don't care enough about them.

This is the simple and oddly compelling message of e-business consultant Chris Thomas. It's a message not about technology but about determination and diligence, notions often ignored in the hip world of the dot-com boom.

Thomas has spent more time than most managers in technology start-ups - 17 years in all. He founded the transponder company Amskan as a 31-year-old in the mid-1980s; he set up the data services joint venture LMT Australia; he headed loan operations at eChoice, where this columnist worked with him; and he is now developing an online procurement project while working with e-business project management through his consulting company, Differential.

Over those 17 years, he has identified at least one trap that dooms many electronic business projects. You might call it the Sort-Of Trap.

"The business sort-of knows what it wants to do, because it has some good people with business experience," explains Thomas. "They have no idea at all about implementation, but they want to implement. So they hire people and firms who have built software and systems."

Those people and firms have their own interests, Thomas points out, and those interests won't necessarily align with the aims of your outfit. The outsiders want to bolster their list of stated achievements - their CVs, their corporate brag sheets. The individual developers want to work with bleeding-edge technology. The more pragmatic firms want to re-apply previous solutions. They’ll say "what do you want?" They’ll say "give us a specification".

It's here, argues Thomas, that the Sort-Of Trap clicks quietly shut. "The client will respond with generalities, because they haven’t thought out the detail of the project. And with that, they will cede all control to their technological hired guns."

The generalities doom the project because the technologists can respond to them in so many different ways. That's what makes software-building different from, say, road-building. Roadbuilding uses just one or two standard solutions; tell a contractor to build you a road and you can confidently predict the outcome. A hundred different solutions might build you a given piece of software, but each different solution will make the end product work differently. Most of those solutions won't do quite what you want.

Thomas recites the all-too-common course of events. The hired guns eventually come back with one of those solutions that doesn't do what you want. They ask "is this what you meant?" And so the organisation's managers say "no, we want that". The resulting system, built on guesswork and compromise and backtracking, fits together poorly and will be difficult to maintain, learn from and expand over time. And no-one wants to measure the business results coming out of this compromised system - not just because measurement is hard but because the managers fear they'll find bad news.

All that is management’s fault, says Thomas, "because the managers ceded control - they refused responsibility for their own destiny". They settled for vague statements that let the technologists define what the delivered software actually did.

What must managers do to avoid this trap? They must define in precise detail what users of the system can do - a tough, confronting task which takes place before a single line of code is written, and which requires managers with at least a small measure of technical savvy and a great deal of determination. This project definition becomes the starting point for a back-and-forth dialogue with the development team. Business management and technologists refine the project together. Only here, says Thomas, can the software team start writing code.

In June 2001 I put Chris Thomas's diagnosis to a Melbourne Web managers' conference. The response was a surprising mix of agreement and relief - relief that lots of people have made the same mistakes, and that there's a path to avoiding those mistakes. As online managers struggle to avoid past errors and an increasingly obvious failure rate, responsibility might just become a trendy notion.