What do software development and the Titanic have in common? They both hit icebergs! It sounds like a bad joke, but there's an important kernel of truth here.
The software development process, unfortunately, has a predictable pattern. You, as the business leader, meet with software developers and reach agreement on "system requirements." The programmers toil and arrive with the new software and both sides are immediately unhappy. Developers think you change your mind. You think developers don't listen.
What really happens is what I call "the iceberg" phenomenon. Both sides believe they have a meeting of the minds and don't realize that their agreement rests upon a tremendous number of assumptions. You and the developers each understand the words, phrases, and concepts of any requirements document in the context of your own experience and environment. Like an iceberg, the words that are used are the 10% that both sides can see; under the surface lies the 90% that defines their differences and creates the many risks that increase time and cost.
For example, programmers don't know if a particular design will have legal implications or will cause problems for someone in the supply chain. Business professionals are facing time pressures that keep them from providing the tiny details of date formats (12/31/2007 vs 31/12/2007) or country codes which may be critical to the business. On the other hand, I once discovered business professionals phrasing a requirement in a way that was about to cause ten weeks of programming, when the right question reduced the issue to a ten minute text change. That's an iceberg!
So, what's the "sonar" for this problem? Here are four alternatives:
1) Find a translator. If you can, find someone who has worked in both worlds and can serve as the "translator" for both sides.
2) Make everyone a translator. Assign someone to create a "lexicon" - a glossary of terms that are unknown to one side or the other. To avoid definitions filled with new inscrutable terms, ask contributors to check with a twelve year-old to see if the explanation is intelligible.
3) Create ambassadors. When possible,insist that a designer or programmer spend time at the side of the person(s) who will use the system. It's amazing how much the developers can learn through watching the workflow, overhearing an occasional conversation, or a chat at the coffee machine. If they are inalterably offsite, consider collaboration tools, giving people the ability to see and hear as much of the user's current business process as possible.
4) Require an "open" development environment. Remember that the vendor's work is not a surprise Christmas present. Consider the unorthodox approach of keeping the vendor's progress accessible at all times. Rather than waiting for benchmarks, assign someone to regularly view the developer's work. Developers using best practices will have wire diagrams, screen mock-ups, and functioning modules that will allow for course correction long before the code is finished.
I know that everyone is facing business pressure to be somewhere else, doing something else -- usually something that seems more directly relevant to the bottom line. But, I guarantee that time spent with developers while they work will save vastly greater amounts of time and money later.
