Process mapping versus documentation

What is Process Mapping?

Early on in my career as a consultant I remember explaining my new role to my Brother. “Process Mapping?” he replied, “I’ve had that done to me!”

He worked in the finance industry and told me that someone in the compliance team had called him. “We’ll be mapping your processes over the next month.” He was told.

“Six weeks later I received another call to tell me it had all been mapped!”

While this is, perhaps, an extreme case it demonstrates the lack of engagement typically found in process mapping exercises. Why is this important?

A lack of engagement is a symptom that demonstrates a lack on understanding as to what process mapping actually is. The term process mapping is often used to describe to act of documenting a process. However, here we argue that process documentation is only ONE of the outputs of a process mapping exercise. So what is Process Mapping?

Documenting versus mapping

I think of documenting a process as simply capturing what’s in front of you. You’re just documenting what you see. This is typically what happens when processes are captured through one-to-one interviews. The interviewee is explaining what they do and the analyst captures it. It’s one dimensional.

Mapping a process is more like mapping the landscape. You can see what’s in front of you but you can’t see what’s behind that distant hill. You don’t know if there’s a village, or a lake behind it. Mapping requires you to take many different perspectives to build up a model that describes the landscape.

In the same way process mapping is as much about documenting what isn’t obvious, or clear, to each person involved.

It could be argued that running process interviews with different stakeholders will give these perspectives. The problem is that there is little opportunity to challenge different perspectives. It’s left to the analyst to interpret conflicting views without understanding why they happen.

Process workshops

It’s for this reason we recommend live process mapping workshop as the best way to map a process. Participants can describe how things work together. Differences can be discussed and the reasons for these differences ascertained.

Differences in how work gets done typically develops organically and leads to duplication and loss of standardisation. Sometimes these differences are completely valid. It is very difficult for the analyst to identify which is which without the necessary debate generated in a workshop.

Of course one or two workshops won’t completely map the process. An ongoing engagement with the team is required to ensure process maps are kept up to date and relevant.

Keeping the process relevant

A recent customer explained how they use process maps at their weekly team meetings. “We always open the process and have it displayed on the screen while we talk about the week ahead.” She explained. “We are in a heavily regulated industry and operate across more than 100 countries. We have to fit new regulations into our ways of working on a weekly basis.”

“The process maps help us stick to a common language when we discuss the impact of each new regulation. It speeds up the implementation and reduces misunderstanding. It keeps us all on the same page during constant change.”

Processes are rarely changed but the maps ensure the team focus on the relevant area and are aligned on what to do.

Saving time

A further advantage of the process workshop approach is the time it saves. While each person in the room still needs to be taken out of the business the analyst mapping the process only needs to be there once.

When interviewing the analyst spends time with each participant individually. Then they must analyse the output of each interview and understand the differences, often getting agreement through additional meetings later.

Using Skore app further speeds things up as, unlike using sticky notes and whiteboards, processes can be mapped directly into the tool and shared at the end of the workshop. Therefore there’s no need to spend time mapping the process into a tool afterwards.

Process mapping is more than simply documenting a process in front of you. It’s about understanding the different perspectives that make up how that processes is run in a given organisation. It’s about understanding what isn’t obvious and why it happens. A good process map will be accepted by the roles it describes and will be used to continuously improve.

Contact us to learn more about how Skore app accelerates and improves process mapping.

Project Lifecycle – accelerating change

Project LifecycleWhether you’re embarked on a major organisational change, designing a new business model, a new service offering or implementing a new system, having a solid project lifecycle methodology is essential. Delivering your project requires a strong team and a strong set of tools to support them.

For many people looking at Skore, for the first time, they see a business process mapping, process analysis or a live process workshop tool. For many customers and partners it’s much more than that.

Skore is used to support all the major phases of a change or transformation project lifecycle from discovery to sustain.

Here we describe how it supports each major phase of the project lifecycle and the benefits it brings.

Digital Discovery

Early in a project, or even before it starts, it’s important to understand the current situation. This informs key decisions about what to implement and why.

This is about understanding what works well today and what could be improved. What are the gaps and how do we fill them.

Skore is particularly good at rapidly capturing business processes either in live digital discovery workshops or through one-to-one interviews. In fact it’s possible to import existing business processes from some other tools. Although we still recommend manually capturing existing process documentation as this gives you the opportunity to analyse it at the same time and helps identify those gaps.

