The roadmap slide shows change and hides the dependencies
Every automation roadmap I have reviewed in the last two years has had the same shape. One row per quarter, one feature per row, a sponsor beside each. Supplier onboarding in the first quarter, purchase requisition approvals in the second, a supplier self-service portal in the third. What none of them showed was which system owned the supplier record all three items touch, or who would fix it when the bank details arrived wrong.
That gap is where the sequencing breaks. The program commits to order and scope before anyone has written down the flows the work depends on. The first item ships. The second discovers that the supplier number it needs is assigned in S/4HANA two days after Dataverse believes the supplier exists. The third slips a quarter while two teams argue about which side is the source.
So my rule before any program commits to a sequence is a one-page map of the information flows it will touch. Not an architecture diagram with boxes and arrows. A list, with three columns, that the people who run the work can read in ten minutes.
Source of record, consumer, exception owner
For each flow, I write down the source of record, the consumer, and the business owner who resolves exceptions. Source of record means the system where a value gets corrected when it is wrong, which is a different question from where it was first typed. Consumer means the system or team that acts on the value and would notice if it stopped arriving. Exception owner is a person or a team with a queue. It is never a connector, never a middleware tenant, and never the integration team by default.
The third column is the one that stays blank, and it decides whether the roadmap is honest. Take a Power Automate flow that pushes a new cost centre from Dataverse into S/4HANA through Integration Suite on BTP. Source and consumer are obvious. Then a posting fails because the company code was retired last month, the flow marks itself failed, and the message sits in the integration monitor. Someone has to open it, decide whether the cost centre was ever valid, and correct it in the right place. If the map cannot name that someone, the roadmap item that depends on the flow is not ready to be given a date.
I have argued before that the queue is never the owner. The map is where that principle turns into a column heading everyone in the room has to fill in, in front of each other.
The credit hold that lived in three places
The situation I keep coming back to came out of a planning review for a sales operations program. The roadmap opened with an item called block quotes for customers on credit hold. It would read a flag on the account in Dataverse and stop a rep from generating a quote. Sponsored by finance, built by the Power Platform team, estimated at three weeks.
When we mapped the flow, the credit hold turned out to have three lives. Finance set it in S/4HANA. A nightly job copied it into Dataverse through BTP, so the flag in front of the rep was up to a day old. And the collections team, who released holds when a payment landed, did not touch SAP at all. They kept a spreadsheet and emailed it to the sales desk every afternoon. Nobody on the roadmap call knew about the spreadsheet until the map asked who clears a hold.
The program did not need a bigger integration. It needed a decision that the hold is set and released in one place, and that the copy in Dataverse carries a timestamp the rep can see. That decision pushed the blocking item back a quarter and pulled forward something much smaller: agreeing which fields on the account are shared rules and which are local convenience. That is the question at the centre of what a shared customer record needs, and it is cheaper to answer before the blocking logic exists.
Write down how the consumer knows a change arrived
The second thing I add to each row is a short note on how the consumer would know a change landed. This sounds trivial. It rarely is. A Power Automate run history where every row is green means the HTTP call was accepted. It does not mean the IDoc posted, and it does not mean the buyer in the plant can see the new supplier in their search. I have sat in incident reviews where the integration team pointed at a fortnight of successful runs while the receiving team had been keying suppliers by hand for the same fortnight.
So for each row I ask the consumer, in their own words, what they would check. Sometimes it is a field on the record, a status that flips or a timestamp that updates. Sometimes it is a report someone runs on Monday morning. Occasionally the honest answer is that they would find out when a purchase order failed, and that answer goes on the map exactly as they said it. A roadmap that puts an approval step or an agent on top of a flow nobody can verify is building on something the organisation cannot see. The piece on where automation ownership breaks down describes what that costs later.
Read the roadmap against the map
Once the map exists, reading the roadmap against it takes about an hour and changes the conversation. Each roadmap item gets tagged with the flows it consumes or changes. Any item touching a flow with a blank exception owner gets a dependency, and the dependency is a named decision with a person beside it rather than a technical task. Any item that would introduce a second source for a value that already has one gets a hard question about whether it should exist at all.
The map also keeps the scope of each interface honest. If an item needs three new fields from a flow that today carries forty, it becomes obvious that the contract should stay narrow and versioned instead of widening again. The argument for keeping integration contracts small is far easier to win when everyone can see which downstream consumers a change would reach.
What I say in the meeting is usually some version of this. We can keep the order on this slide, but three of these items depend on a decision about who corrects supplier data, and until that decision has a name and a date, the dates on the slide are guesses. Nobody enjoys hearing it. It still beats discovering the same thing in a go-live readiness review with the cutover weekend already booked.
Keep the map with the people whose remit changes
The map goes stale the moment a team reorganises, which in my experience happens about every second quarter. So I do not file it under architecture. I put it in front of the people who run the work, walk it once with them, and ask them to tell me when a column changes. The collections team knows before anyone else when hold releases move to a new desk. The finance approver knows when the bank detail check goes to shared services. Those people will keep the map true if it is short enough to read and if they watched someone use it to make a decision they cared about.
If you own a roadmap on Power Platform or SAP BTP that is about to go to a steering committee, pull the top five items and write the three columns for every flow they touch. The first blank in the exception owner column is the real first item on the roadmap, and it wants a name before the next slide gets a date.
