Which workflow should you build first?

Choose a workflow your team repeats, whose current cost you can describe, and whose owner can help test a first version. That gives a software project a useful starting point: a real piece of work and a way to tell whether it improved.

For an advisory firm, the candidates might include preparing for a client meeting, turning a meeting decision into assigned follow-up, or helping an associate find the current version of a service process. Each has a different user, trigger, and consequence. Pick one before trying to connect them all.

Describe the work as it happens today

Follow a recent example from start to finish. Name the person who receives it, the places they look for information, the people they wait for, and the point at which the work is complete.

Use an actual example with sensitive details removed. A diagram of the intended process will miss the spreadsheet someone keeps open to make the process work.

Write down five things:

• What starts the work?
• Who needs to finish it?
• What information do they need?
• Where does it wait, get copied, or get corrected?
• What tells the next person that it is complete?

Choose a first release your team can judge

A useful first workflow has a reachable owner, examples you can test, and a clear boundary. Your team should be able to explain what the first release includes and what a successful run looks like.

If the work depends on a decision that nobody has agreed to make, settle that decision first. If the inputs are unavailable, arrange access before promising a launch date. If the process changes every time, understand those differences before turning them into rules.

For an advisory team, that might mean starting with meeting preparation for one service rather than rebuilding the whole client experience. An associate gathers the agreed information, the advisor reviews it, and the team can check whether the packet is ready. The advisor still makes the decisions that require their judgment.

Record a baseline before you build

Keep a small set of recent examples. Record how long the work took, how much time was spent waiting, what had to be corrected, and whether the person receiving it had what they needed.

Then run the same kinds of examples through the first release. Compare the result, including any new work the software creates. A faster screen does not help if someone has to spend longer preparing its inputs.

These are measures to collect, not promised savings. The first release earns a larger investment when the people doing the work can show what changed.

Bring the workflow, its owner, and three examples

A first conversation is more useful when someone can show the current work. Bring its owner, three recent examples with sensitive details removed, and the decision you need the first release to help you make.

BFD builds workflow software for advisory teams. If you are still choosing the problem or first scope, a Foundations Sprint gives the team a place to start. If the workflow is already clear, tell us what needs to work.