Whether you’re implementing a new system or changing a business model you will need to analyse the information you gather in order to understand the requirements. Again the reporting features of Skore help you extract this information and view it in a variety of ways and in different tools. For example you can check out how Skore can work with Qlik Sense to analyse costing information here.


Once you move into the design phase it’s important to engage the right people, the right subject matter experts. Design is about taking your objectives and designing the work the organisation needs to do in order to deliver those objectives.

Skore is perfect for driving workshops with subject matter experts to capture this work.

Once the work has been defined you need to identify the roles and teams that will deliver it. Again, with its built in roles and responsibility modelling (RACI / RATSI) Skore app makes it easy to assign the work to different roles.

With these assignments you can then start to analyse how many people and what skills they need. Skore can help you build your implementation plan by recording which new activities you will start with and how you prioritise the rest.

At this point in the project lifecycle you are ready to proceed to implementation.


Having designed new ways of working in Skore it is very easy to communicate these online. Teams can be trained directly from the system. Processes captured in Skore can be quickly approved, published and shared with anyone in the organisation.

Team members can access the new ways of working from any device and through these they can access any supporting tools and documents. For example, a description of an activity in Skore may also contain a detailed set of steps, as well as a link to the system needed to perform the activity.

This takes away the uncertainty normally experienced by teams undergoing change. Everything they need is provided in a single place. The Skore digital discovery approach ensures they not only have the ways of working, it presents them in context so it helps answer key questions such as “why do we make this change”.

In any implementation it’s rare to find a design that works perfectly. What you need is a design that can be improved quickly as challenges arise. With Skore, improvements to your ways of working can be made quickly and republished for users, all the while keeping a history of previous versions.


Of course any change is not over at the end of the implementation phase. Any good project lifecycle will include sustain activities to ensure the changes remain in place long into the future.

Skore supports sustain by being a living breathing representation of your ways of working. What’s more, users can engage in continuous improvement leaving comments and suggestions against the ways of working.

With all ways of working captured and regularly updated to reflect reality the next change project will be much easier.

Want to learn more about Skore and our supporting tools to help deliver successful change projects? Contact us to find out more.

What can business analysts learn from Bear Grylls?

As a Business Analyst, or Project Manager, you often arrive on a new project and have no idea where to start. Things are a bit chaotic for a few weeks and then they gradually start to fall into place. You all figure out your roles, what needs to be done and the real work can begin.

This frustrates me, it’s wasted time, we should be able to start adding value straight away. I think… what would Bear Grylls do on his first day on this new project?

Dropped into the desert, or a high mountain peak, out in the wilderness. He has to get to civilisation and he has to survive using what he can carry and the environment around him. If he doesn’t figure this out quickly he’s got more to worry about than the failure of the project or the termination of his contract!

The first thing he has to do is assess the situation. This isn’t a random investigation but a structured approach that can be applied to a variety of environments so he can quickly start making important decisions.

He’ll look at the sky, where does the sun rise and set, roughly what time of day is it. He’ll look at the ground, are there signs of a water source, what way does the ground slope, are there visible peaks and so on.

Only then does he start to move toward his ultimate goal… civilisation.

A model for better business performance

Over the past few years I have been educated on, and adopted, an organizational performance model (OPM). This has really helped me make sense of a current situation and focus in on problem areas when I arrive on new projects.

This OPM is used by some of the world’s largest companies to understand business performance and improve results. The great thing about the model is its simplicity, but more importantly how it puts everything into context.

The Organization Performance Model (OPM)

When assessing an existing organization, or process, we look at the relationships between each of these areas. You can start anywhere in the model and move clockwise around it to make your assessment. Although I prefer to start at Business Results as these are the results you are most likely trying to influence. Moving back from here you can start to ask why do we see the results we see.

Once your assessment is complete you can begin the design phase, working anti-clockwise around the model.

Business results

The business results, as mentioned above, is about looking at what results you get today. It’s important to understand these so you can measure how they change as a result of the project.


This describes the values, beliefs and the actual work that people do in the organisation. It’s this that drives the business results. It’s the reality of what people do every day.

Design Elements

