Blog

A COO at a 900-person medtech firm called me in early July. Their ServiceNow ITSM rollout had gone live in February. The partner shook hands, delivered the last training webinar, and demobilised the team. By June the platform owner had two hundred open change requests in her personal backlog, an incident queue that nobody trusted, and a steering committee that had stopped meeting because there was nothing left to steer. On paper the implementation was a success. In practice she was six months into what she now recognised was the real project, and she had no partner in the room to help her run it. That gap is the single most damaging feature of how ServiceNow consulting services for mid-sized enterprises are usually sold and delivered. The industry contracts, prices, and pitches around the implementation. It leaves the twelve months after go-live to be figured out later. In the enterprise segment that gap is filled by a large managed services contract with the same firm that built the platform. In the mid-market it usually gets filled by silence, and the silence has a cost.

A CIO at a €900m distribution business called me two weeks ago, three months before her Big 4 managed services contract came up for renewal. She was not angry. She was tired. Her team had lived through eighteen months of a ServiceNow rollout under a top-tier firm and the platform worked. Tickets flowed. Reports ran. The board was mostly satisfied. What she wanted to understand was why every meaningful decision felt slower than it should, and why the people she saw at kickoff had all rotated off the account by month four. I have had a version of this conversation four times this year. The pattern is consistent enough that it stopped being a coincidence and became a structural observation about how large firms sell ServiceNow work, and what that structure prevents them from delivering. The point of this post is not to argue that a Big 4 firm can never do good ServiceNow work. Plenty of them do. It is to be honest about the trade-offs baked into the Big 4 delivery model on the ServiceNow platform, and about the specific situations where a boutique ServiceNow consulting partner is not just cheaper but structurally better.

An operations director at a €600m industrial group called me last week. Two years into a ServiceNow ITSM programme. The board had approved the business case on the strength of a slide that promised 30 percent MTTR reduction, 20 percent fewer P1 incidents, and a payback under eighteen months. Now the CFO wanted to know why the finance team could not find those numbers anywhere in the actuals. I have had that conversation more times than I care to count. The answer is almost always the same. The ServiceNow ITSM benefits that make it into a business case are not the same benefits that show up on a P&L twelve months later. Some of the promised numbers are real but got captured in the wrong line item. Some were measured against a baseline nobody bothered to lock down before go-live. And a handful were pure fiction from the outset, borrowed from a vendor slide that nobody in operations ever validated. If you are a CFO, an ops director, or a service owner reading this because someone is about to ask you to defend or extend a ServiceNow investment, this post is for you. I am going to walk through which ITSM benefits actually land, which ones evaporate on contact with real reporting, and…

A CIO at a listed European retailer sent me a two-line email last month. “We know we need to switch ServiceNow partner. The CFO wants a business case. Can you help me build one that survives the audit committee?” That is the question I get most often now. Not “should we switch” but “how do we defend the switch in a boardroom where the incumbent has a fifteen-year relationship with the CEO and the audit chair remembers signing the master services agreement in 2019.” The technical case for switching is usually the easy part. Any competent platform owner can list the defects, the slippage and the OOTB literacy gaps. What breaks in the boardroom is the financial narrative. When the current partner is a globally recognised name, the CFO’s default position is that a switch introduces risk, not that staying does. Reversing that intuition requires numbers, not adjectives. This piece is the framework I use with clients who need to build the case for a switch that will hold up under adversarial scrutiny from a procurement director, a group auditor and a non-executive with a long memory.

The head of IT operations at a Central European bank called me last autumn with a complaint I have heard so often I now expect it. His team had spent nine months and roughly €180k building out ServiceNow Performance Analytics. Sixty-two dashboards, four hundred and eleven indicators, weekly scorecards emailed to the executive committee. The complaint was that nobody read any of it. The CFO admitted in a steering committee that he had not opened a single one. The COO opened them for the first fifteen seconds of the executive meeting and then asked her assistant to summarise. The CEO had never logged in. This is not a technology problem. Performance Analytics does everything it says on the tin. The problem is that most ServiceNow Performance Analytics deployments confuse producing metrics with producing decisions, and executives at the top of a business are only interested in the second one. If your dashboards are being ignored, the fix is not a nicer visualisation library or a bigger screen in the boardroom. The fix is admitting that the reports you built were designed for the analyst who built them, not for the person who was supposed to act on them.

