I remember my first job like it was yesterday. I worked for a BI consulting firm called InPhase Software Ltd. I got the job during my university holiday by writing a letter to all the local companies and including a CV. I got 3 replies, 2 interviews, and 1 job. I worked for an enigmatic salesman called Robert Hobbs, who had just won Entrepreneur of the year award.
They had co-innovated on a really neat Data Warehouse product which allowed Business Scorecarding right the way down to line item analysis, with an Analytics capability in the middle. And before the age of 18 I’d been involved in Data Warehouse implementations at BP, Barclays, Booker and some 10 or more other FTSE100 customers.
And I remember the day that Robert came to me with the business requirements for a new customer and I looked at him, incredulous. I said “Robert, you know that can’t be done with our product.” – His reply: “John, I know you can do it”. He was right.
The Delivery Perspective
I’m sure this story is something that a lot of consultants can relate to: salespeople creating unreasonable demands that push the product we have available to us beyond its limits. They can see the commission at the end of the tunnel and they ignore whether or not it is actually deliverable, because they get paid on the sale, right? They take their pay check and move onto the next sales organisation, with no empathy for the poor delivery consultants who have to implement the mess they sold.
The Sales Perspective
The salesperson on the other hand, is sick of delivery consultants putting a spanner in the sales process. They often have a pessimistic approach caused by the experience of other projects gone wrong. Their estimates are always worst case and take into account a number of risk factors which may or may not be true.
Then the delivery consultants usually estimate from the bottom up, building pyramids of cost which make sense at a granular level, but which add up to far more effort than is required. Even worse, when estimating effort, delivery consultants often assume that the person delivering the work may be weaker than them and adjust the estimates accordingly.
And the reality is that many problems – especially technical problems – can be worked through with a quality delivery team and excellent governance processes. This was my experience at InPhase and the technical problems that I thought were impossible to fix, turned out to be very tolerable – with some design changes.
The Pre-sales Middle Ground
In the Pre-sales process we have to attempt to ride the middle ground between these two points of view, and this can be incredibly difficult. In addition we have to not be too worried about the detail of implementation – it’s just not possible to know every detail when we make an estimate, and we often make assumptions to protect against this lack of detail.
I tend to adjust estimates based on what I know about the nature of the consultant doing the estimate. I have been known to triple the estimates of optimistic consultants and third the estimates of pessimists. This makes up for an estimate deviance of 900% for the same piece of work. And I think this is common in the market – and it’s no wonder that the salespeople and delivery consultants are often at loggerheads.
Dealing with Product
This is exacerbated in the Enterprise IT world because we have products to take into account. The pre-sales consultant (usually a Solution Architect) has to decide what the appropriate tool to use for the job is – and how much it can reasonably be changed or customised.
The reason this is usually a problem is because a software vendor is usually also pushing product into the same account. Their point of view may be different to the consulting organisation and their product knowledge may also be different. And clearly there is a conflict of interests between a consulting organisation trying to push services, and a software company trying to push product.
How do we find a way forward?
The only way that this can work is when the consulting and software vendors work together and get a joint vision. In this process the software vendor has to realise that their product won’t always be fit for purpose, and the consulting vendor has to realise that sometimes making a product fit isn’t straightforward and may require some compromise.
Then we have to bear in mind that in an estimation process there are basically 3 variables: Scope, Roles & Responsibilities and Assumptions. It’s only reasonable – if you can agree those three variables with the customer – to vary those variables so that they give the lowest possible price. What clearly isn’t reasonable is to vary those when you know they won’t be true, with a view to artificially lower the price – although it is sadly common practice, especially in Enterprise IT.
And even within that, the respective pre-sales consultants have to be willing to push the technology envelope and realise that resourcing great people to a project and having the right governance process, is what really brings success.
As I sometimes say (and it only really works in British English) – it’s not the tools which make a project fail, but rather the tools using the tools.