Last week, I started telling you about our approach to creating solutions for our clients. A key portion of what we do is to create an IT system – in our case an Asset Management system. But that is only one part of our “Solution”. When we talk about solutions, we’re talking about creating a result that solves our client’s problems.
Sounds like Marketing text, right? I know. But over the years, we’ve found that there are key pieces that make up a Solution. The most critical of these often reside outside of any IT system or tool. They are the Definition and Transition components of our Solutions.
- Definition: You need to understand the problem to effectively create a solution.
- Transition: Once the solution is ready, it will never solve any problems unless it is successfully transitioned into use.
This week, we’ll focus on the Definition side. Definition has two main goals: understand the client and problem and ensure all involved agree on the solution.
Understanding the Client & Problem
Frequently, people are quick to define a solution before really knowing what the problem is. That might resolve a symptom of the problem – like the arm pain in that old joke. But that doesn’t necessarily solve the problem.
The first thing that we try to do is understand the client themselves. This helps us to better determine the true problem to be solved (not just symptoms) and it helps us to understand the best approach to successfully standing up a system in this particular client’s environment. These are the things that we make sure we understand first:
What’s their mission? What are they trying to accomplish in their business? Systems like ours support the operation of businesses – but they are not typically the main source of revenue or achievement of our clients. It is critical that you understand what their main priority is so your impact on it is only a positive one.
What are they doing now? Rarely are we brought in when there is a brand new requirement. Usually, we’re going into an organization whose existing systems and processes aren’t working. So the first step is to walk through their current processes. It’s also important to review how they got to those processes. A lot of constraints can reveal themselves in those discussions. This brings us to the final question:
What are their constraints? There are usually rules/requirements/constraints that our clients have to live by. Here are some examples we go through with our Assets clients:
– Inventory must be conducted monthly
– All assets with values over X must be stored in a secured location
– There is no network coverage in the storage facilities
– Only personnel with a specific security clearance can handle certain items
It is really important that you understand what these are before trying to define an overall solution – because neglecting one can spell the difference between success or failure.
Throughout the course of these discussions, reviews, and research, the problem eventually identifies itself. And in many cases, it doesn’t look like what the client initially thought it would be. What this also does is to identify what is the best approach to ensuring that what we recommend is going to actually solve their problem. Ultimately that is why we’re there – to solve their problem.
Agreement on Approach
A lot of what we do throughout our Definition work is research and educate. While we conduct our research, we’re also educating the client about what some of their options are – and in many cases, they are then getting a stronger understanding of the reality of their own operations. We keep frequent communications throughout this process so that we continually ensure agreement across all involved as to what the problem truly is – and what is the best way to solve that problem.
Why Do this?
We’ve had many clients initially balk at spending the time it takes to get to true understanding and agreement. It’s not surprising that in the IT systems world, budgets of Define work are frequently cut first.
It has been our experience that skimping on these activities usually adds to costs later in the project (think: extensive scope change). A bigger problem is that shortcutting Define can actually set up a solution to fail. Because let’s be honest, if the “solution” created doesn’t address all of the factors that enable it to work in the environment/support the mission/fit with _______ needs – the solution will fail. And whether it’s cost overruns – or worse, a failed project – either way you have a very unhappy client whose problem still needs to be solved.
When clients would want to shortcut Define, a frequent quote of our founding partners comes to mind: “there’s never time to do it right, but there’s always time to do it over”.
As I mentioned earlier, Definition is just one part of success. Next week, I’ll talk about another critical component: Transition.
In the meantime, I’d love to hear about your approach to Define? What have you run into in your business?
