consulting

A leap of faith

We recently pitched to a prospective client.  We told a story of how we believed their customers would use the new product they had sketched out in the RFP; we told a ‘day in the life’ and brought it to life with illustrations.  We walked through our approach to tackling projects and described our experience on similar engagements.  One of the bid team described his experiences and what the client could expect and we guaranteed that he would be on the project.  We let them have a rate card, and an indication that, comparing what we knew of the project with others that we have successfully delivered, what they indicated they wanted in the RFP was in the range of their budget (which we knew).  We let have them directly relevant references who were ready to take their calls.

What we didn’t do was produce them a project plan, nor a definitive cost.  Given the paucity of information in the RFP there was just not enough to go by; it would be a lie if we came up with a number, there were too many imponderables.  Yet that was what they craved the most.  Most of the questioning was friendly and we answered well, however one question sticks in my mind: “From your presentation, you are asking us for a leap of faith to engage you”.  Well yes, we are.  But is that any different to the way you engage any new contractor?  It is always going to be a leap of faith; even if you engage one of the big trusted brands with an established reputation.  Sainsburys and NHS took a leap of faith when they engaged my old employer Accenture; they probably felt they had done all the necessary due dilligence and were partnering with a proven, reputable organisation, but in those two instances good things did not result.

Do you modify your approach according to context?

I look in the rearview mirror.  Blue lights flashing. Maybe he’s been called out to respond to a call and will overtake me.  No, he’s flashing me.  Instinctly I’ve slowed down, I look at the speedo, it is in KM/H and I’ve not been paying attention to the roadsigns, but it is clear that I’ve been going too fast.  So I pull over.

The question in my mind is what to do next.  I’m in Australia, driving an awesome road, the Great Ocean Road that just asks for a car to be driven (OK, it’s hardly an Grand Tourer, it is a compact Hyundai Getz).  The brain is racing, pumped by adrenaline and fear.   In the UK I would get out of the car, go to the back of it and talk to the officer.  You’ll be asked to do this anyway “Would you kindly step out of the car sir”…  The last time I hired a car overseas was in the US in Atlanta.  Driving through the deep south I got pulled over and I jumped out of the car. Bad move.  “You’re makin’ me kinda nervous’ the cop drawled with his thick southern accent.  He spread me over the ‘hood’ to search me and ended up taking me down to the station, something that was straight out of the Dukes of Hazard, and handed me a huge fine to pay.

So I’m slowing down and thinking do I do the UK thing and jump out, or do the US thing and stay in the car?

I decide to stay in the car.  The right move.

So that’s an interesting story, but what does it have to do with the themes that I usually blog about?  Adapting your approach based upon context.

A while ago I met with the CIO of a company whose core business is in complex instrumentation hardware.  They were looking to diversify their offering, take some of their products out of the hands of specialist practitioners and into the broader marketplace.  Core to the success of these new offerings was usability; their devices required complex set-up and calibration.  Their question; how do you redesign an expert system for novices?

Seeking an answer they hired a customer experience consultancy to gather insights, understand the new segment needs and create wireframes for the new application interface.  But the consultancy couldn’t fit with the way the company worked.  They would run a workshop with the client for a couple of hours then go ‘back to base’ to do the thinking and designing and return to present their designs, well thought out and well polished.  Yet every time they would come back they had got something wrong.  That approach may have worked for a website, but for this complex product they were getting it wrong.

We were asked for our advice.  I started by saying that I thought they should stick with the incumbant,  whilst we would love the business, both parties had invested a lot and learned a lot in the past few months and it would be a folly for us to come in and have to start from scratch.  The answer was to get both sides into the same room, a war room, and thrash out the designs.  Forget about their formal methodology and way of doing things.  If you they were both in the same building they didn’t need that formal staccato present  – review – sign-off process.  They could continually innovate.  That is certainly the way we would do it, yet the CIO thought the incumbent would be resistant to changing their ways.
The theme that joins these two stories?  It’s about reading the situation, knowing the culture and context you are in and adapting your approach and behaviour accordingly.   And that applies as much to agile practitioners as Big Methodology people.  know your audience, understand the context then pick your battles; think big, start small scale fast, remember that change won’t occur overnight.