Blog

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…

The CIO of a mid-sized European insurer pulled me into a call last quarter with a problem most buyers only notice when it is too late. Her ServiceNow ITSM build had been signed at €620,000 and she was now staring at change requests that put the final number closer to €960,000. The work itself was not bad. The platform was being built competently. What she wanted to know was whether the overrun was normal or whether she had been set up. I read the SOW and the seven change orders. The answer was not flattering to her partner, but it was also not unusual. The original price was honest about the visible scope and silent about the predictable cost drivers that every experienced ServiceNow practitioner knows will surface inside the first six months. Those drivers were not surprises. They were a pricing strategy. And once you know what they look like, you can take 30 to 40 percent off most mid-market proposals before the kickoff meeting. This post walks through the eight specific line items that quietly inflate ServiceNow consulting costs, what each one really should cost, and how to write them into the SOW so you are not negotiating from a position of weakness later.

It is 03:11 on a Tuesday and a payroll controller in Vienna is on the bridge call. Net pay for a thousand employees did not post. The ServiceNow major incident is open, severity 1, and the integration team is already pulling logs from three different systems. The ServiceNow ticket says SAP HR returned a 500. The SAP basis team says the iDoc never arrived. The SuccessFactors admin says the delta export ran clean at midnight. Forty minutes in, somebody finally notices that the integration user account on the ServiceNow side rotated its credential at 02:00 and nobody updated the Concur and SAP mid-server connections. Resolution time, end to end, is over four hours. The actual fix took eleven minutes. That is the gap between mean time to detect and mean time to resolve, and it is almost never a tooling problem. It is an integration design problem. Most mid-market ServiceNow customers I work with already have a respectable ITSM practice. They have priority matrices, they have a CAB, they have a problem management process that someone actually runs. What they do not have is integration architecture that helps the on-call engineer figure out what broke in less than half an hour. Their…

A head of IT operations at a European retailer called me on a Saturday night last quarter. Their checkout flow had been intermittent for ninety minutes, the store was three days from a public earnings update, and the war-room bridge had eighteen people on it. Six of them were vendors. Two were lawyers. Nobody was running the call. The incident commander had been pulled into a separate executive bridge to brief the CFO and had not returned. The bridge had drifted into a roundtable of vendors describing what their own monitoring did and did not show. The retailer’s ServiceNow major incident management process had a beautiful page in the runbook describing the bridge etiquette. None of it was happening. This is the part of ServiceNow major incident management that nobody puts in the demo. The platform handles the workflow plumbing well. It opens the major incident record, it pages the commander, it sets the comms cadence, it logs the timeline. What it cannot do, and what nine in ten implementations get wrong, is the operating model around the workflow. The war room is a human process running on top of a technical record. If the human process is not designed, the technical record…

A procurement lead at a German logistics company forwarded me three SOWs last week and asked which one to sign. The scopes were almost identical. ITSM, a light HRSD wave, around 800 employees, two integrations. The timelines were five months, seven months, and eleven months. The pricing roughly tracked the timeline, which is what made him nervous. He wanted to know whether the five-month vendor was a hero or a liar, and he wanted to know it before he committed his name to the contract. The honest answer is that you cannot tell from the SOW. You can only tell by pressure-testing the plan the vendor will not put on the slide. There are five questions that separate a vendor who has actually delivered a ServiceNow implementation timeline in your size segment from one who is selling you a number that exists only in a sales spreadsheet. None of them are about the platform. All of them are about the parts of the project the vendor would prefer you did not look at too closely. Every mid-market ServiceNow proposal arrives with a Gantt chart. The Gantt chart shows phases stacked on top of each other in a tidy waterfall. Discovery, design, build, test, deploy, hypercare. The phases have…

