Following on Part 1 of this series "solutioneering: does not deliver", it is worth looking at all the different parties that suffer as a result of solutioneering and how the problem manifests itself.
It does not matter whether you are a sales account director, sales manager, sales & marketing director, a potential customer asking for a solution, an IT director trying to buy something or a pre-sales engineer trying to develop a solution specification - every single one of these roles is negatively affected by solutioneering.
It does not matter whether you are a sales account director, sales manager, sales & marketing director, a potential customer asking for a solution, an IT director trying to buy something or a pre-sales engineer trying to develop a solution specification - every single one of these roles is negatively affected by solutioneering.
If you have ever been fortunate enough to have experienced being in one of these roles, you will almost certainly relate to the absolute frustration when a proposal is submitted which does not articulate the solution that you anticipated.
Equally, as a member of the bid team, no matter whether you are the technical sales specialist or the account manager - after you have spent hours and long nights polishing a customer proposal, there is nothing more disheartening when the customer turns around and tells you that the solution is way beyond their budget and you need to shave 25% off the price. Or even worse, they do not have a business case to support what you are proposing - can you please help put one together.....
So what is the real problem that causes these scenarios to play out? Customer expectation not set correctly? Customer requirements have changed?
Some analysis and reflection allows real causes to bubble to the top without offending any one party - it is human nature to help people quickly - identify solutions as soon as possible. Look out for the following symptoms (these are not an exhaustive list - just examples):
- no documentation of requirements
- inability to articulate use cases
- budget envelope is not known
- urgent requirement to discount the solution
- have never met the actual business user with the problem
- vague process to evaluate proposals
- no/vague/flexible implementation deadlines
- no clear success criteria or metrics
Once can go on - but you get the general idea - the actual problem that needs to be solved has not been identified and as a result, the scope for disaster has been multiplied exponentially. The risk of a deal not closing is off the scale at this point, as is the potential for delivering a very unhappy customer into the business. What is always very scary is the fact that quite often nobody will stand up and say - we do not know what the problem is.
So what does this problem ecosystem look like?
Walking through the problem ecosystem, it becomes obvious that it is a combination of symptoms and drivers that result in the unsatisfactory outcome. The solution to the the problem cannot easily be identified because I would argue the root cause is not described on the diagram above.
The real cause of the problem lies right at the start of the product lifecycle and has its roots in poor market needs analysis and investment decision making. In part 3 of this series, I will look what could be the real root causes of this problem and potential options to address them.
Thoughts?
What do you think?
