In "Innovation Tip: Step Back to Step Forward" Fred Collapy recommends stepping back at regular intervals in the design process. The three things that he recommends stepping back from are:
- a "decision attitude" - instead of just making a decision, make sure that you are asking the correct question and solving the right problem
- users - be concerned less with what they say they want and be concerned more with what they need
- your assumptions - look at the problem with a new set of eyes
The quality and success of any endeavor depends upon its goals and the quality of the problem statement. Does it accurately represent what you are trying to achieve? The correct answer to the wrong question is still the wrong answer. Know what you are trying to achieve first and then formulate the problem statement.
It isn't that users don't know what they want or how to describe it. I feel that the problem, and many times, also the solution, have already been defined by the time that the users, analysts, architects, designers, and engineers are brought onto the project. The process then becomes to discover the requirements for this problem and solution that fit into the predefined timeline and budget constraints. The requirements collected from the users are biased by how they envision themselves doing their job using this new solution.
There are also many other cultural and organizational biases at play. When hard work and long hours are valued by the organization it is unlikely that business process solution will actually streamline and improve efficiency. When people and organizations are paid or rewarded by the hour and that big "S" on their chest there is very little incentive to work less. Whether or not you believe the statement that "a person working 10 hours per week can provide more value than a person working 60 hours per week" shows where your bias lies.
Constraints and assumptions are both important and dangerous. They are important for projects because it is very rare that anything is open ended and meant to apply to every possible condition and situation. They are dangerous because trying to reuse past experiences and tool sets on new projects with new constraints and assumptions can result in unworkable and dangerous answers.
The solution is to be aware of your experience-biased assumptions and engage outsiders with diverse experiences and expertise. Abandon big up-front user requirement collection efforts. Believe me, they become more about form and completeness than timeliness and usefulness. Adopt iterative and incremental discovery-based processes and tools.