The problem when starting with a solution

Coming to the table with a solution bypasses all logical thought. It favours the hippo (highest paid person in the room) or panders to their ego. It's not collaborative, not built upon shared understanding or research and quite often will result in a half baked "solution". Coming to the table with a problem and exploring it with a multi-skilled team will validate your decisions, generate excitement and reduce risk further down the line.

‘The Solution’ and the problem with it.

Solutions themselves are not the issue, they come in a variety of forms and often fix a specific problem. (Hold on to “fix a specific problem” as I’ll come back to that in a minute.)

The pattern I keep seeing, is when I get invited to meetings to discuss the “New Idea”.

This new idea, delivered with enthusiasm, ticks many boxes and is sure to target the right people etc. The next few questions, aimed at me, are “when can we deliver this?” or “this is our highest priority”.

The first question that comes to my mind is usually “Why?”

The second is “What problem are we solving?”

The third is “Who has a vested interest in this project?”

These are simple and obvious questions, but yet it’s too often that these are not thought about. Moreover it’s too often that service teams are expected to not ask them and simply “go and deliver it”.

By asking such questions early you may be seen as contentious or disruptive. However these questions WILL need an answer at some point in the project. If you wait to answer them mid-way through the delivery phase, you will undoubtedly open up a can of worms. Furthermore the perception of the service team changes. Stakeholders now view them as the “bottle neck” where all the problems lie.

Where does the problem actually lie?

There could be many reasons for these issues but for the sake of this article I’m going to focus on one. Problem definition.

In every organisation I have worked in from large corp to agency this has happened. Someone from high up has seen what someone else (normally a competitor) has done and wants to do the same.

This is a Solution-First approach.

This in itself is not a bad thing however seldom does it come with the insights and research that it deserves.

The solution gets passed through the ranks, all of whom are too scared to challenge the idea. And a new project is born with huge gaps ready to fail.

By taking a step back from the solution and defining the problem we get a better insight. You can discover where the true problems lies. Once you understand this you can develop an appropriate solution to tackle it. Additionally you have your first clear objective which can lead:

• Value proposition

• Application definition statements and more…

Defining the problem and creating solutions

I recently read a good article by Tim Maldon about The problem with Design Thinking. There’s lot’s in there but one thing resonated with me.

Bringing people from multi-disciplinary backgrounds into the same room to discuss a problem. Or as he calls it “Full Stack Design Thinking”. I like this idea as it equalises the playing field and allows input from more sources.

Using this collective knowledge isn’t a magical solution. But it will provide a greater perspective and hopefully identify issues and risks earlier.

Once a clear problem is defined the task of creating a solution is more focused.

Where does the responsibility lie?

The responsibility to ensure that projects are defined properly lies with all involved. Those at the top, who drive incoming projects, have the obligation to provide a well defined problem. Allowing focus to solution making.

Those creating solutions need to ensure that ideas are generated using all who have a vested interest in the project. Therefore getting buy-in from all.

Service or deliver teams have accountability too. Their’s is to check that a project meets the right criteria to begin. If not, it’s their responsibility to push back. Have the confidence to say the criteria has not been met. And ensure that the solution is fixing a genuine problem, is well thought out and can be planned with reduced risk.

There are of course a myriad of tiny details which affect and steer a project. I am not saying that this the Golden Goose of solution creation. However these are basics. And it’s important to get basics right, so when problems do happen, and they will, you will be better prepared to solve them.