The situation
The client's legacy Salesforce workflows were built in a format being retired, so they had to be rebuilt in custom Apex code before year-end. There was no room to move the deadline.
I joined the project two weeks before the end of the year. It was already about three weeks behind, and with the company-wide winter break, only two developers could work on it. I was the only project manager. Everyone was frustrated: the client's executives, their IT team, the people who used the system every day, and our own developers.
What I found
The developers weren't the problem. The client had never supplied information the build depended on, and the earlier tracking and communication let that gap go unnoticed. The team was waiting on answers nobody was chasing.
That changed the job. With 200+ workflows, two developers and two weeks, finishing everything wasn't realistic, and pushing the developers harder wouldn't close a requirements gap. I needed the client's answers fast, a shared decision on what mattered most, and every remaining hour spent on that work.
The recovery plan
- Made answering easy. I built a simple, easy-answer requirements template so the client could fill the gaps without decoding technical questions. We also asked them to survey every user to learn which functionality mattered most. The template came back within 24 hours, but only three or four users were surveyed. Instead of waiting for a perfect answer, we prioritized with the input we had and kept moving.
- Reset priorities with the client. In a reprioritization meeting, we agreed which workflows were business-critical for launch and which could follow after the new year.
- Aligned the developers on release order. With two developers, release order was everything. The team built against the agreed list, so every remaining hour went to workflows that had to launch.
- Communicated twice a day. Every day started with an opening update and ended with a closing update, with decisions and blockers in between. Nobody had to wonder where things stood.
- Made escalation paths explicit. When a decision or blocker came up, everyone knew who owned it and how fast it needed an answer.
| Risk | Warning sign | My response |
|---|---|---|
| Requirements | Client inputs still missing | Easy-answer template plus a working session to close the gaps |
| Schedule & capacity | Three weeks behind, holiday capacity shrinking | Reprioritized to critical workflows, set release order, made escalation paths explicit |
| User impact | Quality-of-life updates had to wait until after launch | Kept deferred work visible, built workaround job aids, offered hands-on support |
The tradeoff
We couldn't deliver all 200+ workflows by year-end, so I made that clear early instead of letting it surprise anyone at the deadline. We protected the workflows the business couldn't run without and moved the remaining functionality to after the new year, when the full team was back.
Deferring work only builds trust if people can see it's coming. The deferred items stayed on the visible plan, I built workaround job aids for users, and I offered hands-on help so day-to-day work wasn't disrupted while those updates waited.
The result
About 130 of the 200+ workflows were promoted to production before the year-end deadline, covering the business-critical core. The remaining functionality went live after the team returned from the break, and users had job aids and support in the meantime. The project stayed within its $150,000 budget.
The relationship recovered too. The client sent a heartfelt thank-you, re-signed their expiring support contract, and brought us additional projects.
What this shows
- I diagnose before I push. The fix was a requirements gap, not a velocity problem. Treating it as a velocity problem would have burned out a two-person team without moving the date.
- I decide with the information available. When the user survey came back thin, we prioritized with what we had instead of stalling.
- I make tradeoffs visible early. Clients can handle a hard choice. What hurts trust is a surprise at the deadline.
- I translate between business and technical teams. The template turned developer questions into answers a law firm could give within a day.
- I protect the people downstream. Deferred work came with job aids and hands-on support, so users weren't left waiting without help.