The Catch-22 for digital projects
Updated: Jun 8
A successful digital initiative begins with having absolute clarity about the problem that needs to be solved.
Regardless of the size of the project, the problem needs to be worth solving. A good problem statement is clear, simple and specific.
Without a clearly defined problem then any solution delivered may not succeed because there was no clarity on what problem the initiative was solving. This may feel like a Catch-22 in complex environments, but there are many reasons this is important, not least of all to ensure the project team is aligned around its goal.
Not only does a well-defined problem statement provide a clear vision for a project or initiative, it also serves as a simple and clear way to communicate the goals of the project to a broader audience and obtain cross-functional support.
Weak problem statement
Our product will be a centralised online destination which is a one-stop-shop for our existing partners and business leads. It replaces several other systems which are difficult to use.
Strong problem statement
Our partner business is worth $250m every year. To understand how our business is performing for them, partners must use more than eight systems to interact with us, each with a different login and user experience. Some of those systems do not provide real-time data and the quality of reporting is poor. These disparate systems also make it challenging to increase business with these partners, an opportunity worth up to $50m annually.
During the delivery phase of an initiative, the problem statement can serve as a True North to keep the whole project team on track, particularly when new ideas creep into the scope.
There are many methods that can be used to create a great problem statement, from Lean Six Sigma to design thinking. I borrowed from both those approaches, as well as my first career as a journalist, to create my approach to defining problem statements.
Ask the questions
Across an organisation, business problems are often seen in differently, so the first step is to get the right people in the room to agree on answers to the following questions. It’s also essential to have suitable representation of the end users in the room, whether they’re customers, partners or internal users. Start with a loose representation of the problem, eg online sales fail to process, then discuss each of the following questions and agree the responses:
Why is this a problem?
Where does it occur (eg, a specific page or location in the sales funnel)
What is impacted? (consider customer, commercial and reputational aspects)
When did it first occur?
What are the symptoms?
How often does it happen?
These may not be easy discussions and it may take several iterations to land on solid answers to each of these questions. But the hard work will be worth it, because it will produce the core components of your problem statement.
A problem statement is just that: A clear articulation of the problem. It should not contain the solution.
A problem statement should allow for measurement of success against specific goals (eg, increasing sales to existing partners by $50m/year).
Finally, and most importantly, once you’re happy with the statement, test it with the people who will use the new or revised product and make sure it reflects their needs and observations.