How to prioritize process improvements with an impact effort matrix

Start with the process problem, not the proposed solution

Ask what should change for the people using the process. Faster reporting, fewer incomplete requests and clearer handovers are different outcomes. Choose one for this decision; otherwise each person can defend a different improvement as the most important.

In this illustrative case, an Operations team wants fewer routine internal service requests returned for clarification, without slowing the first response. Its review of the previous 20 requests records one primary cause per request: eight lacked essential information, five had unclear ownership at a team handover and seven needed no clarification. These are invented case assumptions, not Plotwins customer data.

The team has eight person-days available this month after routine service and required commitments. It will test changes on the next 20 comparable requests, aiming for a two-week pilot and extending it if fewer arrive. A person-day counts the work of all contributors; it is not a calendar day.

• Review the complete impact effort matrix method

Agree on scope and the scoring scale

Compare bounded changes to this request process. An intake adjustment and an entire company-wide automation program are not comparable units. Separate required work first, then include preparation, configuration, training and delivery checks in each improvement estimate. Reserve outcome review and contingency separately.

Here, impact runs from 1 to 5: little connection to the goal, a limited contribution, a useful contribution, an important obstacle addressed, and the main observed obstacle addressed. Effort bands are up to half a person-day, more than half to one, more than one to three, more than three to five, and more than five. Scores of 4–5 are high and 1–3 are low on both axes.

These scores express comparative judgments, not guaranteed savings. Check the estimates with the people doing the work. Record software costs, waiting for approvals and specialist availability separately; eight days of pooled capacity do not guarantee that the right person is available.

• Define impact and effort scores with your team

Compare four possible process improvements

The team considers four proposals using its existing tools. Report automation would save administrative work, but the case review points more directly to incomplete requests and unclear handovers. The matrix makes that difference visible without treating the report as worthless.

This case concerns internal service requests. It is separate from the client-onboarding example elsewhere in the guide; its observations, capacity and estimates should not be combined with that example.

Illustrative estimates, not customer results. High: 4–5; low: 1–3. The table explains each position.

• Compare this with other team prioritization examples

Choose improvements that fit the actual capacity

Operations selects the intake change and the handover change. It plans the intake first, confirms the availability of both team leads and releases the handover change after checking the new intake. The delivery estimates already include agreement, configuration and usability checks; the separate review day is for examining what happens to requests afterward.

Use the person-day estimates to plan, not the effort scores. Adding an effort score of 3 to a score of 4 does not mean seven days. Nor does dividing impact by effort establish a reliable return on investment.

Pilot a small change before expanding it

For the intake, agree what information is essential, adjust the existing request form or checklist, test it with a few requesters and publish a short instruction. Do not make every field mandatory just to produce complete forms; check whether people understand the questions and can still ask for help.

For the handover, map the current transfer, agree who accepts a request and what makes it ready, prepare both teams and check a sample transfer before release. Keep the previous procedure available so the process owner can reverse a change that blocks work.

Record the release date of each change and which procedure each pilot request used. The intake may already resolve some apparent handover problems. Revisit the second change before committing its full effort if the evidence changes. A small sequential pilot helps learning but does not isolate the causal effect of each change.

Turn the decision into a shared plan in Plotwins

Create a project for the internal-request improvement and give each proposal a task on the matrix. Keep the goal, the observations behind the estimate and the boundaries of the work in the task description. The 1–5 scale is the team's convention for explaining positions.

For the selected work, use the following setup. The operational measurements still come from the request records; bring the observations into the review task so the team can discuss them alongside the work.

1. Assign the intake task to the Operations coordinator. Add subtasks for agreeing fields, adjusting the intake, testing it and sharing the instructions.
2. Assign the handover task to the service lead. Add subtasks for mapping the transfer, agreeing acceptance and preparing both teams; record who must participate.
3. Set dates and time horizons after checking availability. Keep the reason for deferring the report and documentation tasks in their descriptions.
4. Create a review task owned by the process owner. Include the pilot scope, the measurements to collect and the decision about expanding, changing or reversing the pilot.
5. Use comments to record changed assumptions and move tasks on the matrix when the goal or estimate changes. Review the plan before adding more work.

• Explore process improvement with Plotwins for Operations
• See how to position tasks on the matrix
• Organize subtasks, responsibilities and follow-up

Review process outcomes as well as completed tasks

At the review, compare the baseline with the next 20 requests of the same type. If volume is lower, report the actual count and extend the observation period. Record the clarification reason and procedure version; exclude urgent exceptions consistently from both groups and review them separately.

Compare returned requests as a share of the requests reviewed, not only as a raw count. Also check time to first response and whether requesters find the new intake harder to use. A lower return rate is not enough if requests are now waiting longer or people have stopped submitting them.

The sample is small, and workload or request complexity may have changed. Treat it as evidence for the next decision, not proof of a guaranteed improvement. Record actual delivery effort too, including time spent maintaining the new process.

Use the next matrix discussion to review the deferred work

A low score belongs to a particular goal. Report automation may become a stronger candidate when the next objective is reducing administrative workload. Bring it back with evidence of time spent, an estimate of maintenance and the capacity it would actually release.

Keep a short decision record: goal, evidence, chosen work, deferred alternatives, capacity, owner and review date. This makes it easier for other teams to understand the choice and for Operations to change course when it learns something.

• Return to the impact effort matrix guide
• Explore Plotwins with your Operations team