As a kid back in the early seventies I often visited my father’s office at his private practice as a physician in the small seaside community where I grew up. I even worked for him on occasion, including one whole summer when I was 15. Dad’s private office, where he consulted with his patients and dictated patient notes for transcription, was tastefully decorated with an assortment of medical and Oriental antiques along with other odd curios.
Now, as an adult many (many) years later, I can still remember one particular item which seemed almost out of place amidst the antiques.
Surrounded by a dozen or so framed medical diplomas and board certificates hanging on the wood-paneled wall behind his desk, hung an 8 x 10 framed photograph of a rather cross-eyed Siamese cat wearing a comical and somewhat perplexed expression. I used to think of it as a “dizzy kitten face”. (Those familiar with Siamese cats probably know what I’m talking about.)
The caption beneath the photograph read, “Doctor, don’t give me what I ask for, give me what I need!“
That rubric stuck with me over the years, following me decades later into my career as a project manager. It came to represent (for me) a paradoxical ethos of project management and business analysis which I, my project teams and my customers have wrestled with over the past twenty years: How to give the customer what they need – and also give them what they want.
I came to learn through long and hard experience that these two things are not always the same and in fact may often conflict.
Project teams are often faced with the challenge of delivering our customers a solution they need, only to meet opposition because the customer has come to the table with a preconceived (and different) notion of what they want. Perhaps it is the latest technology or trend. Or a confusing amalgamation of requirements borne out of a chaotic “design-by-committee” process. Or something they thought they heard the sales guy tell them (a whole other topic for another day).
I’m sure most of you have enjoyed some variation of this humorous (and somewhat vintage) project management meme.
The wooden swing on the left (what the customer asked for) would be virtually unusable, except maybe to a skilled contortionist who wouldn’t mind a few splinters.
The tire swing on the right, while maybe not sounding impressive or sexy to the customer, would effectively and economically meet their needs.
As a project team makes their way through people, processes and product to understand their customer’s business and provide (we hope) a suitable solution, they often encounter the dilemma of the customer not distinguishing the difference between what they want and what they actually need. So, the challenge becomes figuring out how to do this diplomatically and productively, particularly what our customer wants flies in the face of what they’re ultimately trying to accomplish.
Talk about a paradoxical dilemma which pretty much steps on the old adage, “the customer is always right”. Salespeople favor this concept – project managers, not so much. And for good reason.
What’s often needed is the ability and willingness to stand firm during the analysis and design process in order to increase the chances of arriving at a positive project outcome. You might think of it as a form of business “tough love”. Because make no mistake, categorically giving in to what the customer wants, without diligently assessing what they truly need (and possibly having to stand firm on that point) could end up in project failure when the realization hits, even early in the “build” stage, that what was fought so hard for won’t actually meet the need.
At the very least such a realization could end up derailing the project, devolving into exhaustive reviews of requirements documentation, meeting notes and other project and contract documents, accompanied by inevitable finger-pointing, effectively bringing everything to a grinding halt.
All that being said, we all know who will ultimately shoulder the responsibility for the negative outcome, right, wrong or indifferent. Because in the end the customer will stand on the grounds that the vendor was their consultant, and it was the vendor’s responsibility to deliver a solution that would meet their needs.
And in that regard the customer would be right.
If a physician were to cave into his or her patient’s demands, discounting risks and reason, and the patient’s condition worsened, or (banish the thought!) the patient died, in the end who would be held accountable?
Exactly. And rightly so. We all still remember a certain celebrity’s tragic ending when he pressured his doctor into giving him what he wanted – and we all know that outcome.
So, this dilemma remains something for all project stakeholders to seriously ponder – if you haven’t already. Customers and vendors alike, do not discount the need to question and possibly hold your ground on whether what is being asked for is, in fact, what is truly needed for the customer to be successful in their business objectives.
Isn’t that the goal after all?
Have you encountered this challenge on a project? What were some of the ways you approached the discussion of “want vs. need” with your customers or stakeholders?