The design elements are the structures, such as described processes or org charts, that should influence the business results. Understanding the relationship between this and culture is essential in changing the results. A perfectly designed process is useless if no one follows it.


Design elements should be aligned with the strategy. This relationship is often broken as a result of a poorly defined ,or poorly understood, strategy.

Business Environment

The business environment includes factors often out of your control. It may include the market, the competition and the behaviours of consumers. Understanding the business environment is essential before defining an effective strategy.

A simple assessment of these five dimensions will help you focus on the key areas that need attention and the order in which you tackle them. Once you have the results of the assessment you can start working immediately.

If you would like to learn more about how we use the organization performance model (OPM) above please get in contact [email protected].

When is a process not a process?

When it’s a system!

Modern processes are complicated. Since the transition from manufacturing and Adam Smith’s pin factory the processes we are involved in at work are very rarely ridged, fixed and perfectly repeatable. More often than not they require skill and judgement to execute properly.

What makes them so complicated? We no longer work on a fixed production line where a known quantity of raw materials come in, each actor plays a specific part in the transformation and widgets are produced.

Today we have to take a multitude of inputs, we interact with our environment taking numerous signals and having to make decisions based on the information we have.

And yet most approaches to understanding and visualising process is based on this fixed view of the factory with very clear and detailed responsibilities, inputs and outputs.

Open System Theory

Open System theory describes systems as units that transform inputs into outputs but also recognise that the system has a boundary that is permeable. That is the system interacts with, and is influenced by, it’s environment in many more ways than just the input and output.

What’s key to understanding a system, and why it delivers the results it does, is understanding the relationship it has with it’s environment.

Notice how more traditional approaches to process are focused on the activities that happen. Relationships between activities are normally established based on the order they happen in or the role, or function, that performs them.


System Based Processes

It’s clear that modern processes are more likely to resemble systems rather than the traditional manufacturing process. So how do we model this type of process?

We based our approach on the IDEF0 functional modelling approach. It still describes flows of activities, and who does them, but there is more of a focus on the individual inputs and outputs of each activity. That is we focus more on the relationships between activities.

During digital process discovery it is these inputs and outputs that drive the most informative discussions. The inputs and outputs of each activity are like contracts between activities. Especially when those activities are done by different people. We are not just identifying a handover, as swimlanes help you to, but we also specify what is handed over. And this needs to be agreed between the parties.


What’s more, we can capture roles against each step and tag those according level of responsibility (e.g. RACI). This helps to better understand the boundary. We can use the attachments to gather further relations to other types of information such as business rules, policies, systems and so on.

A reference model for the business

The advantage of this approach is that it builds on the traditional visual approach to process. It takes those important aspects, showing the flow of activities, who does them and in what order, and builds on them by allowing us to understand better how they relate to each other.

This helps us get better agreement among diverse team members. It provides a reference point for discussions and changes and helps to focus in on where improvements can be made.

To learn more about using Skore app modelling try our Process Improvement Course or contact us for a free demonstration. [email protected]

It’s time to take process off the table

“The reason most process led change projects fail is that they ignore culture”

I was listening to this during a programme meeting. Some consultants had come to present to us a sure fire way to deliver a successful programme through a focus on cultural change.

My colleagues around the room were all nodding wisely but this statement made me feel a little uneasy. What is a ‘process led change project’… and just because this person says they ‘fail’, do they really?

The conversation moved on to how this approach worked, a ‘process’ they employed to drive cultural change. There were a lot of group meetings, holding hands and singing and somehow the programme would be successfully delivered.

Don’t get me wrong, there were a lot of useful techniques being discussed to help us engineer a culture for success. However, we came back several times to why process was bad. People don’t engage with it, it’s confusing, it’s too rigid and documenting this stuff takes a lot of time.

Just as we were about to throw the baby out with the bathwater I was suddenly inspired by Daniel Pink’s talks on motivation. I remembered a scene where he talks about the contradiction of money as a motivating factor. He describes how money only acts as a motivator up to a certain point. Then its effectiveness drops off and other means are required to motivate workers. He goes on to say “pay enough to take money off the table”. Then you can focus the conversation on other factors such as empowerment, freedom, flexibility, all the things people aspire to once they can pay the rent and put food on the table.

It struck me that process is the same for a change project. Change almost always results in a change to the way we work, the way we do something at work. Therefore process is an essential part of any change.

