Many organisations have an eclectic mix of software in use with teams, running across the organisation’s various capability groups. These software products range in size, from full stack ERP suites, to a spreadsheet with a fancy macro, that one of the reps wrote ten years ago.
Now, you might think it is easy to see which of those is most valuable. Obviously it’s the one we rolled out to 3000 staff, and handles billions of user interactions, and can be fully customised. It couldn’t be the one that ensures that the 500 strong sales team get the right commission, could it?
Received wisdom is that, if your line of business is not building software, you should not be building software. It makes sense, because at high level, there is a danger of throwing lots of effort into a product, which cannot deliver a decent return on the investment. The danger of this way of thinking is that it polarises the “Buy or build,” debate, and potentially misses out on opportunities.
Preferring the buy option, over building software, is sensible, as it means that the costs and risks are delegated to the vendor . Building too large, a solution, in-house, puts you in a support community of one. However, with the best will in the world, commercial, off the-shelf software will mean compromises in functionality, performance, training, etc. This is a situation that the Chesterfield Principle addresses beautifully.
Very much like the classic furniture of the same name, the Chesterfield principle, promotes a comfortable environment, by using small, tightly scoped products, in harmony with more wide ranging, commercial products, informing the buy, or build debate in this way, transforms the way that CIOs and capability leads, can view their software assets. Suddenly, with proper governance, the macro, mentioned earlier, changes from a potential black hole, into an asset that makes the large software suites even more effective.
The trick to creating a software landscape that resembles the classic Chesterfield, is to understand the cost benefit balance of the software as it changes scope. The large “Cushions,” that are the Commercial products are broad in scope, with the cost/benefit position, usually being established during a procurement exercise. The small “Buttons,” are software produced to address a discrete requirement which would not be cost effective for a “Cushion,” product to achieve.
It is usually easy to find the, “Button,” applications in an organisation. These need to be brought in line with governance, ensuring that they are secure, reliable, and performant. Most important though, is to ensure that scope doesn’t creep, and produce features, better realised in a, “cushion,” product. Getting this right engages the different business capabilities, and produces a lightweight development capability, that is complementary to the business.
The requirement for a lightweight development capability is supportive of better dev-ops for commercial software, and increased ability for other capabilities to procure, and commission software. This is the Chesterfield Principle’s key benefit. It isn’t telling you to choose buy or build. It is telling you to weigh the benefits, and make an informed decision as part of a conscious, “Ideas to life,” process, helping individuals, and teams to be more effective.