A CIO at a Central European insurance group called me in April with a very short question. Her ServiceNow programme had been signed off at €1.2 million eighteen months earlier. The current actual spend was €2.1 million. The platform was live in ITSM only, roughly half the original scope, and her CFO wanted an explanation before he approved another cent. She wanted to know whether her partner had ripped her off, whether her team had failed her, or whether this was just what a ServiceNow build looks like in the real world. The honest answer, which took me three days of reading her contracts and change notes to give her, is that it was all three at once, and none of the individual causes were dramatic enough to notice while the project was running. That is the pattern I see in almost every conversation about ServiceNow consulting costs. The headline day rate and the signed statement of work almost never predict the final invoice, because the money that kills the budget is not on either document. It shows up quietly in change notes, environment fees, extension weeks, and the specific overtime the buyer pays their own people to compensate for the partner’s assumptions.

A programme director at a European insurance group called me on a Tuesday morning. Their ServiceNow ITSM rollout had been running for four months. The SOW said six months to production. Every weekly status report for the first three months had shown green. Then, in weeks fourteen and fifteen, three things happened in quick succession. The vendor’s lead architect rolled off to another project. UAT started and immediately surfaced eighty-seven defects the vendor said were “expected.” And the security team, brought in late, said the ACL model needed to be redesigned before go-live could be approved. The status report was still green when he opened it. He was calling because he already knew it was not. This is the conversation I have every few weeks now. Somebody halfway through a ServiceNow implementation timeline realises the plan they signed off in kickoff has quietly stopped being the plan they are on. The vendor has not raised a red flag. The steering committee has not asked hard questions. But the trajectory is wrong, and the person calling me can feel it in their bones before the numbers confirm it. This post is for them.

A CIO of a 1,200-person insurance broker sent me his RFP last week. Twenty-eight pages. Seventeen scoring dimensions. A weighted matrix that would not have looked out of place at a defence procurement office. He wanted an outside opinion before he sent it out to five shortlisted partners. I read it on the train home from Vienna and called him the next morning. I told him the RFP was excellent, thorough, and would almost certainly help him pick the wrong partner. He was quiet for a moment and then asked what I meant. What I meant is that the RFP was optimised for the wrong buyer. It was a scale-down of the RFP a Fortune 100 uses to buy from a Big 4. It scored partners on things that matter when you are running a hundred-million-euro programme with three parallel workstreams and a dedicated PMO. It scored almost none of the things that determine whether a mid-market ServiceNow implementation actually ships on time and gets adopted after go-live. If you sit in the 300 to 3,000 employee band and you are about to send a ServiceNow RFP into the market, the evaluation criteria you use to sort responses will decide the next two years of your platform’s life. This is not the same…

A CIO at a €300M industrial firm rang me last month. He’d just finished a bake-off between two Deloitte practices and one boutique shop, and he wanted a sanity check before signing. The Deloitte proposal came in at €1.4M for a phase-one ITSM and CMDB rollout across three regions. The boutique quote was €480k for the same scope, with fewer bodies but named senior architects on every workstream. His board was pushing him toward Deloitte. His gut said the boutique. He asked me to help him think it through honestly. I don’t sell against the Big 4 by default. I’ve watched boutique shops blow deadlines just as badly as Accenture, and I’ve watched Deloitte crews save a floundering programme that a specialist SI had already botched. The question “should I hire a big four firm or a specialist SI” doesn’t have a universal answer. It has a set of conditions, and the sensible thing is to walk through them before signing anything. There are scenarios where a Big 4 practice is genuinely the right call, and pretending otherwise is dishonest.

A CFO at a European industrial group rang me last month, two weeks before her board meeting. She had approved a ServiceNow programme a year earlier, the platform was live, IT was telling her it was working, and she needed to stand up in front of the board and say something defensible about the money. Her problem was not that the programme had failed. Her problem was that the benefits tracker her PMO had built told her almost nothing she could take to the board with a straight face. It listed licence savings that had not yet materialised, productivity gains measured in hours per engineer per week, and a general sense that things were better. None of that survives a board meeting. I asked her what she had actually been sold twelve months earlier. She read the executive summary of the business case back to me. It was well written and it was the wrong document to be measuring against, because it had been written to be approved, not to be verified. That is the pattern I see in eight out of ten mid-market ServiceNow programmes. The people who wrote the case are not the same people who now need to defend it, and the benefits that were promised are not the benefits that show up first,…

