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.

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.

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.

• 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).