How I met your Implementation: Project Governance, or Why the Oven Temperature Beats the Ingredients

To bake a well-risen, fluffy project you need a

• fair amount of architects 
• quality developers
• a splash of consultants, 
• a tablespoon of Scrum Master (this can be omitted – no one knows what they do either ways)
• a Project Manager icing 

Last but not least, you need a proper PROCESS. The process is the oven temperature. You can buy the most sophisticated, posh ingredients on the market and still pull out either a dry stone that tastes of brick, or an inedible semi-liquid blob. Same ingredients. Different temperature.

A note on the Scrum Master before one of them will write an angry comment that the role works. What doesn’t work is a Scrum Master who books the ceremonies and nothing else. That person isn’t a bad Scrum Master — that person is a calendar with a salary. The difference between the two is the single cheapest quality upgrade available on most projects.

So let’s talk about what actually goes wrong. Everything below is something we’ve walked into on real projects — ours and, more often, ones we were asked to take over.

The oldest rule in the world and still the most frequently ignored one. Not because people don’t know it, but because nobody says it out loud in the room where the decision gets made.

What it looks like: this one is a frequent flyer – for e.g. we have a project for a global company specializing in connected technologies and audio solutions that we took over. The budget was fixed, a fixed date and a scope that kept growing. Everyone in the room knew the maths doesn’t work. Nobody wants to be the one to say it, so the project starts and the arithmetic got rediscovered three months later, at a much higher price.

What we did: we decided explicitly, in writing, which corner flexes. Not “we’ll manage” — which corner. If the date is immovable because of a regulator or a decommissioning of a legacy system, then scope is your variable and the backlog must be ruthlessly prioritised from day one. If the budget is hard, you deliver an MVP and a roadmap for the rest. If quality is hard, and on a system handling customer data it always is, then the other two move.

A useful habit: write the chosen trade-off into the steering committee minutes. Then when someone tries to bend all three corners in month four, you’re not arguing, you’re just reading.

The business says they need something and they give a date. The fact that a date exists doesn’t make it feasible. It very often means somebody promised it upward before anyone looked at the data model.

What it looks like: we ran into this on a project for an Enterprise tier telco. The estimate is expected to match the date rather than the work. Scope keeps arriving mid-sprint as “small clarifications” to existing stories. Nobody re-baselines anything, so the plan quietly became fiction while the status report stays green.

What we did: split responsibility properly and hold both sides to it.

Business owns: requirements, priorities, acceptance criteria, the business date and the reason behind it. “Q3” is not a reason. “The contract with the distributor starts 1 October” is.

IT owns: the LLD, the effort estimate in man-days, the assumptions, the risks and a clear statement of what is not included.

Then the date becomes a negotiation with scope as the lever, rather than a wish with a deadline attached.

This is where the PM has to be assertive – but assertiveness without evidence is just being difficult. Back it with a burn-up chart, a documented velocity and a scope-change log showing exactly what was added since baseline and what it cost. The PM’s sentence is never “no.” It’s “yes, and here is what moves.”

And the rule that makes change control real: something new comes in, something goes out, or the baseline changes. Those are the only three options.

What it looks like: eight hundred tickets. Everything is priority one, which means nothing is. Refinement sessions turn into discovery sessions because nobody knows what half the items mean anymore. Sprint planning takes four hours and ends with a shrug. Meanwhile, nobody can answer the simplest question a sponsor asks: what will we have by Christmas?

Why it happens: this one we encounter more than once. The first example that comes to my mind is a project that we took over in the Manufacturing industry. We took over from other company after they unsuccessfully tried to implement Sales Cloud. Backlog was easy to add to and socially awkward to delete from. So it grew until it stoped being a plan and become an archive of everything anybody ever wanted.

What we did:

• One backlog, one owner. Not one per stream, not one per department. If two people can set priority, priority doesn’t exist.
• A roadmap in three horizons — now, next, later — expressed as business outcomes, not features. “Advisors handle a complaint end-to-end in one system” is a horizon. “Build Flow XYZ” is a task.
• Forced ranking. No ties. If everything is critical, ask which one ships first — that question has exactly one answer.
• A Definition of Ready. No story enters a sprint without acceptance criteria, a known integration impact and a named business owner. This one rule removes more mid-sprint chaos than any tooling ever will.
• Backlog hygiene. Anything untouched for ninety days gets archived. If it matters, it comes back within a week and costs you nothing. Usually it doesn’t come back.

What it looks like: the same business rule is verified in unit tests, again in manual system tests, again in the automation suite, and then once more in UAT – where business users “test” by re-running the system test scenarios someone sent them the day before. Four passes, one rule. Meanwhile the genuinely risky integration path has never been tested end-to-end by anyone, because everybody assumed it belonged to another layer.

What it costs: a regression run that takes two days instead of two hours, a release cadence dictated by the test suite rather than by the business, and – the expensive part – a false sense of safety. Overlapping coverage feels thorough. It isn’t. It’s thick in the middle and thin at the edges.

What to do: write a one-page test strategy that maps each layer to what it owns, then defend the boundaries.

Three things make the table hold. Entry criteria for UAT, so it starts when the earlier layers are done rather than when the date says so. One defect tracker for the whole project, no matter how many vendors are in the room. And one metric worth watching: defect escape rate by layer. It tells you exactly where your testing is theatre.

