Solution Pitching has moved...

New posts will appear at www.dangordontech.com

Please visit me there

“Pharaoh's Magicians” and the Business Case Presentation

My last entry was about a character you run across in the business-case pitch setting: Dr. No.

“Pharaoh’s Magicians” are another beast in the menagerie.

Most of us know the story of the Exodus, where Moses led the Hebrew slaves to freedom in the Promised Land.  Great story.

But when Moses first pitched liberation to Pharaoh, he tried to impress Pharaoh with his technology.  He threw down his staff and his staff turned into a snake.

Pharaoh turned to his house magicians, and they said, “Oh, that’s nothing.  We can do that.  In fact we already have.”  And they threw down their staves, which also turned into snakes.

That’s the enemy: an in-house group who not only can do what you can, but have done it already or could do so in two shakes of a lamb’s tail.

What Pharaoh in our business world wants to entrust a new project to an untested outsider when the in-house crew, whose warts, after all, one knows, says they can do the same thing?

That is the basic pitch of Pharaoh’s Magicians: better the devil you know than the devil you don’t.

Unfortunately, it might not be true.  The devil you know may well be worse than the devil you don’t, particularly if the situation calls for agility, nimbleness, or speed.  The in-house magic shop absorbs quite a bit of resources and has a long latency.  Just think of the application backlog in your IT organization.

The Bible tells us the proper response to Pharaoh’s Magicians: Moses’ snake ate the magicians’ snakes.

Best thing: a key benefit that the business organization needs which can only be delivered by your stuff.

“Dr. No” and the Business Case Presentation

If you have ever made a business case within a large organization (in fact, if you have ever tried to make any kind of presentation to a large organization) you will have run across Dr. No.  He or she is everywhere.

When I was a geek working in some large organizations, I would occasionally get called in to presentations, either by fellow geeks or by third parties.

My gut assumption was that I was being called in to sneer at something in the presentation.  Why else would they pull me from my terminal and bring me into a conference room?

I was a Dr. No:

• “No, that won’t work; we tried that three years ago and go nowhere.”
• “No, those guys can’t do it.  They don’t have the right pedigree/headcount/technology stack”
• “No, it can’t be done.  It’s NP-complete/violates the Second Law of Thermodynamics/Moore’s Law”
• “No one wants that.  Our customers are asking for the very opposite.”

(The last one is kind of rich, since no one ever accused geeks of caring too much about customers (although many of us do).)

Dr. No’s are dangerous, because they do have the ear of their management, and it is often the case that management has brought them in, like attorneys, to find problems and flaws.  But they can be neutralized or even won over.

The first order of business is to understand the psychology of the Dr. No.  Why does he assume he is being brought in to sneer?

The main reason is low self-esteem.  She can’t imagine that any exec would have her in a meeting for her opinions.  After all, her opinions are insignificant.  The only possible motive for having her there is to find fault, and the only way to impress the execs is to find every possible flaw.

The situation is complicated by the fact that execs indeed often do want Dr No’s to find fault.  But, like attorneys, they want to find the real flaws, not every possible flaw.  They want, ideally, for Dr. No to exercise some judgment, to give a thumbs-up or a thumbs-down based on the balance of flaws and virtues.  They want, in essence, a business partner with a specialist point of view.

This analysis provides the key to handling the Dr. No: make him feel like the business partner he should be, and he will be an ally instead of an enemy.

Easier said than done, you might say.  But it’s straightforward:

• Excite her (technical) greed.  There is no geek who doesn’t love cool tech stuff.  Get her excited about something in the approach, or, better, let her think that her group or team can do some of the cool stuff in the approach, and you will have won half the battle.
• Treat him as if he were a business partner.  Ask his opinion about the business implications of the idea.  When the exec opines on something, as Dr. No what he thinks or feels about the same thing.  Find something in his background with a business or business-case angle and use that information to slant something his way.  If you’re in the same organization as the Dr. No, this information should be readily knowable.

An adroit combination of these two approaches will have most Dr. No’s (Dr’s No?) eating out of your hand.

Fear and Greed in the “Geek/Suit” Use Case

We have discussed this a bit in posts here and here, but maybe bringing some of the points together will help us understand the fear/greed topic as a whole here.

The main fear for non-geeks in a business-case setting is we will piss away a lot of money on some scheme I don’t understand and it will cost a billion times as much as we thought and take a billion times longer and it still won’t bring about the business results we want.

Cost and time are of course intimately related in a software project and closely coupled in other geek ventures, but some references in the presentation will exacerbate them:

• Advanced technology.  As my old Theory of Computation professor put it, “if you went onto an airplane and they told you they had just replaced all the software on the plane with new versions, wouldn’t you want to get off?”  Nothing excites Fear like bragging about advanced technology, and whereas geeks frequently want to talk about it, it’s the kiss of death in a business-case pitch.  Stress tried-and-true technology.
• Agile.  Any reference to new processes can ignite Fear, but Agile – in big business settings – is sure-fire to do so.  Why?  Because the suits know damn well your team isn’t agile: after all, they work for BigCorp,  don’t they?  The promise of Agile – more control over the project – seems contrived.
• Huge, dispersed, or multi-headed team.  Maybe this ought to excite Fear more than it does, but it is Fearful enough for those who have experienced the miraculous schedule-killing effect of a complex team.
• Multi-year timetable.  The chance that anything will come in on time over multiple years is negligible.

