Discover how implementing ERP systems with strategic 12-month, 3-year and 5-year planning horizons can accelerate ROI and prevent project fatigue.
Most discussion of ERP timing is about how long a project takes. The more consequential question is when to start one, and it gets far less attention despite having a larger effect on what the investment returns.
A project run at the right moment in a business's development delivers value the business can absorb. The same project run too early builds for requirements nobody has yet, and run too late arrives after the business has already paid for the constraint in workarounds and missed information.
This article covers how to judge the right moment, how timing affects return, and the specific timing decisions that sit inside a project once it is under way.
Businesses occasionally implement a full ERP before they need one, usually because somebody anticipated growth that had not yet arrived.
The immediate cost is straightforward. Licensing, implementation and internal effort spent on capability the business does not use.
The subtler cost is configuration built against assumptions. A business that has not yet operated at scale does not know how it will operate at scale, so the design encodes guesses. Those guesses then have to be unpicked once reality arrives, which is more work than configuring correctly the first time.
And there is an organisational cost. A team of fifteen absorbing an enterprise system experiences the process discipline as bureaucracy rather than as structure, because at that size the informal approach genuinely was working. Adoption suffers, and the resulting habits are difficult to correct later.
Being late is more common and the costs accumulate quietly, which is why businesses tolerate it longer than they should.
Manual effort is the visible half. People rekeying between systems, reconciling spreadsheets, producing reports by hand. Each instance is small and the aggregate across a year is substantial.
Decision quality is the larger and less visible half. Businesses operating without reliable, current information make decisions on impressions. That does not feel like a cost because nobody can see the better decision that was not made.
There is also a compounding effect on the project itself. The longer a business runs on inadequate systems, the more workarounds it accumulates, the more data quality degrades, and the more there is to unpick when the implementation finally happens. A project deferred by two years is usually a larger project than it would have been.
And there is opportunity cost, where growth is genuinely constrained because the business cannot take on more volume, more locations or more complexity without something breaking.
Several signals recur among businesses that implemented at roughly the right time.
Systems no longer talk to each other, so the same information is entered more than once. This is the most common trigger and the most quantifiable.
Reporting takes days rather than minutes, and the numbers are assembled rather than produced.
The month end close is getting longer rather than shorter, which usually indicates that the process is compensating for something structural.
Growth is creating problems the business cannot solve by adding people, because the constraint is coordination rather than capacity.
And the business is planning something the current systems cannot support, such as a second entity, another country, a new channel or an acquisition.
One of these on its own is rarely decisive. Three or four together generally means the cost of waiting has already exceeded the cost of acting.
Beyond readiness, the state of the business at the moment of implementation matters more than most plans acknowledge.
An implementation demands sustained attention from senior people. A business in the middle of an acquisition, a funding round, a leadership change or a major market shift does not have that attention available, regardless of what the plan assumes.
The honest test is whether the people who must make the decisions can genuinely be freed. Where the answer is no, the choice is between a longer timeline and a worse outcome, and the plan should say which has been chosen.
Financial capacity matters as well, and not only for the fee. Implementations produce a productivity dip immediately after go live, and a business operating with no headroom feels that dip more acutely and is more likely to abandon parts of the system under pressure.
Every business has a rhythm, and implementing against it is an avoidable difficulty.
Going live during your peak means the system is unfamiliar exactly when the business has least capacity to absorb unfamiliarity. Retailers should not cut over in November. Accounting practices should not cut over during tax season. Construction businesses should not cut over in the middle of a major programme.
The corresponding point is that the quieter period is not merely convenient, it is when people have the attention to learn properly rather than working around the parts they have not understood.
This constrains the calendar more than people expect once you also account for the financial year and partner availability, which is why timing decisions benefit from being made early rather than negotiated late.
For Australian businesses, the first of July is the cleanest point for a financials cutover, because it avoids splitting a financial year across two systems.
Splitting a year is entirely workable and it adds effort. Comparative reporting spans two systems, the audit covers both, and opening balances have to be established mid year rather than falling out naturally.
The trade off is that everyone wants that window, so partner availability is tightest and the project has to be planned well in advance to reach it.
Where the first of July is not achievable, the start of a quarter is the reasonable alternative. Mid month cutovers create reconciliation work that nobody enjoys and that adds no value.
Where payroll is in scope, it carries a separate and stronger timing constraint.
Moving at the end of the payroll year is materially cleaner, because year to date figures reset and the most error prone part of a payroll migration largely disappears.
A mid year payroll move requires year to date figures to migrate accurately, because Single Touch Payroll reporting depends on them. That is entirely achievable and it is real work that needs proper attention rather than being treated as a data load.
Where the overall project timing and the payroll timing conflict, phasing payroll separately is frequently the better answer rather than compromising either.
The return on an ERP investment is a function of when the benefits start relative to when the costs are incurred, which makes timing a financial variable rather than only a practical one.
Implementing at the point where the constraint is genuinely binding means benefits begin immediately, because the manual effort being removed is effort the business is currently expending.
Implementing early means costs are incurred well before the benefits are available, and some of the configuration will need revisiting before it delivers anything.
Implementing late means the business absorbed the cost of the constraint for the intervening period, and that cost does not appear anywhere but is real.
The practical implication is that the question is not whether the business case works in the abstract. It is whether it works starting from now, given what the business is currently spending on workarounds and losing to poor information.
Where scope is broad, phasing changes the shape of the return meaningfully.
A phased approach delivers value earlier, since financials going live in month six starts returning before the operational modules are complete. Total elapsed time is longer and the first benefit arrives sooner.
A single cutover concentrates both cost and benefit. Nothing returns until everything is live, and when it does, the whole scope returns at once.
The right choice depends on how urgent the constraint is. Where one specific problem is costing the business now, phasing to address it first is straightforwardly correct. Where the value depends on modules working together, splitting them delays the benefit rather than accelerating it.
Our piece on comparing implementation approaches covers that decision in more detail.
Timing decisions depend on a realistic view of duration, and the most common planning error is compressing the phases that exist to prevent problems.
Discovery, testing, training and the post go live period are the four that get squeezed, and each squeeze relocates cost rather than removing it. Problems not found in testing are found in production, and training not delivered before go live is delivered as support afterwards at higher cost.
The phases that can genuinely move are scope, historical data volume, deferred reporting and customisation. All four reduce what is delivered at go live without reducing the quality of what is delivered.
Our guide to the NetSuite implementation timeline sets out what drives duration and how to read a proposed schedule.
Sometimes the correct decision is to wait, and making that decision explicitly is better than drifting into it.
Where a significant business change is imminent, such as an acquisition or a restructure, implementing into a shape that is about to change wastes design effort.
Where the key people genuinely cannot be freed, a project run without them produces a system that reflects whoever was available.
Where data is in poor enough condition that cleansing is a project in itself, doing that first frequently shortens the implementation by more than the delay costs.
And where the business does not yet know what it wants the system to do, spending time on that question is cheaper than discovering it during design. That is what advisory and strategy work is for.
A deliberate delay is only useful if the interval is used, and the work available is substantial.
Data cleansing is the clearest, because it is work only your business can do and it directly shortens the migration workstream later.
Process documentation is second, since discovery is faster and more accurate when the business arrives with a first pass already written.
Deciding the dimensional structure and reporting requirements is third, and it is the decision with the longest consequences.
And selecting the partner properly is fourth, since selection done without time pressure produces better outcomes than selection done against a date.
Our piece on preparing from day one covers this work in detail.
One timing decision that is almost always made too late is what happens after go live.
Businesses typically decide about ongoing support several months after cutover, by which point requests have queued, reporting gaps have been filled with spreadsheets, and the trajectory is already set.
Arranging it before go live is considerably more efficient, because whoever provides it absorbs context while the project team is still assembled and the decisions are still fresh.
That is the argument for treating the ongoing arrangement as part of the project timing rather than as a subsequent decision, and managed services covers how that works in practice.
The timing question resolves into two assessments. What is the current constraint costing, in manual effort, in decisions made on poor information and in growth the business cannot take on. And can the business genuinely free the people and attention an implementation requires over the next several months.
Where the first is large and the second is yes, the moment has arrived. Where the second is no, the honest response is to fix that or to plan a longer timeline rather than to proceed and discover the constraint halfway through.
Our approach to NetSuite implementation sets out how we structure projects, and where the question is still whether and when rather than how, advisory and strategy is the right starting point.
If you would like a view on whether now is the right moment for your business, get in touch.