A CTO at a European insurance group called me in April. Their HRSD and ITSM programme with a Big 4 partner was seven months into an eleven-month plan. Two lifecycle events were live. The rest were slipping a sprint every sprint. The named architect had rotated out in February. The replacement had rotated out in March. The programme board had already extended twice. The CTO had made the internal decision to switch servicenow partner three weeks earlier, but nobody in his team knew how to actually do it without the platform going dark in the transition. That is where most of these conversations start. Not with the decision. With the mechanics. The warning signs are the easy part. Every mid-market leader I speak with can list them once they see the pattern. The hard part is the transition itself, because a partner change mid-project has moving parts that a fresh implementation does not. There is a half-finished data model. There is a live production instance carrying real user load. There is an update set graveyard nobody has documented. There is a managed service contract with an exit clause that reads like a hostage note. And there is a business sponsor who wants to know, on one…

A regional hospital group in Central Europe brought me in last autumn. Their HR director opened the call with a number that stuck with me: forty-two days. That was the average time from a signed offer letter to a new nurse actually treating patients. Forty-two days of paid salary, empty scrubs in the locker room, and a ward manager covering shifts because the new hire could not log into the medication system, had no ID badge, and had not completed the mandatory infection-control module. They had ServiceNow HRSD. They had spent close to two hundred thousand euros with a larger implementation partner. And forty-two days was actually an improvement on where they started. This is the pattern I see every time I get pulled into HRSD for healthcare. The platform is fine. The base implementation is competent. What is missing is the honest acknowledgement that a hospital is not a bank, not a manufacturer, not a shared-services back office. Onboarding a clinician is not the same problem as onboarding a business analyst, and the moment you pretend otherwise, your HR case templates start bleeding time and money.

A procurement lead at a European logistics group forwarded me two proposals last month and asked which one would cost her less. On paper the answer was obvious. The Big 4 firm had quoted €780,000 fixed-fee for an ITSM and CMDB rollout across four regions. A boutique competitor had quoted €95 per hour on a time-and-materials basis with an estimated 4,200 hours of effort, which comes out to €399,000. Same scope, same target timeline, same platform version. She wanted to sign the boutique quote and be done with it. I told her to sign neither yet, because both numbers were misleading in different ways. That conversation is a decent place to start any honest discussion of ServiceNow consulting costs, because the pricing model shapes almost every downstream number more than the day rate does. Fixed-fee and time-and-materials are not just two ways to pay for the same work. They are two completely different risk-allocation contracts, and the one that ends up cheaper is almost never the one that looks cheaper on the cover page.

A platform owner at a European insurer called me on a Tuesday morning with a question that sounded simple. He wanted to know why his change advisory board kept approving changes to CIs that had been decommissioned eighteen months ago. His CMDB said the servers were live. Discovery said the servers were live. The datacentre said the servers were scrap. Somebody was lying, and the board was signing off on ghosts. I told him this was not really a data problem. It was an ownership problem wearing a data costume. His CMDB had four different teams contributing records, no product owner, no reconciliation rules that anyone could name out loud, and a Discovery schedule that had last been tuned in 2022. The result was exactly what you would expect. A large expensive table full of half-truths that nobody trusted enough to use for a decision and nobody owned enough to fix. This is the pattern I see almost every time a mid-market or enterprise buyer asks for ServiceNow CMDB data quality services. The instinct is to reach for a tool, a bulk cleanup script, a consultant with a checklist. What is actually needed is a product mindset. A CMDB is not a database. It is a product with users, a…

A COO at a European industrial group called me last month. Their internal PMO had just presented the ServiceNow implementation timeline for a global ITSM rollout. Eight weeks. That was the number on the slide. Eight weeks from kickoff to production, three business units, four thousand users. The board had already approved it. He wanted a second opinion before the signature dried. I told him the truth. Eight weeks was not a timeline. It was a wish. And the person who signed off on that number was either new to the platform or under pressure to say yes to something impossible. The real question is not how fast you can implement ServiceNow. It is how much you are prepared to sacrifice to hit an arbitrary date. This is the conversation that keeps happening. Buyers ask how long does it take to implement ServiceNow, they get a confident answer from a sales engineer, and six months later they are calling someone like me to clean up the mess. The typical timeline for a full ServiceNow deployment is not a secret. It is just uncomfortable to say out loud when a competitor is pitching half of it.

