Friday, September 05, 2003

Scoping, Testing, Prototyping, Expanding and Change

In an uncertain world, it's hard to be right all the time. And we all know that hindsight is often good after you have made a mistake (though hindsight is not always perfect -- people do draw bad conclusions about what went wrong).

When you are tackling a new problem, there is, I believe, a sequence that reduces risk. My examples come from both technology projects and new product launches.

The Four Stages

Scoping is something that good managers do automatically. But even good managers often fail to scope. What I mean by scoping is doing what some have called the "back of the envelope calculation". In technology, most scalability problems occur because the team fails to ask up front the key question: "How big and complicated is the problem?"

An analog in the selling process is "Is this customer capable of purchasing my product or service?" If you fail to ask this question, you can waste a lot of time and effort.

In the new product development area, the key question is, "What is the compelling reason and value that my product or services offers that will trigger a sale?"

Even if you have scoped a problem, you still need to test your idea. In a world filled with technology, one of the best ways of testing an idea, a project or a product, is to ask other experts who have experience in the area.

Actually, asking the experts is easy. Listening to what they say is much harder.

In the new product area, there is no substitute for market research. In fact, market research done badly or not at all is the major cause of new product failure according to major surveys (in about 45% of the cases).

There's a pretty simple rule in life. It seems to appy to just about everything. Large is typically riskier than small. A large information warehouse is a very risky project. Developing a subset of the problem first generates a lot of learning. And it can help you to refine your scoping estimate and validate the opinions of experts.

Just as importantly, most managers can't actually tell you what they want. They need to see something. But whatever you build will be wrong, so keep it small.

And with new technology products, usability studies and user interaction studies are often key to producing a superior product.

Expanding and iterating a project is exceptionally important because this is where the big money gets spent. Best practices in software development involve what is called iterative development. Strategist like Benko and McFarland (Connecting the Dots) talk about chunking a project to minimize risk and allowing the project to be killed if it stops being relevant.

Some writers like Jeffrey Moore (Crossing the Chasm) also point out that as you expand your market, the type of buyer, their needs and expectation change.

Projects and technologies develop inertia. As a result, it is extremely difficult to kill off old technologies and old projects. Encouraging change requires leadership and the willingness to specify the need for a major increase in performance improvement.

All this seems obvioius when you put it down on paper, but we all seem to forget these basics.

Alistair Davidson

No comments: