I recently wrote a guide on the 8 biggest mistakes organisations 
make when integrating new technology and designed a project success model to avoid those mistakes. Both are available for free from www.fusiontech-consulting.com.
However, in this article I want to focus on the biggest culprit of them all. This particular culprit results in organisations:
It’s simple to avoid, yet organisations don’t. The culprit?
Diving into Solution Mode Instead of Scoping
An organisation identifies an inefficiency in one of their departments and challenges them to find a solution. The first thing most people will do is to start looking for solutions. Once a potential solution has been found, try to figure out if it’s a fit, or, if they need to go out and search for a new solution. Sound familiar?
This is the most complicated and time-consuming way to create new efficiencies and solve problems. And, it often results in getting side tracked from the original requirements. So, why is it so common? Why do we insist that this is the approach to take?
Simple, finding solutions is fun, scoping is considered boring. As well as that, most organisations are driven by performance and recognition, so if you find a solution you will receive praise and it will be reflected in your performance review. Naturally, this creates a competition mentality so in a way it becomes a race to finding the solution.
The irony is that the fastest way to finding the right solution, isn’t the fastest way to finding “a” solution.
Can you think of a time when you thought you found the perfect solution and half way through the integration process the project started revealing regulations, restrictions, challenges, requirements that you weren’t aware of when you selected that solution? And, you quickly realised that you may not have selected the best solution after all?
Truth is, even with a thorough scope there is a possibility that you will come across unforeseen obstacles, but correctly scoping will drastically reduce them, especially the major ones.
Let’s go back to the original scenario, an organisation has identified an inefficiency or problem that needs solving. All that information gives you is what the end result needs to fix (target), it doesn’t however give you the pathway to your target. Which means, you still don’t know:
With a long list like that it starts becoming obvious why a thorough scope upfront is so critical, and how important it is not to rush it to ensure all the ins and outs are covered.
Step 1 Client: I always start a scope by having a meeting with the client to identify what they really want, what the end result needs to achieve and how it is measured, who the solution impacts, budget, and any restrictions, regulations or exclusions they may be aware of. The purpose of this is to ensure I actually know the problem I am solving and avoid getting side tracked by ambiguity.
Step 2 Stakeholders: Meet with key stakeholders to identify any restrictions and regulations from their end. These stakeholders could include IT, finance, sponsors, head of departments etc. The people who need to sign-off at the end and whose toes I don’t want to step on by mistake.
Step 3 Process Map: Meet with the people who will be impacted by the solution. This is where you go into the detail, so the best thing to do is set aside a day or even a week to process map. Identify what today looks like and the challenges that are being faced with the current workflow, use this information and the information gathered in Step 1 and 2 to find a new, real fit solution and what that new process would look like. Does your new solution meet all your requirements? Is it user-friendly? Does it fall within budget?
Let’s take a look.
The scope should always the first thing on your list, towards the end of your scope it will merge with Solve & Test which is a cycle until the best solution has been found but that’s for another article.