What it looks like: you first eat the ingredients and then start baking… while they are in your stomach…

The design document is produced at the end of the phase, reverse-engineered from what was built, because a contract or an internal checklist requires it. Nobody reads it. It’s out of date within a sprint.

Why it’s worse than having no document: an LLD produced before development is a design decision and it forces someone to think about the data model, the integration points and the volumes while changing them is still cheap. Produced afterwards, it’s an archaeology report. The thinking never happened; it was replaced by a series of ad-hoc decisions taken inside pull requests, each individually reasonable and collectively incoherent.

The bill arrives later: third-line support can’t support what they can’t understand, handover to the client’s team takes months instead of weeks, and every architectural question gets answered with “ask Marek” — until Marek changes jobs.

What to do:

• Put the LLD in the Definition of Ready, not the Definition of Done.
• Keep it short. Two pages and a diagram that are true beat forty pages that are ceremonial. The purpose is to make the design reviewable, not to fill a template.
• Record decisions, not just outcomes. A short ADR – decision, context, alternatives rejected, why – answers the question that actually gets asked in year two: why on earth is it built like this?
• Keep documentation next to the code and review it in the same pull request. Documentation in a separate shared drive diverges from reality on the day it’s written.
• Generate what can be generated – object schemas, flow lists, dependency maps, and write by hand only what needs judgement.

Third line is fine. Third line is rare, deep and genuinely needs the people who wrote the code.

Second line handled by the delivery team makes about as much sense as the plot of Cinderella  where an entire kingdom runs a nationwide shoe-fitting programme. Expensive resources, wrong process, problem solvable in five minutes by the right person.

What it looks like: a developer with a complex piece of work in front of them gets interrupted eleven times a day by simple issues, “quick questions” arriving directly on Slack and so on. Sprint capacity becomes unpredictable, velocity stops meaning anything, and planning turns into guesswork. The team isn’t slow – it’s a helpdesk that occasionally gets to write software.

The hidden cost is worse than the hours lost. Interrupt-driven work is shallow work. It is very hard to hold a complex integration in your head when the average uninterrupted stretch is nineteen minutes.

What to do:

• Separate the function. Second line needs runbooks and process, not senior Apex developers. This is usually the whole answer.
• If it can’t be separated, ring-fence it. One named developer per sprint on support duty, with capacity explicitly carved out, let’s say twenty percent, and the rest of the team genuinely protected. Rotate it so nobody burns out and everybody understands production.
• Close the direct channels. Everything goes through triage. No DMs, no corridor requests, no “you’re the only one who knows this.” If someone is the only one who knows something, that’s a documentation defect (see point 5).
• Feed it back. Every recurring second-line ticket is a missing feature, a missing validation or a missing runbook. Route the pattern into the backlog instead of handling the same incident forty times. Incident management keeps the lights on; problem management turns them off permanently.
• Make the runbook a go-live gate. Part of the Definition of Done, not a follow-up task. Support can only take second line if they’ve been given something to work with.

What it looks like: several streams blocked, all of them waiting on an integration with a system owned by someone else. Every team has a defensible reason why the problem sits elsewhere. The ticket moves between queues for three weeks. Escalation happens only once the date is already lost, at which point the discussion is no longer technical.

Why it happens: dependencies fail precisely where accountability ends. Each team is doing its job correctly within its own boundary. Nobody owns the boundary itself.

What to do:

• Name an owner per interface — a person, not a team. A team can’t be called at 16:00 on a Friday. Someone whose name is on the integration can.
• Keep a visible dependency register. What is needed, from whom, by when, and what happens if it’s late. If a dependency isn’t written down with a date and a name, it isn’t managed — it’s hoped for.
• Go contract-first. Agree the API contract early, mock it, and let both sides build against the mock. Most cross-team blockage is two teams waiting for each other to go first. A contract and a mock removes the waiting.
• Automate escalation. Anything blocked beyond forty-eight hours goes up a level by default, with no judgement call required. Automatic escalation isn’t aggressive — it removes the social cost of raising a hand, which is the actual reason things sit blocked for three weeks.
• Put cross-system priority where it belongs. Two teams with different sponsors cannot resolve a priority conflict between themselves, and asking them to is unfair. That’s what the steering committee is for.
• Make someone accountable for the end-to-end outcome, above the individual streams. Without that role, every dependency is somebody’s edge case.

None of the above is exotic. There’s no problem on this list that a competent team hasn’t seen before, and no solution that requires a new tool or methodology. That’s exactly the point: projects rarely fail because of ingredients. They fail because the temperature was wrong and nobody checked the oven until the smoke came out.

Which is why my one piece of genuinely practical advice is about the partner you pick, and specifically about their project managers. A good PM is the person who says the uncomfortable thing in month one rather than month six.

On one of our projects for a global technology company serving automotive and consumer markets, Łukasz Chęciński took over a Salesforce delivery covering Salesforce Platform and Einstein bots. He joined a project where he found at least half of the aforementioned issues. He reorganised the delivery plan, clarified ownership, reduced the migration scope and moved selected integrations into separate workstreams, which resulted in successful delivery. And he has been doing that for the last 15 years.

Anyone can present well at the start of a greenfield project. The better test is what happens when someone joins halfway through, inherits the decisions already made, and still has to get the project under control.

If you recognise more than two of the seven, send us your backlog and your test strategy. In a week we’ll show you where you’re paying twice for the same rule 😀