At every organization I visit, I see people dealing with information in awkward, costly and sometimes terrifying ways. From perverse contortions of Word and Excel, to email servers cluttered with half-edited attachments of the same document, to clunky and expensive groupware that everybody makes excuses to avoid, organizations limp along under conditions that make certain tasks tedious and/or expensive, while simply making others impossible.
Suppose you wanted to tackle these problems. What do you normally do?
If you've tried either of these avenues, I'd like to ask you a question: how'd that work out for you?
I've made a few observations while writing business information infrastructure for the past ten years or so:
Though perhaps the most striking observation is that traditional strategies treat information infrastructure as a capital asset—an acquisition—an entity unto itself. Purveyors of these complex, expensive and fragile systems seem to fail to recognize that your business is the system, and it likely needs little more than to grow some additional connective tissue here and there, rather than risk a multiple organ transplant.
By hiring somebody whose job it is to learn about your organization and write the story of how it goes about its business, in such a way that over time, the story reaches a depth and clarity that can be executed by machine.
The principle underpinning this process is that nobody you hire is going to understand the peculiarities of your organization until one person understands everything. This is because an army of people with less than one complete picture of the system each does not equate to one complete picture. This is a notion called conceptual integrity and it is the most essential component of problem-solving and system design.
When we treat the development of information infrastructure like a construction project, any goal of creating shared understanding, assuming it exists, competes directly for resources with the goal of building the product. This makes the acquisition process opaque and the utility of the result—an all-or-nothing excursion—unclear until well after the business transaction is complete.
Likewise, when the goal is a specific artifact, many important considerations are quickly dismissed as out of scope. For instance, an organization may commission a new website, and the agency they hire might remark privately to themselves about how abysmally their client handles its communications content. Though they won't mention a solution, nor might they even be capable of delivering one. Nor, for that matter, might the client even be interested despite the value of such a consideration, as it lies outside the exclusive purview of creating a website.
When we cast the development of infrastructure as a construction project, we slice arbitrarily across concerns that we aren't even aware are connected. Furthermore, choosing a technical platform too hastily, in the interest of keeping down the cost and time to completion, is just as likely to produce the exact opposite effect. Finally, adding people to a software project does not make results happen any faster, and adding people to a late software project is guaranteed to make it later.
If, however, we make shared understanding the objective, what you get for your money is ultimately an education on what an optimal information infrastructure for your organization would look like, what not to commit to and what information can be safely acted upon right away. This is a job that a single competent and well-connected person can do, part time*, over the course of a month or two for the beginnings of operable results, and for as long afterward as the relationship yields tangible value.
Further, if we put this incremental learning session in the context of information rather than technology, of people rather than computers, it is amenable to understanding what ought to be done without the need to consider specifically how. The process can provide this while at the same time connoting that any technical product that does result is an implementation of some well-understood part of the abstract system, which does no more or less than what is already described in familiar terms. This condition would enable you, the business decision-maker, to form consistent expectations of how otherwise inscrutable parts of your organization ought to behave.
As I mention above, a considerable proportion of the work involved in developing information infrastructure is a one-person job. Or rather, several one-person jobs, for which the next tends not to be obvious until its predecessor is complete. In fact, the ability to delegate confidently—and not just because you have people sitting idle that you want to put to work—is a good indicator that a part of the system is well-understood and easily separated from the rest. But in the interim, what happens if this special person gets hit by a bus?
A convenient litmus test for a goal of shared understanding is that it remains after the agent of that understanding leaves the room, let alone the planet. We achieve this by gelling what we learn into a set of artifacts, which also serve as the currency of progress. By artifact in this case I mean any document, recording or representation that lends itself to the understanding of the system, manicured for easy uptake. If the point is for you to get what's going on, it makes little sense for an agent to hoard or obscure this information. If we create an unbroken line between these documents and those that deal with even the most technical of considerations, then at least they will be amenable to being understood by somebody, and the understanding required to evaluate their performance will always be available to you.
There is one last practical consideration: the composite of capturing results and that of real time on the calendar. No single task in this model exceeds more than a handful of man-hours, but each depends on a great deal of highly-specific input. Thus, while progress may be lumpy, you can be confident that at any point there exists no significant body of information that you do not have in your possession. Moreover, it is realistic to say that at no point would you ever have material outstanding for longer than a few weeks.