Define your process or outcome first?

Should you be designing processes first or focus on the outcomes?

This is a critically important question when thinking about redesigning your business processes. You have one chance to get this right and a room full of senior people with high expectations of the process workshop.

When running live process mapping workshops, when we define the top level of the map (which could be Quote to Cash or Recruit to Retire or even the entire company) we always start with the final outcome. And often a significant amount of the time is spent debating and getting agreement on exactly what the outcome is.

Outcomes drive everything

What is the definition of “satisfied customer” for your organisation? Everyone had better be clear, because that will drive the processes you have in place. Or let us take a complex process, which seems so simple.

“When is a software support call resolved”?

• When it has been reported to the help desk?
• When it has been investigated and found to be a bug?
• When the user has been told that it is a bug and it will be in the next release?
• When the new release has been delivered?
• When the user has implemented the new release?

Until we get agreement on this simple question, we cannot hope to build the right processes.

3 simple steps

So define your outcomes which allows you to design processes that have the roles and responsibilities. Simple really.