When is a project finished? For most of us, it seems pretty simple: when we ship the product or launch the service. But we need to take a step back and consider what “done” really means.
Most teams in business work to create a defined output. But just because we’ve finished making a thing doesn’t mean that thing is going to create economic value for us. If we want to talk about success, we need to talk about outcomes, not just outputs. And as the world continues to digitize and almost every product and service becomes more driven by (or at least integrated with) software, this need grows even stronger.
For example, we may ask a vendor to create a website for us. Our goal might be to sell more of our products online. The vendor can make the website, deliver it on time and on budget, and even make it beautiful to look at and easy to use, but it may not achieve our goal, which is to sell more of our products online. The website is the output. The project may be “done.” But if the outcome — selling more products — hasn’t been achieved, then we have not been successful.
Most companies manage projects in terms of outputs, not outcomes. This means that most companies are settling for “done” rather than doing the hard work of targeting success.
In some situations these ideas are the same thing or have such a clear, well-understood relationship that they might as well be the same thing. This is frequently the case in industrial production. Because of the way industrial products are designed and engineered, you know that when your production line is spitting out Model T cars, you can be reasonably certain they will work as designed. And because of years of sales history, you can be reasonably certain that you will be successful: You will sell roughly the number of cars you expected to. Managers working in this context can be forgiven for thinking that their job is simply to finish making something.
With software, however, the relationship between we’ve finished building it and it has the effect we intended is much less clear. Will our newly redesigned website actually encourage sharing, for example, or will the redesign have unintended consequences? It’s very difficult to know without building and testing the system. And, in contrast to industrial production, we’re not making many instances of one product. Instead, we’re creating a single system — or a set of interconnected systems that behave as one system — and we are often in the position of not knowing whether the thing we’re making will work as planned until we’re done.
This problem of uncertainty, combined with the nature of software, means that managing our projects in terms of outputs is simply not an effective strategy in the digital world. And yet our management culture and tools are set up to work in terms of outputs.
The old cliché in marketing is true: Customers don’t want a quarter-inch drill. They want a quarter-inch hole. In other words, they care about the end result, and don’t really care about the means. The same is true of managers: They don’t care how they achieve their business goals; they just want to achieve them.
In the world of digital products and services, uncertainty becomes an important player and breaks the link between the quarter-inch drill and the quarter-inch hole. Some managers try to overcome the problems caused by uncertainty by planning in increasingly greater detail. This is the impulse that leads to detailed requirements and specification documents, but, as we’ve come to understand, this tactic rarely works in software.
It turns out that this problem — the way our plans are disrupted by uncertainty, and the fallacy of responding with ever-more-detailed plans — is something that military commanders have understood for hundreds (if not thousands) of years. They’ve developed a system of military leadership called mission command, an alternative to rigid systems of leadership that specify in great detail what troops should do in battle.