Just like workers are unlikely to turn up for work in a profit making business without getting paid, a change project isn’t going to work without understanding how things work today and how we’re going to change them tomorrow.

Conversely too much process (too much detail, too much control, too much analysis) will put people off, constrict them, take valuable time away from them. And ultimately impact the successful delivery of the project.

What we need to do is focus on taking process off the table so that the rest of the programme team can focus on all the other aspects of the project in order to engineer a culture of success.

What does that mean exactly? It simply means we help understand the current state in a clear and simple way (even if that means the current state is incredibly complex). Processes should be captured in a way that all members of the programme team, and stakeholders, can use it to communicate effectively.

If process documentation is difficult to read and understand it becomes a barrier and that means it’s still very much on the table as an issue.

The documentation should be at the right level of detail: too much and it becomes too restrictive, too little and it doesn’t provide enough guidance.

Design and validation of changes should involve key people that will help drive the change. If you want to empower people try to get them involved in the design. You can’t include everyone so make sure there is a clear and simple way that everyone can be heard and provide feedback and ideas.

Finally don’t fall in love with the first version of a process you capture. Make use of the freedom to capture multiple versions of the same process and ask people what works well and what doesn’t. The best ways of working will emerge as others share ideas and feel free to discuss how they do it.

Want to learn more about how Skore app can help you take process off the table? Contact us [email protected]

Image by Fabian Blank – Unsplash

How to choose the right software for your business

We’ve shared before a high level process for implementing software but here I thought it worthwhile spending a bit of time considering how we select the right tool in the first place.

Over the past few years we’ve worked with a number of small to medium sized business implementing new systems. In many cases they have already selected a tool and are simply asking for help getting it setup and running.

It begs the question, if they don’t have time to implement it where did they find the time to choose it?

Choosing the right software is just as important as the implementation. In fact much of the work you do during selection is required for the implementation.

Our experience demonstrates this issue as when asked to implement, without selection, we often discover too late that the new software is missing some critical feature.

Here is our high level process for selecting the right software:

click the image to view the interactive process
click the image to view the interactive process

How it works

It goes without saying that a core part of this approach is the capture of process! But only once you’ve defined the objectives, goals, benefits (perceived and real) and, importantly, budget.

These things are essential up front. They may change as you learn more about the solutions you are reviewing but you need something upfront to frame the next conversation.

Work with a number of key stakeholders to capture and understand the current process. This allows everyone to get their concerns, hopes and desires out on the table and documented. In the context of what they do and what they are trying to achieve.

You now have a heap of really useful information that will certainly make your early selection easier. You can start researching potential solutions. Simple things like budget and a rough list of requirements will help you eliminate those that are too expensive or don’t deliver your basic needs.

Getting into the detail

Now it’s time to get hands on with your shortlist. Before signing up to any trials you want to create a couple more resources. Firstly create a list of scenarios. Work with the stakeholders again to understand what are some common and not so common scenarios they deal with.

Here are some example scenarios from a software company looking to implement a support desk system.

  1. User from a small customer calls in to say they have forgotten their password
  2. User from a medium sized customer calls in to say the system is unavailable, they are upset and losing money
  3. User calls in with a question about a feature that is detailed in the help manual
  4. etc

Discuss how these things are handled today and what rules are applied. I hope you are starting to see that you are gathering lots of really useful information here and keeping a track of all the requirements the team have.

It might be worth using Kano mapping to categorise each requirement in terms of ‘must have’, ‘nice to have’ and ‘delighter’.

This list forms the basis of your comparison chart. Create a matrix with requirements down one side and the shortlisted solutions along the top.


As you evaluate each solution against your scenarios mark each requirement with a score (1-10 typically works well) as to how well it met the requirement.

Once the evaluation is complete you can add up the scores. Don’t forget to make notes about other features you find along the way and the general experience.

Create a report

At the end you should be able to present your findings back to the team with both quantitative and qualitative analysis along with your recommendation for the product.

Explain how the solution stacks up against the original goals and objectives. It’s possible that none of the solutions fit perfectly, especially if budget is constrained. It’s up to the business owner to make the final decision.

I hope you find this useful. If you’d like any further guidance please contact us [email protected]

Project management vs. process is there such a thing ?

