The build finished on a Tuesday, on time, and then sat untouched for nineteen days. It was waiting for a security review from a team in another division, a team that had never heard of our project, whose queue ran six weeks deep, and whose manager reasonably asked why we hadn’t booked in March. Our schedule had the review down as three days. The three days were accurate. They just weren’t attached to any agreement with the people who’d do the reviewing.
Nobody had failed at their job. That’s the thing about dependencies. Every task had an owner working diligently. The gap between the tasks had nobody at all.
Your schedule is mostly other people’s promises
Look at any project plan honestly and the tasks your team fully controls are a minority. The rest depends on approvals from committees you don’t sit on, data from systems other teams run, decisions from executives with fuller diaries than yours, and deliveries from vendors with other clients. A schedule is not a description of your team’s work. It’s a portfolio of other people’s promises, most of which were never actually made. The task list says “receive legal sign-off, two days.” Legal has not agreed to two days. Legal has not been told.
This is why I keep arguing that the operating model matters more than the plan. In four events, four operating models I looked at how the world’s biggest events answer one question: what do you control and what do you borrow? Projects fail on borrowed ground far more often than owned ground, and the border is exactly where the dependencies live.
Convert assumptions into agreements
The fix isn’t more sophisticated scheduling software. It’s an uncomfortable amount of talking. Every external dependency on your plan is in one of two states: agreed with a named person who knows your date and has accepted it, or assumed. There is no third state. “It’s in the plan” is not a state.
So walk the plan and sort every dependency into those two buckets. The assumed bucket is your real risk register, and it deserves the treatment I described in the unpriced trade-off: name the cost out loud while it’s still cheap. Then give every dependency a single owner on your side. Not the other team. Someone on your project whose job is to hold that promise, chase it weekly, and raise the flag the moment the other side’s dates start drifting. Dependencies don’t fail suddenly. They fail quietly, weeks before the plan notices, in a status update someone on the other team gave to a different meeting.
The Tuesday test
Pick the three dependencies that would hurt most and ask: does the person on the other end know our date? Have they said yes to it, to us, this month? If the answer’s no, your schedule has a nineteen-day gap in it already. You just haven’t met it yet.
Ben Webb is an Australian project leader and speaker, AIPM Project Manager of the Year 2022 and IPMA World Project Manager of the Year nominee. He writes about delivery, leadership and events.
Leave a Reply