Upstream and downstream: mapping your dependencies
In Unit 1 you identified that your role exists to deliver specific outputs. In this unit, we take the next step: understanding that your outputs depend on inputs from others, and that what you produce in turn enables others to do their work.
This is what it means to be part of a delivery chain. Every role in the MCA sits somewhere in a sequence. Things come to you from upstream. Things leave you and flow downstream.
“A delay in the middle of a chain doesn’t just affect you. It affects everyone downstream — often people who have no idea the problem started with you.”
Upstream means what must happen before you
Upstream refers to whatever must happen before you can do your work — approvals, data, signed documents, completed designs, environmental clearances, legal opinions. If something upstream is late, incomplete, or wrong, your work stalls or you produce a flawed output.
Downstream refers to whatever your work enables. These are the people and processes that depend on what you produce. If your output is late, they wait. If your output is wrong, they either cannot proceed or they build further work on a faulty foundation.
- Approvals to proceed
- Signed documents or designs
- Data and assessments
- Legal or technical clearances
- Endorsed certificates or requests
- Verified and complete deliverables
- Cleared documents to act on
- Confirmed compliance status
- Certified payments to process
- Performance data to report
How a payment moves through the MCA
To make the chain concrete: here is how a contractor payment flows from verified work to disbursement. Every step depends entirely on the one before it.
Each step in this chain is a quality gate — and a potential failure point. If the Project Management Team passes an incomplete claim, Finance either catches the problem and delays payment, or misses it and creates a compliance issue. Every handoff matters.
What each division needs and what it provides
Every division has a specific set of upstream inputs it depends on and downstream outputs others depend on. A few examples:
- PProcurement needs: approved scope and specs from the Project Management Team, legal clearance, budget confirmation from Finance. Provides: signed contracts and variation orders to implementing teams.
- PMProject Management Team needs: signed contracts from Procurement, approved designs, ESMP clearance from ESP, M&E baselines. Provides: verified and endorsed payment claims to Finance, confirmed outputs to M&E, completion certificates.
- EESP needs: project scope and site information from the Project Management Team, MCC approval of ESMPs and RAPs. Provides: compliance clearances that unblock works mobilization and payments.
- MM&E needs: output data from implementing teams, finance disbursement data, confirmed project logic. Provides: performance reports and early warning flags to leadership and MCC.
These are not courtesy dependencies — they are operational ones. When the input doesn’t arrive on time, the downstream function either stalls or proceeds on an incomplete basis. Both outcomes cost the compact.
The four patterns that stop the chain
Most compact delivery problems are not caused by individual incompetence. They are caused by broken dependencies — a handoff that didn’t happen, information that didn’t flow, an approval that stalled with nobody flagging it.
- 1Silent blockages: Someone is waiting for an upstream input but hasn’t said so. The upstream team doesn’t know they’re blocking anyone. The delay only becomes visible when a milestone is missed.
- 2Incomplete handoffs: An output is technically passed downstream but is missing a key element — a signature, a figure, an attachment. Days or weeks are lost sending it back.
- 3Assumed handoffs: One team believes they’ve passed something on. The receiving team has no record of it. The document sits in an inbox, unreviewed.
- 4Cross-division blind spots: Each division knows its own tasks but has a limited view of downstream effects. An ESP delay holds up procurement; a legal query holds up implementation. Neither team sees the full impact until too late.
Before moving on: think about your last month of work. Where did you wait for something from upstream? Where might someone have been waiting on you?
What you’ve covered in this unit
- ✓Every role in the MCA sits inside a delivery chain — with upstream inputs it depends on and downstream functions that depend on its outputs
- ✓The payment chain example shows how a single disbursement requires correct handoffs across multiple functions — each step depending on the one before it
- ✓The four most common chain failures are: silent blockages, incomplete handoffs, assumed handoffs, and cross-division blind spots
- ✓Managing your dependencies — actively, not passively — is part of the job, not extra work
Role profiles — what each division in the MCA is specifically responsible for producing, what it receives upstream, and what it passes downstream. Find your own profile, then read at least one of your neighbors.