Author: Oliver Taylor

With irregularly repeated activities it is difficult to identify how long they take to complete. When analysing an operation, it is important to understand what is really going and how long those tasks and activities take.
Someone who is completing these tasks in amongst numerous other activities is unlikely to be able to provide a clear idea of time to complete.
A way to start accurately recording how long a task is going to take is a sampling. This is the process of recording what the person is doing at set intervals of usually 15 minutes. This can then be analysed and provide quantitative data. This can be viewed as a highly invasive practice making staff feel as if they are under investigation and with short tasks it may be impractical to make regular enough visits to capture timings.
An alternative approach would be to record what is being done without recording who is doing it.
The results of either method can be analysed to get an idea of how long and the difficulties of completing the tasks are.
If you are planning to employ either of the approaches is important that the person being studied is aware of what is being done, why it is being done and how the results will be used.

So, you know exactly what needs to be done. Once, built, delivered and implemented the solution will solve all of the problems perfectly.
You present the solution and are promptly told, that will take too long, cost too much and take up too much space.
Unfortunately, this is the only approach that will work and there is no room in the budget so what can you do.
The solution is to remove some of the requirements. This is often a hard task as the requirements are only there because they are all required.

The way to decide which ones are removed from this phase is called MoSCoW.

This stands for must have, should have, could have and want to have. Each of the requirements should be categorised with one of these labels. This categorisation is a delicate activity as you must take into account not only current but future demands that are being developed in parallel.

Must have are requirements are fundamental and form the minimum usable requirements of the project without which the project is not worth doing.
Should have are almost as important as must have but short term workarounds exist to alleviate an immediate issue.
Could have requirements will not jeopardise current or near-future operations.
Want to have form ideal objectives but should be the first things considered to be omitted in the case of a resource overrun.

Appropriately applying these labels will allow you to more appropriately decide what should be omitted from the current stage, either being omitted or pushed to a later stage of development.

When you are tasked with analysing a business process it is important to understand what the potential user will be using it for, how it will be required to work and what it will be required to do. There are many ways to model, interview and elicit exactly what the result should be.

The best way to avoid ending up with a broken process is by asking the people who are going to use it even going to the point of acting out the process step by step with the team. This will result in any discrepancies being ironed out but it will also result in improving buy-in and support during the role out as the team will feel involved and will know they think it is right for them.

Once you have identified something is not working quite right it is important to understand what it is you are looking at.

When looking at a business process it is important to understand what is around it and what relies on it, failure to do this may stop other portions of a business functioning.

The simplification of a form by removing superfluous information may stop another portion of the organisation working.

To that end I have created the analogy of the plant or the rainforest.

The potted plant sits alone in it’s process receving sunlight and growing within the physical bounds of it’s pot without affecting anything else if it grows more it will not help or limit anything else from growing.

Whereas everything in the rainforst exists in a complex interdependent relationship with everything else. If another process uses more, or less of the resources available your process will be affected. If your process performs more quickly you may create a bottleneck later on or run out of things to process prematurely.

When considering the business process being reviewed you must consider the possibility of external influences, do you need to have the ability to scale up supply very quickly or is it usual to have a quiet season?

It is always worth considering that now is not the worst or best case. Your product may become disliked it may be found your supplier uses dangerous materials or their deliveries are occasionaly late. It is best therefore to examine the past to estimate future events as well as desiging in flexibility to systems.

When exploring a complex process or one that takes time to understand it is important to make sure you do not lose any detail of the project.
It may be worth using a spare wall for this purpose, potentially supplementing labels with photographs or samples of what the process is completing at that point and what state the assets would be in. This would allow you to walk ‘through’ the process and follow along as the work and steps are completed.
This can be coupled with having someone else follow through this process and confirm they come to the same understanding as you at the end. This will allow you to confirm the process is correctly captured and start to explore the ways some of the steps may be improved, simplified or even made more robust.

When reviewing a process it is important to ask why does it exist.

This often involves exploring where the inputs come from and where the outputs are going.

It may be the case that a process was developed organically and no longer accurately maps to those operations before or after it. If this is the case then it may be possible that the process is simply no longer needed.

It is always best to understand where a particular process sits within the organisation.

When analysing a process it is worth asking the question, how important are the edge cases? The answer could be critically or it may be it depends on what they offer.
During your analysis, you may find 80% of the work is spent creating 5% of the output if this is the case this question may become very pertinent. It is important nevertheless to never take this as a guarantee as that 5% may be what leads to a single organisation’s revenue stream or supports the companies philanthropic credentials.
Alternatively, you may need to build into your new process a cap at which effort outweighs potential returns to ensure effort is not wasted.

It is easy to consider the outputs of a process as finished, when that may not be the case.
It is important to confirm it is before designing your outputs.
It would be rather difficult for example if you finish a document and export it as a PDF only for the next process to have to deconstruct this to add details to the same document.
Conversely, if the next process involves sending out a document it may be preferable that your process does save it as a PDF as this may save time, license fees and complexity across the organisation.
This could also apply to any number of things. Packaging an item disproportionately to its journey, saving as an Excel document rather than a CSV or even completing a final check before the final changes are made.

One of the main reasons for completing an in-depth analysis of what is required by the company is to ensure any project that is started has a firm foundation not only in need but also what it wants to achieve. The way the decisions made later on in the project can be made with some certainty allowing for fixed-price agreements to be made with external organisations, therefore, reducing the risk of change unduly affecting the cost of a project.