The instruction doesn’t land gently.
Someone, usually well-intentioned, says we need a new ERP. They then pause, as if offering a kindness, and add that it must be done in six months.
At that moment, the experienced CTO does not argue about feasibility. Instead, they ask a quieter question: what does success look like, and what must not break along the way? The answer determines everything that follows.
Six months is not long enough to build the perfect system. However, it is just long enough to put in place a disciplined, survivable one, if you proceed with intent.
1. Start by Narrowing the Problem, Not Expanding It
The most common failure mode appears immediately.
The organisation decides this ERP must fix everything it has ever disliked about operations.
Consequently, scope balloons before anyone has agreed on outcomes.
Instead, the first step is ruthless definition. You must establish, in plain language, what the ERP must do on day one and what it explicitly will not do. Typically, that means agreeing three things:
- Which core processes must run without interruption (finance close, order-to-cash, procure-to-pay).
- Which legacy systems must be retired within six months.
- Which improvements are consciously deferred.
At this stage, ambition must yield to clarity. Importantly, deferring scope is not failure; it is the only way to meet the deadline without institutional damage.
2. Lock Executive Sponsorship Early and Publicly
ERP programmes fail quietly when ownership diffuses.
They fail noisily when accountability remains ambiguous.
Therefore, within the first two weeks, the executive sponsor must be unambiguously named and visibly active. This cannot be delegated to “the business” in the abstract. It must be a single executive who is willing to trade preferences between functions and accept discomfort.
At the same time, you must establish decision rights. Who can say no? Who can break a tie? Who absorbs risk on behalf of the organisation? These decisions feel procedural, yet they determine whether the programme moves or stalls when pressure arrives.
Without this clarity, every later step slows.
3. Choose Speed Over Novelty in Vendor Selection
At six months, the vendor decision is already late.
Accordingly, the selection criteria must favour proven paths rather than theoretical fit. This is not the moment for heavy customisation or vendor courtship rituals. Instead, you should prioritise:
- Solutions with established implementation accelerators.
- Partners who have delivered similar timelines, repeatedly.
- Reference architectures you can adopt rather than debate.
Moreover, resist the temptation to “future-proof” excessively. The future can wait. The deadline cannot.
A good ERP delivered imperfectly on time will outperform an elegant one delivered late every time.
4. Freeze Customisation Before It Freezes You
Customisation kills six-month programmes.
For that reason, you must establish a hard principle early: configuration over custom code, even when users complain. Naturally, they will complain. That is not a signal to change course.
Instead, treat every request for deviation as a risk decision. Ask what breaks if the process changes rather than the system. Often, the honest answer is “comfort” rather than capability.
By month three, this discipline becomes non-negotiable. At that point, late changes compound exponentially and threaten delivery itself.
5. Rebuild Data with Brutal Honesty
Data migration is where optimism goes to die.
Legacy ERP data is rarely clean, current, or complete. Consequently, a six-month timeline demands a decisive approach. You migrate what you need to operate, not what you happen to have.
Practically, this means:
- Freezing data definitions early.
- Cleansing master data with business owners, not IT.
- Running multiple trial migrations to expose problems quickly.
Here, speed comes from realism. If the data is wrong, say so early. Silence only ensures surprise later.
6. Align the Organisation Before Training the System
Training too early wastes time. Training too late creates panic.
Therefore, before any formal training begins, you must align leaders on how work will change. This alignment happens in workshops, not slide decks. Managers must understand how approval flows, reporting lines, and controls will shift.
Once that understanding exists, training becomes reinforcement rather than revelation.
Equally, communications must remain consistent and repetitive. People resist because they fear loss of competence. Acknowledge that fear, and much of the friction dissipates.
7. Govern Progress Weekly, Not Politely
In a six-month programme, governance cannot be ceremonial.
Accordingly, weekly cadence matters. Risks must surface early. Decisions must be made quickly. Slippage must be visible, not softened.
This is where executive sponsorship proves its worth. When trade-offs arise, and they will, the programme must move forward, not wait for consensus.
Progress, in this context, is measured by resolved uncertainty rather than completed tasks.
8. Design Go-Live as a Business Event, Not an IT One
Finally, go-live is not a technical milestone. It is an organisational transition.
Therefore, you must plan for degraded performance, increased support demand, and emotional fatigue. Floors need walking. Leaders need visibility. Problems need prioritisation, not panic.
Critically, you should define what “good enough” looks like for the first month. Stability matters more than optimisation. Confidence matters more than elegance.
When the system holds, trust follows.
Closing Reflection
A six-month ERP is not a transformation but a controlled project.
The CTO’s role is not to promise perfection, but to create a platform that the organisation can stand on without fear. If you narrow scope early, enforce discipline consistently, and lead visibly, six months is enough.
Barely, but enough.
Discover more from Diary Of A CTO
Subscribe to get the latest posts sent to your email.
