Lately I've been talking to a lot of people about innovation, and the culture and processes necessary to succeed as an "innovative company". It seems to me there's a lot of good thinking that could begin to permeate business process and culture even in a less innovative firm.
One of these concepts is the idea of failing faster. It comes from the concept of creating a "strawman" or prototype of an idea and trying it out. Putting the prototype, mockup or whatever you'd want to call it in the hands of some likely consumers is the best way to get quick feedback, and to uncover requirements and features that weren't communicated earlier. Basically, the faster you can prototype a solution, the more time you have to craft an even better solution, since the prototype will elicit a response that you just can't get by talking about an abstraction.
Now, port these concepts over to the rather mundane business processes you work within everyday. The next time you need to change a process or discover a better way of working, rather than sit around all day in meetings trying to decide what everyone wants, just create a mockup of the new process or new product. Put the new process through its paces and get feedback. You'll get more input, better requirements and feedback and a more realistic, useful set of specifications than in just about any approach.
You've got to be willing to change the dynamic in which you work, and be willing to build something that most likely will get thrown away (the prototype) but I can assure you in almost every case you'll have a better result using this approach, in less time, than in just about any other process.
Why?
1. It's concrete, not abstract. Most individuals don't work well with verbal abstractions, they need to see something or work with something. A prototype, mockup or simulation lets them interact with a solution rather than just talk about it.
2. When they work with it, they will communicate requirements and needs they would not have thought of in a typical requirements session. In most requirements gathering sessions, people come with two types of requirements: ones that don't matter (what color it is) and ones that solve a problem so specific that only the person submitting the request will see a benefit. Many of the remaining requirements are "god and motherhood" kind of requirements that you could generate before you went into the meeting. Actually working with a representation puts the user in his or her role with a new process or tool and forces them to think through what they actually do, not what feature they may simply want.
3. They can be specific about requirements and raise real concerns. In a simulation or when working with a prototype, users can point out real problems that may occur. For example, one customer of ours built a prototype of a new product which they felt would be a great new product. However, once they started working with the prototype, the distributors felt that it would be too difficult to service and maintain, and they helped revise the product specifications. This kind of thing is very hard to do without a prototype or simulation.
4. You can iterate and obtain buy-in. In this approach, it's ok to iterate and loop back to the same folks, as long as you are bringing them something new that incorporates what you've learned previously. In fact, as long as you demonstrate your willingness to learn and incorporate what they are telling you, you'll get greater buy-in as the people trying out the new product or service begin to recognize their impact on the new product or service.
Many people will scoff at this approach. They'll want long JAD sessions and requirements gathering. I'll argue that many times you can build a prototype of a product or a simulation of a process or service in very little time, and begin to incorporate changes in it faster than you can get people together to define requirements. This approach may take a little more time upfront, but the results will be better and will come faster than in a traditional step by step approach to gathering requirements.
Comments