A platform owner at a mid-market insurer called me last month, frustrated. Her change failure rate had crept from a respectable 4 percent up to 11 percent over two quarters. Her CAB met every Tuesday at 11am, fifteen people on the call, agenda stuffed with thirty to forty changes, most of them rubber-stamped in ninety seconds each. She wanted to know if there was a feature in ServiceNow she had missed. Some smart workflow, some AI risk-scoring add-on, something the platform could do that her team was not using. There was, of course. But the feature was not the problem. The problem was that her CAB had stopped being a control and started being a ceremony. Every implementation I have ever audited that produced creeping change failure rates had the same underlying issue, and it was almost never a missing module. It was discipline. Change management on ServiceNow works exactly as well as the human process you wrap around it, and most mid-market organisations have let that human process rot quietly while they kept upgrading the platform.

A VP of Operations at a 350-person SaaS company asked me a question last week that nobody asks on the first call. He had read enough LinkedIn posts about the Big 4 pyramid to be cautious, and he was ready to choose a smaller firm. What he wanted to know was different. “If I sign with a boutique,” he said, “what does day fourteen look like? What does day sixty look like? Tell me what is actually happening inside the engagement, not what the slide says.” That is the right question, and it is the one almost nobody answers honestly during a pitch. The boutique versus Big 4 debate has been ground down to slogans. Specialist SI versus pyramid. Senior delivery versus offshore deflection. Fixed-fee versus time-and-materials. All of those things are real, but they are descriptions of the wrapper, not the actual mechanics inside the engagement. If you are a mid-market buyer trying to decide between a global integrator and a smaller specialist, what you want to understand is what happens on a Tuesday afternoon in week three. That is what this post is about.

An ops director at an 800-person logistics company called me last month. Their executive team had just signed a three-year ServiceNow contract. The implementation partner, a top-tier global SI, had pitched a twelve-month programme with a workstream lead, two architects, four developers, a business analyst, a PMO, and a part-time engagement director. The blended day rate was the kind of number you only say out loud in a small room. Halfway through month three the company had a tidy steering committee, a Jira board the size of a small city, two PowerPoints titled “Future State Vision”, and exactly zero working catalog items in production. The director was not angry. He was tired. He said the same thing I hear from every mid-market buyer who has been burned once. “We are not a Fortune 500. We do not need a programme. We need somebody to build the thing.” That gap, between what mid-sized enterprises actually need and what large SIs sell them, is the entire reason boutique ServiceNow consulting exists. If you sit in the 200 to 2,000 employee band, with revenue somewhere between fifty million and a billion, and you are looking at servicenow consulting services mid-sized enterprises…

A head of IT operations at a Hungarian logistics group rang me in May after his first full quarter on ServiceNow. He was confused, which is a good problem to have. The CFO had asked him for a benefits readout and he could not figure out which numbers to lead with. The platform was working. The team felt it was working. But the financial story did not match the operational story. Tickets were down, escalations were down, his Tuesday morning incident review had collapsed from forty minutes to eight, and yet the savings line his finance team had put in the business case had not moved in any measurable way. This is the part of a ServiceNow rollout nobody warns you about. The real benefits of using ServiceNow show up in the operations room first, weeks or months before they show up in a finance system. If you do not know what to look for in those first few weeks, you spend the whole year trying to defend a benefits case that was written for the wrong audience. A business case is written before anyone has used the platform. It has to be defensible, which means it has to be conservative, which means it almost always points at the wrong column to measure. The columns the case picks are…

A CIO at a 900-person specialty chemicals group rang me at the end of May. Their ITSM and HRSD rollout with a top-tier global SI had been live for fourteen months. The build was technically finished. The managed service contract that followed it was not finished, and it was not working. Tickets to the partner were taking eleven days to acknowledge. The named delivery lead they had been promised was sharing his time across nine accounts. Half the change requests came back with quotes higher than the original implementation rate card. The CIO knew something was wrong and could not put it on a slide for the audit committee. He wanted a calibration call. We spent forty minutes on it. By the end he had the eight signals he needed and a number he could defend. The decision to switch ServiceNow partner is almost never made on time. The signals show up months before the move happens, and most leadership teams sit on them because the alternative feels worse than the status quo. It is not. The cost of staying with a partner who is mis-delivering is larger than the cost of moving, and the gap widens every month. The question is not whether to switch. The question is whether you can see the…