Problem first. Solution second. Always.

It would be fair to suggest that if you can’t define the issue you are trying to solve you can’t possibly arrive at a solution to solve it.

Common sense, right?

However, more often than not we see people focussing on the solution rather than analysing the problem they are trying to solve. We’ve had a lot of initial conversations with client which go like this:

Client: “I have this brilliant idea/business challenge/need/aspiration, and I want to build an app/website/platform/whatever. I’ve written 2 sides of A4, and spoken to my cousin who works in IT and he recommended Ruby on Rails, apparently it’s the fastest thing to build in. Do you guys do Ruby on Rails?”

Us: “Sounds great, and yes we do. We’d love to help, but first can you tell us more about the problem you’re trying to solve and who you’re trying to solve it for.”

Client: “Erm…ok. But how long do you think the solution will take to build, and how much will it cost?”

The client is almost entirely focused on the solution because thinking about solutions is exciting. It feels like progress and they are on the cusp of solving their problem (even though they may not be clear about the intricacies of the problem they are trying to solve).

Inevitably this leads to more problems and a suboptimal solution being delivered.

Don’t race to a solution

Being swept along with this excitement is a bit like choosing the latest shiny two seater sports car as the family transport when you have two kids and two dogs.

Not only will the result not be fit for purpose it will also need you to go out and buy another car which can transport everybody (and the dogs) to fulfil the original objective.

Andrew Pons QsmGE0P2 B8 Unsplash

This race to a solution is most evident in businesses that don’t have the right balance of experience in their IT and change teams and/or lack structured change management.

The result of this is that developers are often involved in conversations too early and start coding too soon. As a result, the discussion rapidly diverts from “How are going to solve this problem and its intricacies” to details about an inappropriate solution which does not even get close to addressing the core objectives and issues

  • “that user interface is completely wrong”
  • “that’s not how we manage orders”
  • “the look and feel is not what we were looking for”

and on and on…

Ever more diversions…

Most frustratingly these diversions continue to take us even further away from answering the core objectives of the project.

The best analogy for this would be to say its like trying to navigate to a destination without knowing your starting point of origin. You may get there in the end but it will take a lot of trial and error, will take longer and burn more resources, and in most instances you will never reach your desired destination.

Given all the above it is no surprise that so many projects fail, fail to deliver, or run over on cost.


How to get it right

Clearly you want your IT project to be a success, so what can you do to ensure it is? Here are the 5 key things you need to consider and be aware of:

1. Start at the end.

Work backwards from the impact you want the project to have and identify the issues you are trying to solve.

One exercise we often use with clients is the press release exercise – imagine this project has been a great success and you have to write the press release for it then literally write it! Then expand it out – pretend you are being interviewed by someone and you have to explain how this project gives you a unique edge, makes your product better or solves the issue you are trying to address.

This serves to focus on what is really important for you and ultimately the users of the tool being developed and what success really looks like.

2. Consider the context.

To get to that point, you have to go through what we call the Discover and Define stages.

Consider the business context of this challenge, what has been tried before, what users think, what others are doing, and what trends there are in the marketplace. This will give you a very broad data set, which you can then refine down into exactly what you need to do, who you’re doing it for, why it matters, and how you will know if you have succeeded.

Do not be tempted to draw assumptions which are not based on hard data and facts. If you do you are only fooling yourself, and if this data is not immediately apparent, then dig deeper!

Dig deeper

3. Maintain healthy suspicion.

Be very suspicious of teams who want to jump into design or code after just one kick-off workshop.

Although the “fail fast” methodology works in some disciplines this is very rarely the case with IT projects as one wrong turn or move (or indeed incorrect assumption) can have massive impact on the overall project as interdependencies between stack choice, design, UIX and reporting all come into play.

Investment in time up front planning and scoping will save you money and heartache and ultimately make sure your project delivers a robust solution to the issues you are trying to address through it. In our experience, this varies from 10-25% of total time.

Often, we see 10-15% of time invested early on, with the remainder of discovery time used at appropriate stages in the project to deep-dive into a specific feature or scenario.

4. Manage risk, ensure certainty.

Use the Discover and Define steps to manage risk – by treating them as standalone projects in their own right.

By doing this you don’t need to commit to a project if there is a lack of certainty or feasibility in the Discover phase.

For example, a client approached us with an idea for a complex project. By the end of the first workshop, we had found enough data for him to decide it wasn’t worth pursuing, and we jointly decided to end the Discover phase there because it was clear that the opportunity wasn’t there. This saved the client money (almost 50k), but more importantly saved them from putting time, effort and resources into an opportunity that was never going to pay off.

5. Balance talent and processes.

When building teams, make sure you have the right talent and processes in place to ensure you protect yourself against the trap of coding too soon.

A balanced team will include experts in business analysis, user experience, project management, testing, and software development.

Crucially, it will include a strong project lead who understand the business case, the constraints, and can unite the delivery team. A balanced process will include a way of deciding whether something is worth doing or not, a way to track progress against an agreed schedule, and a way to make decisions even when there are differing opinions.

Crucially, it will ensure quality and effectiveness of output to avoid low-quality, expensive, never-ending projects.

In Conclusion

Don’t get caught up in the excitement of thinking about or defining solutions too soon. Doing so is a quick path to wasted time, effort, and budget.

Instead use the 5 steps we’ve laid out above to get a clear, unabridged view of the problem at hand and the “exam question” you’re actually answering. With this clarity of understanding in place you’ll provide a clear focus and then build a solution that does exactly what you, your customers and your business need it to.

In need of some help to avoid solution excitement and properly define what’s holding your business back right now? Let’s talk.