“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.