IBM Maximo Implementation: Realistic Timeline, Phases and Cost

Almost every IBM Maximo proposal I have reviewed from the buyer's side of the table quotes a timeline that assumes everything goes right. The system integrator is not lying. They are quoting the plan that wins the deal, and the plan that wins the deal is the optimistic one. My job here is to hand you a realistic phase-by-phase schedule so you can hold your own line in that meeting, know which weeks are soft, and understand exactly which tasks nobody can do for you.

I write this as someone who has run these projects for 22 years, on both sides. If you want the product context first, start with my introduction to IBM Maximo. This guide assumes you have already decided Maximo is the platform and are now staring at a Gantt chart in a sales deck, trying to work out whether nine months is real or wishful.

Why you need your own timeline

The proposal timeline is a negotiating document. It is built to look achievable and affordable, and it quietly assumes that your organisation will produce clean data on time, release your maintenance supervisors for workshops on demand, and sign off on decisions within days. In my experience none of those three assumptions hold by default. When the project slips, the SI points at the assumptions, and they are usually right to.

So build a counter-plan. Not to be adversarial, but because a schedule anchored to your team's real availability is the only one that survives contact with reality. The rest of this article is that plan: the phases, the weeks, where it actually breaks, and the questions to ask before you sign.

The phases, with weeks attached

Here is a single-site implementation broken into eight phases, with the honest week ranges I use for planning. These overlap in practice. Configuration begins before data migration finishes, integration runs alongside configuration, and training starts while user acceptance testing is still being prepared.

A word on phase 1. Discovery looks cheap on paper and it is where you either set the project up to succeed or quietly wire in its first delay. This is the phase where you decide how work orders will flow, who approves what, how you split reactive from planned, and how the maintenance team actually behaves versus how the manual says they should. If your supervisors are absent from these workshops, the design gets built from assumptions, and you pay for that later in UAT rework. Treat discovery as the most important three weeks in the plan, not the warm-up.

A word on phase 3. Configuration is the part everyone worries about and it is almost never the problem. Maximo is deeply configurable out of the box, and a competent SI will land the standard build inside the window. If you want to understand why staying inside configuration rather than drifting into code is what keeps this phase predictable, read my piece on Maximo configuration versus customisation. The weeks that go wrong are 2 and 4, the data phases. Every extra week of custom code you add here is also a week you inherit at every future upgrade, so scrutinise anything the SI proposes to build rather than configure.

Phase 8 deserves respect too. Go-live is not the finish line, it is the moment the real test starts. Hypercare, the intensive support window right after cutover, is where adoption is won or lost. If technicians hit friction in week one and quietly fall back to paper or their old spreadsheet, the whole investment stalls. Budget genuine on-site presence for those first weeks, not a phone number.

A realistic Gantt view

This is the same single-site schedule drawn out. Notice how much of the calendar the data work occupies, and how the phases overlap rather than running in a neat relay.

Single-site pilot versus multi-site rollout

Be very clear with yourself about which project you are actually buying, because the two have different physics.

Single-site pilot: 4 to 6 months.

One site, one asset register, one set of processes to design and prove. Four months is achievable when your data is already reasonable and your people are available. Six months is the honest number when the asset register needs real cleansing, which it almost always does. If a proposal quotes ten weeks for a first site, that is the number that wins the deal, not the number that survives.

Multi-site rollout: 12 to 18 months.

Once the pilot proves the design, additional sites roll out against a template. This is faster per site but slower overall, because every site brings its own dirty data, its own local process quirks, its own supervisors to release for validation, and its own change-management resistance. Twelve months is a disciplined rollout of a handful of similar sites. Eighteen months is a portfolio of mixed sites across regions. Anything promising a full multi-site estate in under a year is compressing the data and change work into a window it will not fit.

Where the effort actually goes

Here is the split I see on a typical single-site build. The number that surprises most buyers is data. Cleansing, mapping, loading and validating asset and location data is 30 to 40 percent of total project effort, and it is the part the SI cannot do without you.

Read that top row again. If a third or more of the effort is data, and the data is your responsibility, then your team's capacity is the real critical path. A proposal that shows a slim data line and a fat configuration line has the risk in the wrong place, and it will be your budget that absorbs the correction.