And of course, the Fear-inducers with respect to ultimately getting the right results:

• Working Closely with Sales.  Sales is a fickle project manager.  Sales people are notoriously attracted to Bright Shiny Objects and a business project whose guiding star is some group from Sales, or close coordination with Sales, is doomed to mission creep and an ultimate product with a billion features and no integrity.
• Market Research.  Another Fear-inducer about quality of ultimate results, mainly because it’s hard to find honest helpful market research; most of it acts like a mirror, telling you that you are the fairest in the land.

What Is Not of Interest to Suits (Generally Speaking)

• Discussion of technical risk.  As the sorry story of the Obamacare website debacle unfolds, one can only imagine the yawning, fidgeting with gizmos, and other signs of audience uninterest that greeted the tech team’s feeble attempts to discuss the tech risks of the project at the outset.  Suits hate to hear any details about technical risk: all they want is the geeks’ assurance that tech risk will be manageable and will be managed.
• Discussion of technical merit.  As with risk, so with merit.  Suits don’t want to hear what approaches are preferred, and why.
• Discussion of Schedule/Budget risk.  The one thing that is sacred in the Obamacare discussions is the immovability of the end date.  One of the first big software projects I worked on as a programming professional had a delivery date of April 1.  No one saw – or at least admitted they saw – the irony of a project end date of April Fools’ Day which, as early as January of that year, we all knew was completely unachievable.  Yet we solemnly swore that 4/1 was written in stone until the week before.

All this is quite a change from the investor presentation setting, where most of the questions from potential investors revolve around risk and reward (although here, too, the discussion is almost never very technical).

Is There an Argument for a Framing Slide in a Business Case Pitch to Suits?

In an earlier post on raising money from investors, I argued for the importance of a “framing slide” at the beginning of a presentation to help your audience situate themselves within your pitch.

Is there the same argument for a framing slide in business-case pitch to suits?  And does the slide contain the same bullet points?

Yes, and no.

Yes, a framing slide is good in a pitch like this, and for the same reason: It shows respect for your audience, understanding of what questions will be on their minds at the beginning of your presentation, and a promise to answer those questions.

But, no, the questions on the mind of a business-case audience are not the same as an audience of potential investors.

A group of suits hearing a geek pitch a business case are not generally investing their own money, or even the money of limited partners.  They are spending out of a budget or hearing an argument to lobby for budget.  Therefore the budget and use of funds, although important, is perhaps not as important as the investor pitch.

What business-case investors care most about is:

• Whose turf is affected by the proposed initiative?
• How will that stakeholder benefit or suffer?
• What are the bona fides of the team making the case?
• What argument can be made to my superior in favor of this business case?

(Not an exhaustive list, perhaps, but one that stems from an attempt to get into the mind of the audience.)

The core insight here is that business cases within a large organization have much more to do with turf than with ROI.

Make no mistake, a business-case pitch will need slides on budget and slides on ROI (perhaps lots of them).  But the essential first slide is all about the politics.

Classifying “Suits”: Early Adopters and Early Majority

Geoffrey Moore of “Crossing the Chasm” fame is often misunderstood on the topic of Early Adopters and Early Majority.

Moore actually has three kinds of early customers: Innovators, Early Adopters, and Early Majority.

Most of us confuse Early Adopters with Innovators.  When we meet a visionary customer, we wrongly assume they’re an Early Adopter.

What’s the difference?  Innovators love technology and innovation for its own sake.  They want one of everything to play around with.  Innovators are essentially indifferent to the business value of an innovation.

Early Adopters, on the other hand, care about the business value of innovation.  They are willing to take a risk on an innovative technology approach, but they are doing so as a calculated risk in order to gain a business advantage.  Early Adopters see the business advantage of an innovation and accept the risk of using it in order to reap the business reward.

And, finally, Early Majority customers want to “let Joe drain out the risk.”  They don’t want to take chances with new technology until they believe everyone else is doing it and they are in danger of being left behind if they don’t.  Early Majority customers wish that innovation risk would go away.

Within the organization, then, geeks are likely to comprise mostly Innovators and Early Adopters.  And suits are likely to comprise mostly Early Adopters and Early Majority (as well as Late Majority and Laggards, but those are topics for another day.)

The business value of an innovation and the unvarnished risk associated with it are the two things Early Adopters want to be crystal clear about.

The business value of an innovation and the strong hint that everyone else is already doing it are the two things Early Majority want to be crystal clear about.

It’s possible to speak to both of them in the same pitch, since Early Adopters don’t care what everyone else is doing (much) and Early Majority don’t listen to blah-blah about risk as long as they see others taking the risk.