Outproduce

Free planning tool

Put a boundary around your workflow.

Already have a task in mind? Answer six questions about its systems and owners. You will get a suggested scope, unresolved approval points and a CSV to use in your build discussion.

0 of 6 answered

Choose one answer in each group. Your result appears below after all six.

1How much work belongs in this scope?

Describe the workflow you already chose.

2How many systems carry the work?

Count systems that must be read or changed, not every app in the company.

3Can the source records be inspected?

A person should be able to trace an item from its input to its finished state.

4Are the approval boundaries written down?

Name what may happen automatically and what must wait.

5Can you name the failure cases?

Include missing records, unavailable systems and requests outside the scope.

6Who will own the workflow after launch?

The business owner and the person handling technical failures must both be clear.

Turn the outline into a testable scope

Review the outline with the workflow owner. Add the actual system names, allowed actions and people who handle exceptions. An assessment is optional, depending on the engagement.

How the scope rules work

Coverage and system count add zero, two or four points. Mixed records, partial approval rules and several exceptions each add two. Managed technical support adds one. Totals of zero to three suggest a contained workflow, four to eight a connected workflow and nine or more a broader scope. Missing records, approval rules, a normal path or an owner always produce an unresolved-boundary warning. These rules describe a starting scope. They have not been validated against build effort or production readiness.

Start here

Show us the workflow.

Tell us what starts it, who owns the result, which tools carry it, and where it stalls. We will tell you whether it is ready to map.

Strong fit

The workflow repeats

One person owns the result

The records exist

Several tools carry the work