What Happens When Projects Go Off Track?

I've worked on somewhere between 40 and 50 Workday implementations over the last nine or ten years. I can count on one hand the ones that finished on time and on budget.

That isn't because the people were bad at their jobs. Most of them were smart, committed and genuinely wanted the project to work. Projects go off track for quieter reasons, and almost always earlier than anyone admits.

Here's what it actually looks like, using one project I'll never forget.

It starts with a great kickoff

We were implementing Workday at a large university on the West Coast. The CIO had brought Workday into his previous organization, so he wasn't just supportive, he was a champion. The kickoff was energizing. We walked through the timeline, set the rules of play and agreed on a vision: whenever there was a conflict or a question about which approach to take, we'd go back to that vision and the priorities everyone signed up for.

Everything looked right.

The first warning sign showed up in week two

The week after kickoff, I could already see it wasn't going to be smooth.

Nobody had addressed backfill.

The university had bought a platform worth millions a year, and the implementation itself was worth millions more. But the most critical piece, their people, hadn't been planned for. The same staff who already had full-time day jobs were now expected to work with consultants almost full time on mission-critical tasks: gathering documents, filling data templates, answering configuration questions and shaping the system around how the institution really works.

No one had asked the obvious question: when are they supposed to do all of this?

How the slip actually happens

The first missed deadlines were small. A template a day or two late. A document that didn't arrive. But in an implementation, a day or two late on an input is never just a day or two late. Consultants can't move forward without it, and every downstream milestone, smoke testing, end-to-end testing, payroll parallel, starts to move with it.

Leadership found out quickly, which surprised no one. We ran status calls with the project manager and every division, walking through what was essentially a souped-up spreadsheet: the item, the owner, the due date. Most items were either not done or stuck on an open question that had gotten lost somewhere across email and a dozen other tools. Maybe the message really was missed. Maybe the person just never had time to get to it. Either way, it was late.

The response was the one I've heard on almost every project: "Okay, just get it to us by this new date and we'll catch up."

That's exactly where the real damage begins. The person now spends their limited time catching up on the old task, which means the next task, the one that should have had their attention, loses priority too. One late item quietly steals time from the next. It becomes a chain reaction, and by week two we were already behind in a way that's very hard to recover from.

The cost: three delayed go-lives

Payroll made it worse. You can't go live on payroll whenever you like. Most organizations aim for specific cycles, often the end of December so the first January paycheck runs on the new system. Miss the window and you wait for the next one.

This university pushed its go-live three times.

Every delay meant running two systems at once: keeping an old, heavily customized PeopleSoft environment alive while still building Workday. Double the effort, from the same exhausted people.

And there was a subtler cost. Payroll needs a lot of configuration and a lot of decisions, and the processes underneath weren't clearly defined. Without a clear picture of the goal and the procedures that support it, every configuration session turned into a menu of possibilities. When nobody can point to "this is how we want it to work," teams default to how they've always worked. Over-customization creeps in, and the new platform slowly gets bent back into the shape of the old one. The whole point of moving to a new system is to leave old habits behind, not rebuild them somewhere more expensive.

The human cost nobody puts in the budget

This is the part that rarely shows up in a project post-mortem. I've seen people cry on these projects. I've seen people shout, and I've seen people quit between phases. When you ask someone to do two full-time jobs for months, morale doesn't just dip. It breaks.

And backfill, the thing that could have prevented a lot of it, often never even appears on the risk register. Consulting firms should be explaining this upfront. Some do. Many don't, maybe because it adds cost to the deal, maybe because it's an uncomfortable conversation. But staying quiet about it doesn't make the cost go away. It just moves it onto your people.

The fix everyone reaches for, and why it doesn't work

When a project slips, the instinct is to add more check-ins. More status calls, more touchpoints, sometimes several in the same day.

In my experience this mostly creates anxiety. The honest answer people give on those calls is: "Sorry, between this meeting and the last one I didn't have time to actually do anything." More meetings don't create progress. They consume the very time people needed to make progress.

What I'd do differently in week one

If I could go back to the start of that project, here's what I'd put in place.

• Define what "finished" really looks like. Not "Workday is live," but what life looks like once it's working. For a finance team, maybe that means closing the books in an hour instead of one or two weeks. A concrete finish line gives every later decision something to be measured against.
• Break the finish line into components, and put a name on each one. What has to be true to get there? Who owns each piece? Granular ownership is what turns a vision into work people can actually do.
• Document the new way of working from day one. People will leave, change roles or move to the next project. If the new methodology is written down as it's built, it doesn't walk out the door with the people who designed it.
• Actively hunt for what you don't know. Most project risk isn't hidden because people are careless. It's hidden because nobody thought to ask. Backfill is the perfect example. Ask early and often: "Given what we're trying to do, what are we missing that could hurt us?"
• Keep status and risk in one place. When the goal, the owners, the procedures and the current status live in one hub instead of across emails, spreadsheets and chat threads, problems surface on day two instead of week two. People with day jobs can see exactly what's needed from them and get back to work.

The bottom line

Projects rarely blow up in one dramatic moment. They drift, one late template and one "we'll catch up" at a time, while everyone is working hard. By the time the slip is obvious, you're already paying for it in delayed go-lives, duplicate systems and burnt-out people.

The projects that stay on track aren't the ones with the most meetings. They're the ones that know exactly what finished looks like, know who owns each piece, write down how the work gets done, and look for risk before it finds them.

That gap between the plan and what's actually happening is the problem we started stratbox to solve. But whatever tools you use, start with the questions above. Your people will thank you.