I was on a call and we had this discussion about, supposedly, 2 types of processes:

  1. Process as a “recommendation”: process says A-B-C but you can do A-C-B if you think it’s relevant. Maybe it’s good for a project.
  2. Processes as mandatory instructions:  process says A-B-C, you must do A-B-C. It’s best for repetitive processes that need a lot of structure.

Ok… so one is more flexible than the other?

In (1) people use their expertise and experience to know what is best to do and adapt the process to their needs to get the best performance.

In (2) people use their expertise and experience to know that it is best to follow the process in order (A-B-C) to get the best performance.

So to me there is no such thing as a process for “repetitive / structured” activities or a “project process”. We rely on people using the process to know when to adapt and when to comply. The end goal being the same : how can I get the best performance.

We are in the business of creating shared understanding between functions so they can work together in the best way.

Describing a way to do a project as a process helps understanding all the tasks of the project and how they are linked. The role of the project manager is to understand these tasks and coordinate them so they produce what needs to be done.

Create Rich Interactive Procedures

In this video I take you through a demonstration of an example process and procedure portal created in Skore app.

Traditionally Skore app has been focused on process design and analysis with our view on making it as quick and easy as possible. As we worked with more and more teams they told us that creating documentation with the process information was also very important.

Once you’ve designed a great process it is only really great if your team use it. We provided tools to help create documentation such as image export and save to PDF but we really wanted to do something better.

With Skore app you can create ‘easy to read’ process flows that tell you what happens, who does it and what outcome should we expect from each step. Process flows present the steps visually which makes them easy to follow, especially if the process has choices, alternatives and branches.

On to this we can add further information, detailed descriptions, images, video, audio and links to systems and documents. This means that the procedure is no longer just a static document but provides access to all supporting information presented in a clean interactive flow diagram.

Check out our Learn pages to find out how to build Rich Interactive Procedures in Skore app.

The Vicious Cycle of Customer Experience (CX)

Ever wondered what’s going on after you’ve repeatedly had a bad customer experience with the same company?

How do companies allow themselves to come bottom of the pile in consumer research with the most complaints or the longest call waiting times?

Here’s why that happens and what companies can do about it

These are often larger known brands that rely on a large market to provide them customers. In today’s connected world a bad experience quickly spreads across social media and makes it into mainstream press faster than ever.

So how can these brands allow this to happen? We may think they don’t care, they’ve developed a culture that doesn’t respect the customer.

In the most part that’s not true, employees, managers and leaders want to be successful. The company wants to protect its brand and, in the age of the consumer, it knows it must provide the best service it can to do so.

So why does this keep happening over and over again?


We don’t always see the same brands making the headlines, although some are more persistent than others. Generally those that are top of the consumer research ‘worst’ polls won’t be there next year, in fact they are often at the opposite end of the scale.

This shows that most of these organisations take the problem seriously and try to fix it. But how or why do they let it happen in the first place?

These spikes in bad performance are often triggered by a disruptive event. Something unexpected the company wasn’t prepared for.

For example, in a recent interview I had with the Operations Director of a leading energy company he explained that customer growth had taken them by surprise.

“We introduced some new, very competitive tariffs. We expected an increase but nothing like what we saw.” He went on to explain how they made headlines “The number of calls shot up and many calls were dropped due to the sheer volume. This in turn meant customers called in again and things just kept getting worse.”

It wasn’t just call waiting times that were affected. The increase in pressure on the team exposed gaps in their processes. The Customer Service Agents were no longer able to provide the same amount of care to each customer as they normally had time to.

A lot of balls were dropped and this led to a number of complaints making it into local and national press.

Another client I worked with in the telco industry suffered both internal and external disruption. Under two separate strategic initiatives the company created the perfect storm of ‘change fatigue’. The support desk at the centre of these two initiatives was barely able to cope when a major fault erupted on their network.

The call volume spiked and the disruption caused by the two change programmes meant they were unable to get control of the situation and bring the call volume down to a manageable amount over the short term. This led to a number of major customers threatening to move to alternative providers.

In both these cases the short term solution was to throw bodies at the problem. More Customer Service agents Were hired to clear the call volumes and bring things back to normal.

What went wrong

As business returns to normal the old habits return and things carry on until the next major disruption. Everyone breathes a sigh of relief and carries on as they were.

