Transformation delivery
Put business dependencies on the delivery plan.
Make the decisions, data, people and operating changes that technology delivery depends on visible, owned and timed.
A new job-management system is technically on track for launch. In this hypothetical example, the configuration is nearly finished and the supplier has met its milestones. The launch still depends on a pricing decision, cleaned customer records, revised team responsibilities and time for operational testing. None of those items appears on the main delivery plan. The technology can be ready while the business is not.
Look beyond the technical work
For each important milestone, ask what must also be true outside the delivery team. Start with decisions, data, people, process and third parties. These are not background assumptions when the date or outcome depends on them.
In the hypothetical launch, the system may need a confirmed price list before configuration can be completed, named people available for testing, agreed ownership for exceptions and a supplier response to a contractual question. Put each dependency beside the work it affects.
- Decision: which choice must be made, and by whom?
- Data: what must be available, complete and checked?
- People: whose time, knowledge or authority is required?
- Process: which working rule must change or be agreed?
- Third party: what must a supplier or partner provide?
Give every dependency a need-by date
The need-by date is not always the final deadline. It is the last point at which the dependency can be resolved without disrupting the work that follows. A training decision may be needed before materials are written; cleaned data may be needed before a migration rehearsal, not on launch day.
Name one accountable owner and the evidence that will close the item. “Operations to confirm” is not enough. Record the person, the required answer or artefact and where completion will be visible. If responsibility is shared, keep one owner for coordination.
Review consequences, not just status colours
A dependency can stay marked green until the moment it blocks the plan. Review what has changed, what is still assumed and which downstream activity is now exposed. If an item will not be ready, make the consequence explicit: re-sequence work, reduce the launch scope, secure temporary capacity or move the date.
Keep the response proportionate. Not every dependency belongs in a senior meeting. Escalate when the owner lacks authority, the latest useful date is approaching or the consequence crosses an agreed tolerance.
Keep the plan connected to adoption
Continue tracking business dependencies after launch. New working rules, support cover, reporting ownership and the retirement of old processes often determine whether the change becomes routine. Treating launch as the finish line hides the work required to make the investment useful.
A short dependency review can sit inside the existing delivery rhythm. It should expose what the plan is waiting for and prompt an action, not become another report to maintain.
Rethink’s ongoing AI and technology support can provide regular senior delivery challenge, help resolve cross-team dependencies and keep implementation connected to adoption under an agreed scope.