When operations become difficult, it is tempting to imagine a complete transformation: one new platform, redesigned processes and every team working from the same system. That vision can be useful, especially when core systems are no longer fit for purpose. It can also create a project so broad that benefits remain distant while cost, complexity and uncertainty increase.
Focused automations offer another path. They target a clear source of friction, improve it and use the result to guide the next decision. This does not mean thinking small. It means building capability in practical stages while keeping the larger operating model in view.
Why giant projects become difficult
Large transformation projects combine many kinds of change. Technology, data, process, roles, reporting and customer communication may all shift together. Each area introduces decisions and dependencies. A delay in data preparation can affect testing, while an unresolved process question can change system requirements. The project may remain busy without delivering useful improvement to daily work.
The time between planning and real-world use also creates risk. Assumptions made at the beginning may no longer be accurate when the solution reaches users. Teams can change, priorities can move and customer expectations can develop. Detailed planning is important, but it cannot replace learning from a working process in the hands of the people who use it.
- Broad scope creates connected delays and decisions.
- Benefits may arrive long after costs begin.
- Early assumptions can age before users test them.
What small automation does well
A focused automation starts with a specific outcome, such as reducing lead response time, improving document collection or removing repeated status updates. Its boundaries are easier to understand, the people affected can be involved directly and the result can be evaluated against a visible baseline. This shortens the distance between an idea and useful evidence.
Small improvements can also build organisational confidence. Teams learn how to describe processes, prepare information and manage exceptions. Leadership gains a clearer understanding of where automation creates value. These capabilities make future work faster and more reliable. A sequence of focused projects can therefore become a deliberate transformation rather than a collection of unrelated fixes.
- A narrow outcome is easier to test and measure.
- Teams gain experience without carrying excessive risk.
- Each result provides evidence for the next investment.
Avoid creating a patchwork
Small projects are not automatically good projects. If each automation is chosen in isolation, the business may create more disconnection. Several workflows might store the same customer details differently or send overlapping notifications. Local improvements can shift effort to another team instead of removing it from the end-to-end process.
Use a shared set of design principles to keep focused work aligned. Decide where important records belong, how processes should identify customers and how exceptions should be handled. Maintain a simple view of the main systems and the information moving between them. This provides enough structure to connect each automation to a coherent operating model without requiring the entire model to be built first.
- Define an authoritative source for important data.
- Use consistent identifiers, statuses and ownership rules.
- Check the effect on the full process, not one team alone.
Know when broader change is necessary
Some problems cannot be solved responsibly through isolated automation. A failing core system, severely inconsistent data or a process shaped by outdated policy may require broader redesign. If every small improvement depends on replacing the same underlying platform, continuing to patch around it can waste time and deepen complexity.
The decision should be based on evidence rather than ambition. Assess the cost of the current problem, the number of affected workflows, the quality of available information and the business's capacity to manage change. Even within a broad programme, delivery can still be organised into useful stages. A large destination does not require a single high-risk leap.
- Broader change may be needed when core foundations are failing.
- Evaluate organisational capacity as carefully as technical need.
- Deliver large programmes through usable, measurable stages.
Questions people ask
Frequently asked questions
01Are small automations better than a full transformation project?
Small automations are often useful when the business wants faster learning, lower risk and measurable improvement in a specific workflow. A broader transformation may be necessary when core systems or shared processes require coordinated replacement.
02Can several small automations create more complexity?
Yes, if they are developed without shared standards, ownership or a view of the wider operating model. Each improvement should fit a clear architecture so that useful local changes do not become another disconnected patchwork.
03When should a business choose a larger transformation programme?
A larger programme may be appropriate when several critical processes depend on the same outdated foundation or cannot be improved independently. The business should also have the capacity, leadership and evidence needed to manage sustained change.
The useful bit
Three things to carry forward
- 01Focused automations reduce risk and create faster operational learning.
- 02A shared architecture prevents small improvements from becoming a disconnected patchwork.
- 03Choose programme size according to evidence, dependencies and the business's capacity for change.