A future-state process should solve a diagnosed present-state constraint, not merely make a diagram look cleaner. Before changing systems or reporting lines, establish where work waits, who owns decisions, which exceptions recur and what the customer or internal user experiences.
Compare the present and proposed workflows using the same measures, cases and controls. The resulting gap analysis should tell management what to change first, which assumptions need a pilot and which risks the redesign must not create.
Business Need
Define the outcome at risk and the boundaries of the process being examined. Distinguish delay, quality, cost, compliance and experience problems instead of assuming all process steps are equally weak. Agree the decision owner and evidence needed to justify redesign.
Stakeholders
Include the people who initiate work, perform handoffs, approve exceptions, support technology and receive the outcome. Ask where informal workarounds exist and which controls they protect. Map decision rights before proposing role changes.
Current Process
Observe representative work rather than relying only on policy charts. Record triggers, inputs, process steps, waits, rework, exception rates if actually measured, and responsible teams. Capture a comparable baseline and note where data is missing.
Requirements
Express future-state needs as capabilities and constraints, such as a visible owner at every handoff, auditable approval history or reliable exception escalation. Separate genuine obligations from an incumbent tool’s screen layout or historical practices.
Prioritization
Rank redesign opportunities by the consequence of the current bottleneck, feasibility, risk, dependencies and ability to test safely. A quick change to a handoff may be preferable to replacing an entire platform before the operating problem is understood.
Acceptance And Traceability
Test the proposed state with representative routine, edge and failure cases. Compare results against the current baseline using the same definition and observation period. Record remaining gaps, responsible owners and conditions for wider adoption.
Practical Current State Vs Future State Analysis Working Template
- Trigger and result: Where does the workflow start and what must it deliver?
- Current-state evidence: What do observation, records and exception cases reveal?
- Root cause: What actually produces the delay, defect or rework?
- Future-state change: Which role, handoff, rule or capability will change?
- Controls and risks: What must remain safe, compliant and traceable?
- Pilot decision: Which comparable evidence supports adoption, redesign or reversal?
- Owner and next review: Who will act, by when and with which evidence?
Worked Example
Consider a multi-stage invoice approval process. Before automating it, the team maps where requests wait, how delegates are assigned and why incomplete submissions return to the originator. A proposed future state may simplify handoffs, standardize required data and specify escalation for absent approvers. Pilot a representative set of invoices before making claims about time savings.
Common Mistakes to Avoid
- Designing the desired system before observing the existing process.
- Using a workshop consensus as evidence that a bottleneck has been measured.
- Removing an approval or control without checking its purpose.
- Comparing current and future performance with different populations or definitions.
- Scaling a pilot without testing exceptions and staff responsibilities.
Questions Managers Should Ask
- What is the most consequential observed failure in the current workflow?
- Which step creates rework, waiting or unclear accountability?
- Which control must survive in the future state and who verifies it?
- Can a smaller process or policy change address the problem without a new system?
- How will pilot results be compared fairly with the baseline?
Management Review Checklist
Bring a current-state map, prioritized root causes, proposed future-state map, change owner and comparable test evidence to the decision meeting. Resolve process ownership and control exceptions before treating the diagram as an approved operating procedure.
What to Review After Three Cycles
After several process cycles, review completion, exceptions, rework and user effort using the same definitions as the baseline. Where the redesign moved work to another team or generated new exceptions, update the operating model rather than declaring success based on one faster step.
A 30-Day Application Plan
- Week 1: Observe live cases and document the current workflow, exceptions and baseline.
- Week 2: Validate root causes with adjacent teams and sketch alternative future states.
- Week 3: Pilot the smallest safe change with explicit controls and acceptance checks.
- Week 4: Review comparable results and decide whether to adopt, refine or revert.
Capability Maturity
Basic: the present process and its ownership are visible. Developing: future-state requirements follow confirmed causes and are tested. Mature: teams measure end-to-end results and update the process when new constraints appear.
For HR, L&D and Corporate Sponsors
Corporate participants should work on a real but appropriately anonymized process with a defined owner. Their workshop output should include current-state evidence, a future-state design, risk controls, a pilot plan and an acceptance decision, not merely two contrasting flowcharts.
Related Courses in This Capability Cluster
A worked application scenario
A procurement team wants to redesign supplier onboarding because many applications stall. Instead of mapping the official procedure alone, the analyst observes actual cases, including incomplete documents and requests that bypass the standard route. The team distinguishes necessary controls from duplicate data entry and identifies who owns cross-functional handoffs. It sketches a future process with measurable completion and exception rules, then pilots it with a limited group. Comparison against the observed current state demonstrates whether the redesign solved the real bottleneck.
Where to Go Next
The Business Analysis and Requirements Management course develops this capability through live instructor-led practice, scenarios and workplace application. Organizations building a wider pathway can also review TheSkillGrid Training Bundles and Corporate Academies.
Approve the future state only when the team can explain the observed problem, why the proposed change addresses it and how the result will be checked.
Develop this capability in your organization