The Actual Problem may be Different from What We Assume it to be

A famous quote – often attributed to Mark Twain – says, “It ain't what you don’t know that gets you into trouble. It's what you know for sure that just ain’t so!”

Most software projects fail because what they produce is not what the end user actually needs. In a conventional waterfall approach, the requirements of the project are gathered, reviewed, signed-off and frozen at the beginning with no revalidation made during the later stages of the project. Unfortunately, very often, the requirements change over a period of time! This results in a solution that may be well-engineered and feature-rich but which fails to address the issue at hand.

In order to create an effective solution, it is critical to first get a good grasp of the actual problem. Nuances of the problem often come to light only upon close investigation as the project makes progress. In more agile design methodologies like Design Thinking, the team continuously validates the problem statement with regular feedback from the end user. The feedback helps in refining not only the solution but also the problem statement at every iteration. This means that only when the end user confirms that a particular iteration solves the problem, the project moves to the next stage.