Neil Sparrow, Managing Consultant, Altis London
When I started my career as a technical guy I firmly believed that “problem solving” in the realms of “technical” i.e implementing a specific system vs “soft skills” such as business analysis were worlds apart.
Over the last decade, working in mixed projects covering both aspects, I have changed my view. Both “soft skills” and “technical” work require exactly the same approach!
Let me explain…
My starting point for any piece of work is an “actionable outcome”. What is the required outcome from this work? What will this actually enable us to do differently? – An outcome which provides no potential actions has limited value.
This is often where “soft skills” type work can seem different to “technical”. Within a technical project it is easy to see that a system of some kind, using infrastructure and other resources will be the output. With a “soft skills” project it is all too easy for such work to become a “talking shop” with limited outputs or actionable activities identified.
How do we avoid this pitfall?
The solution in my experience is to use exactly the same methodology as we would with a “technical” project, starting with the idea that the quality of any output is purely dependent on identifying the right problem(s). To get to the right problem we need to ask the right questions!
Taking the systems analogy we might ask a client the high level question – what do you need the system to do? Then we drill into the details of the specification, size, shape, throughput etc. Once we have this more detailed spec we look for candidate systems/solutions.
A “soft skills” based business analysis project can follow the same approach. Let’s take the example of “we would like to make our organization more efficient”. This would be the high level question equivalent to our system question of “we need a new system”.
Now we drill down. OK, so what currently is happening means you are not as efficient as you believe you could be? This then becomes the detail part of our requirements specification. The important part of this is correctly identifying the causes of inefficiency. Most people when asked to identify a problem or inefficiency will identify the outcome of the problem, not the cause. Often the manifestation of an issue or inefficiency can be upstream of other processes or teams which the person raising may not have any visibility of.
So our role here is to ask the right questions. We need to facilitate our end users to firstly identify the problem and then find the root cause, not simply identify the manifestation of the problem. Once we have the true cause of the issue we can then move onto identifying actionable change which will make a real world difference to the organization.
Whether a “soft skills” or “technical” project, they both succeed or fail on the quality of the upfront analysis. Resources internal to an organization already know the answers to the problems, but perhaps lack the ability to have an end to end view or find it difficult to articulate problems.
As consultants I like to think that we don’t need to have the right answers at the start of an engagement. We just need to have the right questions. Our role is to facilitate the journey from identifying the manifestation of the problem, tracking it back to the true source and then work with clients to come up with possible solutions.
“Soft skills” or “technical”, it’s all about getting an actionable outcome… and that requires the right questions to be asked.