Where the schedule actually slips

In two decades I have watched the same two failures repeat, and neither of them is the software.

1. The asset register is not clean and nobody owns it.

The client hands over a spreadsheet exported from a legacy system, or three spreadsheets that disagree with each other, with duplicate assets, missing parents, blank criticality, and location codes that mean something only to one retired engineer. Turning that into a loadable hierarchy is weeks of work, and it is work only your people can validate. The SI can build a loader in days. What they cannot do is tell you whether pump P-4471 is really the same asset as PUMP4471, or which of your 12,000 rows are duplicates. That decision is yours.

2. Maintenance supervisors are never released for the workshops.

The people who know how the work really flows are the same people keeping the plant running, and their day job always wins the calendar fight. Workshops get half-attended, decisions get deferred, sign-offs sit in an inbox, and the design drifts because the people who should shape it are not in the room. This is the single most common cause of slip, and it is entirely within your control to prevent.

The fix for both is the same: build the plan around your people's real availability, not the SI's ideal one. If your supervisors can only give one day a week, the schedule must reflect one day a week. A plan that assumes full-time client availability is a plan designed to slip.

There is a practical move here that saves months. Start the asset register cleansing before the project formally kicks off. You do not need Maximo, a contract, or the SI to begin de-duplicating rows, filling in missing parents, and agreeing a location structure. Every week of data work you complete up front is a week removed from the critical path later. I have seen this single habit turn a six-month pilot into a four-month one, purely because the hardest phase was already half done on day one.

What you cannot delegate

Some tasks look like they should be the implementer's job and are not. These are the responsibilities that stay with you no matter how much you are paying the SI. Get this clear in the contract, because a vague RACI is where the "you never gave us clean data" argument is born six months in.

The three rows at the top are the ones buyers most often assume the SI will handle. They will not, and they should not, because these are business decisions dressed up as data tasks. Cleansing the asset register, ranking criticality, and signing off failure codes are yours. Resource them in your own budget as if they are, because they are the critical path.

Cost, in ranges

I keep cost figures deliberately loose here, because a precise number without your scope, your site count, your integration surface and your licensing model is misleading. What I will say is that the software licence is rarely the dominant line. Services, data work and integration typically outweigh it, and the data effort you just read about is a real budget line, not a rounding error.

A single-site pilot sits at the lower end of the range and a multi-site rollout scales well above it, driven mostly by the number of sites and the state of their data rather than by the licence count. For the full breakdown of what drives the numbers, and where buyers overspend, I keep that discussion in one place rather than repeating figures across articles. Ask me for the current pricing view when we speak, and factor the 30 to 40 percent data effort into whatever number the SI quotes.

Questions to ask before you sign

Take these into the room before the contract is final. The answers tell you whether the proposal is built on reality or on hope.

• How many weeks does your plan allocate to data cleansing, and who is accountable for it? If the answer is thin or vague, the risk is being parked on you silently.
• What client availability does this timeline assume? Get it in writing. Then check it against what your supervisors can actually give.
• Is there a single-site pilot before the rollout? If not, ask why, and be sceptical of the answer.
• What happens to the schedule and price if our asset data is dirtier than assumed? There should be a defined mechanism, not a surprise change request.
• How much of the build is standard configuration versus custom code? More custom code means slower upgrades later; see configuration versus customisation.
• How will we get reporting out on day one? If your KPIs will come through Power BI, plan that early; here is how connecting Power BI to IBM Maximo actually works.
• What does hypercare include, and for how long? The first weeks after go-live decide whether adoption sticks.

For the vendor's own view of the platform and its modules, the canonical references are worth a look:

• IBM Maximo Application Suite
• IBM Maximo documentation

The plan you defend

The optimistic proposal is not a trap, it is a starting position. Meet it with a plan of your own: eight phases with honest week ranges, a data effort budgeted at a third of the total, a pilot before any rollout, and a clear list of the tasks only your team can own. Anchor every date to your people's real availability. If you do that, you walk into the signing meeting knowing which weeks are firm and which are hope, and you are far harder to surprise.