The real underlying problems were acutely obvious just as things got out of control. In those moments immediately before chaos ensues. There is a frantic scratching around to find the answers to questions before we revert to taking the simplest path.

For every individual this simple path can be different. Send it on to your colleague and forget about it. Make something up that sounds plausible. Say what you ‘think’ the truth to be without taking the time to check it. As things get worse we stop asking, we stop seeking answers and just do whatever seems most likely.

When we stop following the process we can’t expect the right outcome to be delivered. In fact we can’t expect the outcome to be the same for each customer interaction.

The vicious cycle of customer experience

When we trip on a staircase the natural reaction is to grab the handrail to steady yourself. But if that handrail isn’t there we grab out at the nearest thing, the wall, a colleague or stranger standing nearby. Like the safety demonstration on an aircraft we aren’t expected to use these things all the time. But they are there whenever we really do need them.

It’s these ‘safety features’ that are often missing in our work that should help us deal with unexpected situations. Like the procedure document created for the last audit and left to collect dust in a filing cabinet, the lifejacket under your seat may as well not be there if you weren’t reminded about it every time you got on an aircraft.

And so this is what happens in a time of crisis. When things start to go wrong and there’s no obvious handrail to grab on to employees will grab whatever they can.

In the examples above this suggests the systems, and therefore the underlying process, were not fit for purpose. They didn’t help the team, they worked against them. This doesn’t fill your team with confidence, especially in times of high pressure.

When this happens it has an impact on employee satisfaction, a key part of delivering a great customer experience. If your front line staff aren’t happy it’s highly likely that will eventually affect customer experience.

Take this together with a worsening situation where the workload is going out of control. Add the fact that customers are becoming more and more frustrated as they are made to wait in endless queues listening to the same maddening holding music over and over and over.

A frustrated customer and an inability to effectively resolve that customer’s problem creates the perfect storm or vicious cycle. The vicious cycle of customer experience is when poor customer experience and low employee satisfaction reinforce each other in a downward spiral.

The vicious cycle of customer experience

The image above shows the various interactions in play that can lead to the vicious cycle. Keeping all these things in balance is important to maintain a healthy team.

Being prepared for disruption

As we have seen, under normal conditions a balance is found in the system allowing customer experience and employee satisfaction to stay relatively constant. However, the more ‘brittle’ that system is, the fewer safety features it has, the more likely balance will be lost in the event of a disruption.

Other elements in the system come into play. Being prepared for a disruption means making sure those elements are working. The better they are set up the more likely you will keep balance in the system.

The system diagram has been simplified and there are other aspects that can affect the balance but this shows those that are relatively easy to deal with. It provides us with concrete actions we can take to prepare ourselves for the worst. It tells us what a handrail should look like.

Ensure processes are well designed
Although a well designed process is only part of the story it is the essential foundation.

  • Are the processes designed to deliver the outcome you expect?
  • Do those outcomes align with business objectives?
  • Is it feasible to deliver that outcome with the resources you have?
  • Do your systems and tools support the process?

Ensure processes are easy to understand
A well designed process needs to be easy to follow. Having your front line staff poring over abstract architectural diagrams, or detailed text based procedure, during a time of crisis is hardly going to make things easier.

  • Can the process be easily read by your front line staff?
  • Have you tested these with a broad sample of employees?
  • Are they unambiguous?
  • Do they provide enough flexibility for employees to make their own decisions?
  • Are they kept up-to-date?

Ensure processes are easy to find
Just like the handrail, processes need to be easy to find so that staff can reach out and grab them easily in times of crisis.

  • How do employees access the processes?
  • Are they easy to find?
  • Have you tested that using User Experience (UX) tools?
  • Do you run regular ‘safety demonstrations’ to help employees remember how it works?

Ensure processes are easy to maintain
If processes are difficult to update then the cost of doing so will quickly become prohibitive.

  • Do you have a system that makes it easy to update?
  • Are processes stored in a single place?
  • Does the process documentation have appropriate governance? (not too much or too little)

Need help with your processes? We can provide a review of your current process documentation based on the above criteria to see how well prepared you are to deal with the next disruptive event. Contact [email protected] for more information. Want to learn more about customer journeys? Check out Instrktiv.

