There are two ways in which companies often don’t know very much about what they ask for in business software.
The first is this: for any kind of even vaguely standard business software, whether it’s something a company buys off the shelf, commissions someone else to write, modify or develop internally, there exists as much variation in the details of both its use and its construction as they’re used to seeing in more tangible items like punch presses and pickup trucks. But while they’re used to specifying in full detail the functionality they’re looking for in a new truck – we want it to do this, this, and this, but won’t pay more for one that also does that, that, and that – they’re often unaware of the equivalent variations to be found in business software. As a result, often the details they specify themselves or allow to be specified by or a third party are barely more informative than “we need a new pickup truck” would be in a different context.
A knowledgeable consultant can overcome this first problem on a company’s behalf, but the second one is deeper and more insidious. It is this: despite the fact that a company is sure it understands its own business in all its fascinating details, it probably does not understand it in terms that will mean much to the people who will create or sell the company its new software.
What is it that a company must precisely communicate to the people who will try to provide it with the business software it needs?
Buyers must be able to tell software sellers or consultants precisely how their company expects some software system to mesh with how their business operates and works. Buyers have to tell sellers precisely how it will be used and what it will do for the people who will use it: what the people who will use it will get from it that they won’t be able to get without it. And “the people who will use it” fall into three categories:
- The actual users of the software, the people who carry it with them in their toolboxes, as it were;
- The people who won’t touch it as a tool but whose own jobs provide it with the input it needs;
- And the people who, themselves, may not know a thing about it but who nevertheless depend on the information it helps to provide.
A company must never lose sight of the first category, the people who will operate the software itself, but they routinely ignore the other two categories. But without the people who provide the software with essential data, the system won’t work, and without the people who depend on the software’s output in the course of their own jobs, the software has no reason for being. All these people matter a lot, but we rarely think of them all at the same time – much less think of them all together as cooperating in the same business process.
Most companies don’t really understand themselves in a way they can explain to others.
Human nature being what it is engineers tend to think the job is done when the product is designed; sales people tend to think the job is done when the product is sold, and accountants tend to think the job is done when the books of account are accurate and up to date. They almost always know better, of course. Engineers have a pretty good grasp on what the things they design are supposed to do and why it needs to be done, sales people have to know a lot about what makes their product different from someone else’s, and accountants really do understand, that without the rest of the company and what it does, they’d have no numbers to collect and interpret.
But in spite of this knowledge, engineers still speak in the language of engineering, sales people still speak in the language of sales, and accountants still speak in the language of accounting. When, for instance, two sales people get together and one tells the other about their current job, the one told usually understands it – but it’s quite likely that an engineer or an accountant who overheard that conversation would fail to grasp all or even most of what’s being said.
So how is a company supposed to describe itself to people in yet another profession such as, the software trade? How is a software seller or designer or coder supposed to know things about that company that, taken all together, elude the understanding (and even the vocabulary) of every individual who works in it? Yet if a company can’t tell its business software providers (be they internal or external) exactly what it wants from them, the odds of getting it are not good at all.
Are the readers beginning to understand why most software acquisition and implementation projects don’t deliver on a project’s critical expectations, costing companies’ untold dollars along with the negative impact it has on their business?
What we mean when we say most companies don’t really understand themselves.
When we at Adaptive Growth say (as we often do) that most companies don’t really understand themselves, what we mean is that they can rarely describe themselves in terms that will give software providers and consultants an accurate picture of how some software system will be expected to fit into the company as a whole. And it is important to note that until a company learns how to do that, the usability and fitness of the software it acquires will tend to be hit or miss.
This problem is well known, but it’s often misdiagnosed as a mismatch between the technical language of software and the business language of the software consumer. It is no such thing. It is true that the business software consumer doesn’t understand the technical language of the software trade, but that fact really doesn’t matter at all. The company that buys a new pickup truck for business purposes probably doesn’t speak the technical jargon of the automotive industry either, but it knows it doesn’t need to; it is thoroughly familiar with what various types of pickup trucks do and so it is able to explain its needs very clearly in plain English. “Must routinely carry two people and nine-hundred-pound payloads on city streets” is as much of a technical spec as it usually needs to give anyone.
The fact that the same company that easily and successfully describes the truck or the punch press it wants to buy can’t describe its software needs nearly as well has nothing to do with its inability to speak the language of software development. The fact that it can’t describe the software it needs in ordinary business terms has a completely different and very easy-to-miss cause. And that is companies can’t describe the work they need new software to do in plain but detailed business language simply because they’ve never described that work in those terms to themselves.