Requests, dependencies, prioritization with the criterion on record, and a decision by the appropriate decision-making authority — from the request that comes in to the outcome recorded with its reasons. Where that decision leaves commitments open, each one is tracked through to the status confirmed by the authorized owner or by the system of record for execution, whichever was agreed for that commitment.
01 · The problem
Demand arrives from everywhere and in every shape: a manager who needs a process changed, an obligation with an external date, a project left half-done, a request from the top to look at an idea. Each is logged wherever there is room, and no two end up in the same place.
Today, initiative records are scattered across whatever tools each team had available: Microsoft Excel spreadsheets kept by each area, email threads holding the original request, and the business cases and minutes in the organization's document repository — Microsoft SharePoint in Microsoft 365, for example.
Portfolio reporting in Microsoft Power BI summarizes self-reported progress. None of those sources records which request was merged into which, who owns the item holding an initiative up, or on what criterion it ranked below another in the previous cycle.
Much of the prioritization meeting then goes into rebuilding that list: what exactly was asked for, who sponsors it, whether it had already been raised, what it depends on and where it was left last cycle. The decision gets made on whatever could be gathered in time, not on what the organization already holds.
A prioritized initiative has not yet been decided; even an approved initiative may still have conditions to meet before work can start.
02 · The solution
Every request comes in through the same front door and follows the same defined sequence: intake, qualification against what has already been admitted, dependencies, the cycle comparison against the criteria set for that cycle, a decision by the appropriate decision-making authority, and follow-up on the commitments that decision leaves open.
Each initiative enters the cycle already linked to what the organization has declared in the Operational Graph: the processes it changes, the applications and data it touches, the area sponsoring it and the initiatives that constrain it. That is why a dependency between two requests from different areas surfaces during qualification instead of at the kick-off meeting. BPMflow orchestrates this demand cycle — stages, deadlines, reviews, approvals and evidence — so the workflow follows the graph rather than a diagram drawn on its own.
The exception that shapes the cycle most is the late dependency: an approved initiative stalls because another one, still undecided, is its precondition. Progress on the first does not close the matter. The dependency is recorded and visible on both records, with an owner and a due date, and each initiative keeps its own status: the first holds one of the four decision outcomes — approved, with a condition still open — while the second holds no outcome at all, because the body responsible for it has yet to rule. Two separate states, and neither is absorbed into the other.
03 · Capabilities
Every initiative sits on one board, with its stage, sponsor, dependencies, age and outstanding decision in plain view. Max answers questions about an initiative within the authorized context: it explains which stage the initiative is at, shows the evidence on record and points to what is holding it up.
Captures each request with its subject, requesting area, sponsor, expected outcome and stated urgency — whether it originates in the business, in an obligation with an external deadline, or in a project left half-done.
Compares the request against the initiatives already admitted and against the processes and applications it touches: a request that duplicates an active initiative is merged into it instead of opening a second case in parallel.
Links each initiative to the processes, applications, data and areas it needs, and makes visible when one initiative is a precondition for another, or when two compete for the same component.
Applies the criteria set for the cycle and keeps the score, the criterion applied and who assigned it. Changing a criterion opens a new cycle; it does not rewrite the previous comparison.
An initiative can be approved, reformulated, deferred, or rejected with reasons on record — four distinct outcomes. Each one requires the authority appropriate to that type of initiative, and each one gives the requester a reason they can see.
Tracks open conditions, committed milestones and scope changes with an owner, a date and evidence, through to the status confirmed by the authorized owner or by the system of record for execution, whichever was agreed for that event.
04 · Roles
Owns the cycle and its calendar.
What they see
Every request by stage, sponsor, open dependency and age, plus what each one still needs before it can be decided.
What they do
Admits or returns the request, merges duplicates, builds the cycle comparison and publishes the outcome with the reasons behind it.
Raises the initiative and answers for it.
What they see
The status of their request, what information is missing and which other initiative it depends on to move.
What they do
States the subject and the expected outcome, responds to review comments and takes on the commitments assigned to them.
Defines the technical prerequisites.
What they see
The initiatives touching the same applications, data and integrations, and the order in which they touch them.
What they do
Records dependencies and preconditions, and flags when the proposed sequence cannot be executed in the priority order that was set.
Decides within its own authority.
What they see
The cycle comparison with its criteria, the declared dependencies and the commitments already taken on in earlier cycles.
What they do
Approves, reformulates, defers or rejects with reasons, and puts the conditions attached to each decision on record.
05 · How it connects
Prioritizing initiatives, deciding on an investment and assessing the impact of a change are three different questions about the same portfolio, and they belong to different owners. Each has its own path; shared context is what keeps all three from being rebuilt separately.
When a prioritized initiative needs a formal economic decision, that path picks up the request, the reviews by the competent areas, the authority that applies by amount and policy, and the conditions that survive the approval.
See Financial Decision & Investment Governance →When the question is what the initiative will affect before it is approved — processes, applications, data, risks and the teams involved — that analysis and the roadmap it produces live in Change Impact.
See Change Impact →When two initiatives compete for the same application or the same component, architecture criteria and the current state of the repository supply the technical sequencing that prioritization alone cannot resolve.
See Enterprise Architecture Governance →The portfolio answers what gets done first; the investment decision, on what terms; the impact analysis, what changes when it happens.
06 · Implementation
The initiatives open today and the criteria the organization already applies are the raw material for the first cycle. There is no need to freeze the portfolio to get started.
1 · Agree on the cycle and its criteria
Which requests enter the portfolio, what minimum information a request must carry to be qualified, which criteria rank requests within the cycle, which authority decides each type of initiative, and what counts as a decision made.
2 · Load the portfolio as it stands today
Initiatives in flight are loaded and linked to the processes, applications and areas already declared in the Operational Graph. The first cycle needs only its own context; there is no prerequisite architecture project.
3 · Run a real cycle and hand it over
The first cycle uses requests from the current period. The team tunes criteria, deadlines and dashboards as that cycle runs, and the client team then takes over day-to-day operation.
07 · Typical scenarios
Several areas asking at once, obligations with external deadlines, initiatives that depend on one another, and a quarterly decision cycle: this is part of the normal operating rhythm of a transformation office.
Illustrative applications, not client references: equipment and infrastructure in healthcare; capacity, renewal or expansion initiatives in CPG, education and utilities; and corporate transformation demand. The cycle is the same one; what changes is the type of request, the criteria that rank it and the body that decides.
A portfolio is governed when every request has a stage, every priority has its criterion on record and every decision has someone accountable for confirming it. The practical way in is to run one full cycle using requests from the current period.
Demand and Portfolio Governance is an EAFlow cross-industry solution on the Operational Graph, supported by BPMflow automation capabilities. The economic decision and its conditions live in Financial Decision & Investment Governance; the analysis of what an initiative will affect lives in Change Impact. It is not a portfolio management suite: it does not plan resource capacity, does not track timesheets and does not produce the detailed financial forecast.