A head of IT at a 600-person logistics company sent me a partner shortlist last month. Three names on it. One was a global SI everyone in his industry uses. The other two were positioned as boutique ServiceNow consulting firms, both around forty people, both with the standard set of badges on the website. He had asked all three for a scoping call and walked away from those calls more confused than when he started. Every firm said the same things. Every firm had the same case studies on rotation. Every firm claimed they would “act as a true partner, not a vendor.” He wanted to know how to tell which one would actually deliver. This is the question that has replaced “do we need ServiceNow.” Mid-market buyers have figured out that the Big 4 model breaks badly at their scale. They have read the LinkedIn posts about rotating consultants and offshore deflection. They are now looking for an alternative. The problem is that “boutique” has become a marketing label, not a structural reality. Plenty of small firms operate the Big 4 playbook in a smaller wrapper. Picking the wrong one costs you the same money and the same time.

A CIO at a European insurer called me last month with a problem that is becoming familiar. They had switched on Now Assist for ITSM eight months earlier, paid for the SKU, sat through the keynote demos, and asked their service desk leads to “use the AI.” The dashboard told them adoption was high. The MTTR numbers had barely moved. Customer satisfaction was flat. Two of the agents were quietly turning the summarisation feature off because it kept hallucinating the wrong impacted CIs into resolution notes. The CIO did not want a vendor pitch. He wanted to know which Now Assist features actually pay for themselves on a real instance, and which ones the platform team should leave alone until the next release. That conversation is the post. Most ServiceNow customers I work with treat Now Assist the way they treated Predictive Intelligence in 2019. They flip the toggles, run a demo for the steering committee, and assume that because the model produces output, the output is valuable. It is the same mistake people made with chatbots in 2017. The output looks confident. The screenshots are great. Whether anyone is actually faster or more accurate is a separate question, and almost nobody…

The CIO of a 700-person logistics company in Antwerp called me on a Monday in March. She had a signed proposal from a Big 4 partner sitting on her desk, two years of work priced at €1.4 million, and a queasy feeling that something was off. Her IT director had pushed for it. The board wanted ServiceNow. The procurement team wanted a “safe” name on the contract. But the proposal had 64 pages, eight workstreams, twelve named roles, and not a single hour of work that was going to happen before month four. She wanted to know if she was about to make a mistake. She was. Not because the Big 4 firm was incompetent. Because the proposal was built for a company three times her size. That is the trap mid-sized enterprises walk into over and over when they go looking for ServiceNow consulting services for mid-sized enterprises and end up shopping at firms whose entire delivery model assumes a 5,000-seat customer with a global PMO. The mid-market sits in an awkward zone. You are big enough that the platform genuinely solves problems for you. Ticket volumes are real. HR cases are real. Asset sprawl is real. Audit pressure is real. You are not big enough to absorb a six-figure project…

Last quarter I sat in a budget review with a CIO and his CFO at a mid-market industrial group. The CIO had built a thirty-slide ServiceNow business case. Process automation, self-service portal, AI triage, modern UX, vendor consolidation. The CFO listened for about four minutes, then put down his pen. “Tell me which of these numbers gets smaller next year and by how much.” The CIO did not have an answer. He had benefits. He did not have a number the finance function could put into a forecast and defend at audit. The deal stalled for six months. When it eventually got signed it was for a third of the original scope. That CFO is not unusual. He is the modal CFO in mid-market Europe right now, and he is the person who actually decides whether ServiceNow gets bought.

A platform owner at a German logistics group called me on a Monday morning in March. Their ITSM go-live had slipped from January to April, then April to June. The Big 4 partner running the build had cycled through four lead consultants in seven months. The latest one had been on the platform for nine days. The steering committee had a board update on the Thursday and the CIO wanted to know whether they should walk. That conversation is more common than people admit. The decision to switch ServiceNow partner mid-project gets framed as nuclear, and most CIOs delay it for one or two quarters longer than they should. The cost of the delay is almost always larger than the cost of the switch. The trick is doing the switch without setting fire to the work that already exists, and without paying for the same scope twice. The pattern is consistent. A Big 4 or top-tier SI wins the bid on the strength of brand, references, and a named partner who shows up to the pitch. The build starts and the named partner disappears within four weeks. The actual delivery team is junior, often offshore, often rotating. The platform architect role is staffed at 0.3 FTE by someone covering three other…