Getting Better at Business Requirements

The approach to process, that forms the basis of skore app, has been used widely in many organizations. It has been particularly successful in implementing large scale ERP and CRM systems. In one example a team, that we have worked with extensively in the past, helped implement an ERP in 6 weeks when the leading Systems Integrators had quoted 6 months!

In project after project we see high levels of success using this approach. A single process model is defined up front and used throughout the project to capture business requirements and communicate those effectively. The documentation is used by the technical team to configure the solution. It is used by the change team to manage the transition. It is used by the business to express their needs.

Yet research, such as this by IAG Consulting, tells us too many projects fail due to poor requirements. Here we explore one reason this happens and introduce our approach to mitigating these issues.

Asking users what they want

A major problem any analyst will find in a requirements gathering project is that the business owners, or users, don’t often know what they want. Of course no one would ever say that outright. You may get the odd “I’m not sure but I’ll know it when I see it.”

Business users are normally full of ideas and thoughts about how a new process or system ‘should’ work. And yet so often, when delivered the product is deemed not fit for purpose. Whose fault was it? The analyst who didn’t interpret what the user asked for correctly?

In any project we must make a number of assumptions and test these as we go. But we still need a start point, and the further down that road we can start the better.

The problem with asking users what they want is that’s actually a very difficult question to answer. These users tend to be immersed in their day jobs. Busy fighting the very fires you’re there to help put out with your new project.

They’ll have lots of ideas, they’ll see lots of things that can be improved all the time. They are probably overwhelmed by things that could be fixed. They won’t have had time to think through which would add more value. What they’d do first and what would have the most impact.

Answering a different question

You approach them when they have little time to spare and other important things that need to be completed. They will not have the time, or energy, to start making sense of what they know. As Daniel Kahneman describes in Thinking Fast and Slow, when asked a question that’s too difficult to answer with an immediate response we default to answering an easier question.

And so your best intention, to gather requirements, through the use of interviews, surveys and workshops can result in a lot of answers to the wrong questions.

Ask users what they do

And here is where a process approach can help. For those already familiar using a Business Process Management System (BPMS) to automate processes this will not come as a surprise. Rather than asking users what they need we ask them what they do. A far easier question to answer and one a lot less likely to be substituted for something else.

As you discuss what happens, and visualize this in a process flow, the users move this information from their minds and out on to the page where they can move on to the next thought. They start to see connections and are reminded of ideas and thoughts they’ve previously had.

The process flow provides context for these ideas and reminds the user of the purpose. While talking about what they do they will find it easier to accurately describe what is wrong. And more importantly provide ideas on how to do it better.

A good process visualization tool will provide a quick and simple way for the analyst to capture these thoughts and ideas against the process. The tool will provide easy reporting so that these important requirements can be reviewed and analysed later.

A further requirement, for an approach like this to work, is the ease with which the user can understand the visualization you are building with them. They will not see and make these connections if the diagram they are looking at is made up of hieroglyphics only an expert will understand.

The process must be simple and easy to understand, providing enough information to accurately describe how things work but not overwhelm or confuse the audience.

Requirements are part of a process

The typical analyst will be familiar with modelling business process flows. However, the use of business process flowcharts tends to be tactical. In the development of a new digital product it may be used to define the flow of data or a user journey.

In the projects where we see the greatest success, process flows are used strategically to guide the project. Hence why they make a good business requirements tool. They are used to describe the work that the organization does and then act as a framework in which we position the requirements for the digital change.

A process diagram is not a deliverable as part of a requirement. Requirements are attributes of the business process.

As such, the process model becomes a point of reference for all stakeholders in the project. It is the model through which the business expresses its needs. The same model the design and development team use to build the solution. And the same model the training team use to manage and support the users once the solution is implemented.

Again this can only be achieved with a process approach that is easy to read and easy to understand for as many people as possible.

A better approach to business requirements

To help others take advantage of this approach we have started to create a general approach to business requirements gathering and definition.

This includes a Business Requirements Canvas, an early stage tool to help understand the purpose of the project, the key processes and any key technical and user requirements. The Canvas informs the project vision and objective, captured in the Strategy Template. And finally the process approach, or IDEFlite, a simple yet powerful approach to process that can be used as the single common framework for the project requirements.

Learn more and download the tools here.