Bring me problems not solutions!

Albert Einstein is often quoted as having said ‘If I had one hour to save the world, I would spend fifty-five minutes defining the problem and only five minutes finding the solution’. Since Mr. Einstein was, undoubtedly, a clever man, I’d like to believe that those are his words.

Understand the problem first

Where I work no one seems to care about problems. All I ever hear about are solutions and what to do to make things differently, and hopefully better or right. People even make a point out of the fact that they don’t like problems and therefore don’t care about them much.

Now, one could of course argue that finding solutions and communicating these is better and more productive than finding problems and whining about them. But you should not do one without the other.

We are not after your solutions

Several times a week a general manager, colleague or just plain random person walks by the room where I, and my fellow process managers, hang out and give us solutions.

And we try to embrace these solutions kindly and gently ask ‘what problem does it solve? How will we know that this change will fix anything that’s broken?’

Now, it is appropriate to mention that we are not particularly good at goals and objectives at my company either. If you have clearly-defined goals it is, of course, easier to see the problems that keep you from reaching your goals, therefore you require less effort effort to define these problems.

In many cases problems are about value. At least they are if you, like me, work in the banking industry where all that counts is value. It is probably different if you work in, for instance, healthcare or the military.  If a problem prevents you from gaining value, or if that problem wastes money, you will ensure that you are able to remove it.

PSG (Problem – Solution – Goal)

As one step in the quest to be more effective I decided to write down a few pieces of advice to my coworkers, something to have in mind when talking about problem solving and making improvements. So I put together a one-slide presentation, accompanied by a brief document with my thoughts on the need for a problem definition before starting to think about the solutions. We called it the ‘PSG-model’.

There is, of course, nothing amazing about this. I didn’t invent anything, didn’t have any new bright ideas and I didn’t produce anything original apart from the slide itself. It is merely a simple, common sense method.

But it worked!

The key message was that the solutions are merely the path, and the journey from the problem to the goal. If we don’t have a clear goal, we can use the problem definition (and a sense of ‘right’ or experience, if you will) to define and agree on goals.

We started to turn the solutions presented to us, or the ones we came up with ourselves, into problem definitions. When that had been completed it became notably easier to agree on goals. The solutions we turned to problems without value were discarded, and we managed to swing the mindset at meetings, and our spontaneous walk-ins, to be around problem definitions instead of nifty solutions.

This method became so well accepted that some people apologised when they mentioned solutions during discussions, even though it was perfectly legitimate to do so.

Activity observations

The next step was to create a bit more structure around how we recorded and documented all the problems and goals (former solutions) so that we could act on them and put them to use. A document template was used to guide whoever wrote the problem and goal down, and we purposely left anything regarding solution out of the document. We called them ‘activity observations’.

The time where we actually sat down for a few minutes with the person who came by with a solution also made a big difference to how we were approached all those small enhancements or plain whining of a more personal nature.

I’m certain there are some ITIL abbreviations for what we did and what came out of it. As for now I couldn’t care less, it works and no one can tell me we did it wrong, because we did it our way despite all the prerequisites that form part of this organization.

All and all, we managed to turn the wide plethora of solutions, random ideas and general whining to problem definitions and commonly agreed goals. It has taken us a little further towards valuable IT Service Management.

One thought on “Bring me problems not solutions!”

Comments are closed.