Start a conversation
Menu
HomeProductsServicesSolutionsWho we work withInsightsStart a conversation

Improve how the work actually happens

Documenting or automating a poorly designed process does not necessarily improve it. We start by looking at the work itself: who decides, where it changes hands, what people are rewarded for and what holds it up.

Discuss a challengeExplore our approach
Aerial view of a water treatment works

How a process is written, and how it is actually done

The gap between the two usually explains more than either one does on its own, so we look at six things that shape how the work is actually done.

As written
  1. Request
  2. Design
  3. Check
  4. Approve
As done
  1. Request
  2. Waits for a decision
  3. Design
  4. Handover repeats work
  5. Check
  6. Back for rework
  7. Approve
Schematic only; the six things below explain most of the difference between the two lanes.
DecisionsWho makes each decision, on what information, and how long the work waits for it.
HandoversWhere work passes between people, teams or organisations, and what is lost or repeated at each one.
IncentivesWhat people are measured and rewarded for, and whether that pulls in the same direction as the process.
DependenciesWhich tasks rely on others, inside and outside the organisation, and which of those links are fragile.
ConstraintsThe resource, approval or information that limits how much work can flow through.
FeedbackHow the organisation learns that something has gone wrong, and how quickly that changes what happens next.

How the work runs

There are four stages, carried over from our process work, and the emphasis throughout is on making the change last.

  1. Process analysisA close look at the processes as written and as done, with the people who carry them out.
  2. Redesign and standardisationRedesign around the constraints that matter, drawing on your own processes or on the Synaform standard process library, whichever fits better.
  3. DeliveryEmbed the process where the work happens, in Project:OS or in the platforms you already use.
  4. AssuranceCheck that the work is being done as intended, and that the process still makes sense as circumstances change.

Where a redesign has consequences that are hard to judge, such as moving a decision earlier or changing how work is batched, we can test it first with systems modelling and simulation. Where the redesign touches a whole programme's governance, it connects to our capital programme control solution.

Using the knowledge you already hold

A great deal of process knowledge sits in old project folders, and in spreadsheets that long ago grew beyond their first purpose.

Spreadsheets the business relies on

Spreadsheets that started as a quick fix and became something the business depends on can be turned into properly organised databases, with the structure and controls a critical record needs.

Linking a process to its evidence

A process can be connected to the evidence that it has been followed. If a process says a document is required at a given stage, we can monitor for it on your Common Data Environment, so the work can be checked rather than taken on trust, and connecting to those sources draws on our data, integration and implementation service.

Questions

Our processes are already written down. Is this still relevant?

Often more so. Having processes documented is not the same as having them followed. We look at what is written down, what actually happens and why the two differ, then work out how to bring them together.

Do we have to adopt your processes?

No. We compare what you already do with our standard process library and use whichever works better for you. Often the answer is a mix.

Do we need Project:OS?

No. We can embed processes in Project:OS or in the platforms you already use.

How do we know the processes are being followed?

That is the assurance stage. We link processes to evidence, so if a process says a document is required, we can monitor for it on your Common Data Environment.

We have years of project data in old folders. Can you use it?

Yes. We can extract information from previous projects so that what was learnt last time is there to use next time. It is useful evidence, but not a precondition of starting.

Related services

Strategic and operational advisoryOperating model and performance questions at leadership level. Systems modelling and simulationTest a redesign before it is introduced. Technology and AI enablementWhere automation helps once the process is right. Data, integration and implementationConnect the process to the records that prove it.

Tell us about a process that is not working

Bring a process that is not followed, a handover that keeps failing or a team that has outgrown how it works.

Start a conversation