Don't Wait

One of my customers asked me a common question this week: should I build an automation now that we're planning, or wait until after I've done this other thing that will affect it and then do the automation? The automation in question was between the client management system and payroll, involving a whole bunch of spreadsheets. This setup poses significant business continuity and cybersecurity risks.

However, we were also questioning whether the client management system was fit for purpose. There’s a chance we might build an integration for the current system only to replace it later. Naturally, the concern is whether this would be a waste of money—throwing good money after bad.

Another version of this question involves creating joined-up user experiences around core systems. For example, should I build that joined-up experience around my client management system and my expense management system now? Or, if my client management system might be replaced, should I wait and build it later?

These are essentially the same question with the same answer for the same reason. So, I'll generalise them as: should I build my thing now and adjust it later, or wait and build it then? Anyone who's read my previous articles can probably guess the answer: build it now and adjust it later.

The first reason is that the cost of reworking something isn't as high as you might think. About 80% of the cost of building integrations or joined-up experiences is reusable. The additional cost of making adjustments is only around 20%. For an integration, most of the expense comes from analysing the problem, examining the core systems, and understanding how data flows between them.

While the data formats and structures can change between systems, this is usually a minor part of the coding and thinking challenges. Most of the effort you put into building the integration remains relevant, especially if you're replacing it within a 12-month period. If documented well, it's not as complex as it sounds.

When building a joined-up user experience or interface in a user-first fashion, that experience remains consistent regardless of the system behind the scenes. If you replace a system, like a client management system, it will be with something that has similar flows, data models, and structures. The problem and the experience stay the same; you’re just rewiring that experience to a different backend system later. This task is closer to trivial than to overwhelming.

In my experience, both with integrations and user experiences, the cost of rework is minor compared to what people often think. Many misconceptions arise from using the wrong technologies. When using the right technologies, like serverless solutions and ubiquitous free tools, the effort to rebuild or rework and reintegrate them into different systems is minimal compared to the original work.

My second argument is that even if you end up discarding the code, the benefits are usually realised within a few months. This could be from reducing cyber risks, addressing business continuity risks associated with running things on spreadsheets, or simply improving time efficiencies. The benefits often outweigh the costs of building these integrations and experiences sooner than people expect.

We're focusing on integrations and experiences used frequently, like daily, weekly, or biweekly, or those accessed by large audiences. The more often they’re used and the larger the audience, the quicker the return on investment. This logic applies to any question of whether to do something now or wait to combine tasks for perceived efficiency. In almost every case, doing things now is better. Making a project bigger increases risk, likelihood of failure, and delays business benefits far more than anticipated. Small projects succeed; big projects fail. Therefore, do small things more often and sooner.

Andrew Walker
Technology consulting for charities
https://www.linkedin.com/in/andrew-walker-the-impatient-futurist/