I began as a programmer. Programmers, in general, read a lot to understand things. They read code, they read books, and they read articles. So, when I started in a sales role, I read a lot - old habits die hard. There's a phrase that has stuck with me from my sales bookworm phase - “Almost no-one buys a drill because they want a drill. They want holes.”
Or, to quote one senior IT executive that I was trying to convince to support a process definition effort - “No-one cares about this. They care about when I'm going to fix their printer”.
Consider this comment from a lead enterprise architect at a multi-billion dollar organization - “every business case I've ever seen has been fictitious”.
In sales, we get asked about help with the business case a lot. In B2B sales, getting your contact to be ready to purchase gets you about 50% along the sales cycle. Then they have to convince their executive suite, who you often have no direct contact with, to move forward.
But here's the thing. You can make a qualitative business case, which says “we will get this benefit, and this benefit, and this benefit”. And, you can make a quantitative business case - “we estimate a 2% time saving per year that translates into the elimination of one FTE from the team”. And when the CIO sees a qualitative business case she says “How much is this worth?” And if you give a quantitative business case she says “and your figures are based on what exactly?”
It's a standard management technique - challenge what is presented to you and see how passionate a defense is mounted. But to an architect, who comes from a background in rigor, such questions are hard to field.
It's a problem that is applicable to anyone in a corporate environment, not just someone trying to get budget for a modeling tool. “Everyone sells in some way at some point” is a cliché, but it's a cliché because it's basically true.
Recently I've been trialing a different approach that may be more familiar to architects, and give them the framework to make their sales case more effectively.
One area of EA modeling is motivation models. ArchiMate and TOGAF have their motivation extensions, there's also the Business Motivation Model from the OMG, and Nick Malik's more comprehensive EBMM. I won't spend a post arguing the merits of each of these; people with bigger brains than mine are better qualified for that. What's more important is a common feature of each, and how it can help me sell iServer, and my clients sell their programs.
Specifically, a motivation model traces down from high-level drivers to low-level, actionable requirements. If we look at the motivation model below, we can see how we trace through from a couple of business drivers, to goals, to specific requirements.
So how does this help us sell? It clearly articulates the narrative. “The company wants to ensure compliance with regulations.”
So, we need to control access to data, and track the regulation against IT operations. How do we do this?
We map the process tasks to the data objects and use attributes to track sensitive data such as PHI. At the same time, we map regulations to the processes, applications and data that they affect.
A lot of selling, and by extension getting buy-in, is by expressing a logical narrative. But sometimes it can be difficult to guide your audience through the chain of logic that you had in mind. So far I’m finding using a motivation model to be a useful aid with this.