Successful Process Mapping

How process mapping can save time and drive down costs in your organisation

Michael Cousins PhD, FCQI, Managing Director of Triaster Limited is the primary author, In this article he has simply tried to pass on the insights, wisdom, experience and understanding that Triaster’s staff and customers have displayed to me over the years. If there is anything in this report which you feel is valuable, then I would like to thank these same staff and customers on your behalf, for it is to them that any thanks are due. Any mistakes are purely my own.

If we want people to use processes, we have to make it easy for them to do so.

We need to place the processes they need at their fingertips. We need to make it as easy for them to find and use a process as it is to find a file in their e-mail or on their hard disk, otherwise, they will use other information sources instead.

But to organise process-related information in such a way as to make it easy to find is a challenging task. Processes are multi-functional and multi-disciplined, they span departmental boundaries and involve many different job roles in their execution.

It is important therefore to structure and present processes in a sensible, attractive and easy-to-use way that is relevant to the intended audience. When this is achieved, a Process Library has been created.

Throughout this report the expression “Process Library” is used. This term, first introduced to the industry by Triaster in 2005, means a shared repository of processes and related forms, procedures and working documents that is accessible to all authorised personnel through a browser such as Microsoft Internet Explorer.

There is an example of a Process Library here: Libreea Showcase Library The content of this report is concerned with the production and maintenance of a successful Process Library.

By way of background, Triaster has worked with hundreds of organisations since the early 1990’s to help them capture, share, use and improve their business processes. The purpose of this report is to distil some of the insights we have gained from this experience. In a very real sense Triaster is relaying the direct experience of hundreds of live projects through the words in this report. We have drawn the conclusions we have because of direct observation of what has worked and what has failed to work.

We do not have an axe to grind, and we do not seek to influence or persuade the reader to adopt or agree with any of our findings, we simply offer them as a faithful interpretation of the things we have observed in the field or had reported to us from our customers’ own direct experiences.

We hope that you will find the report stimulating and helpful as you go through the steps required to create success for your own organisation, and we hope that this report may help you save time and avoid common pitfalls.

Understanding the Three Most Significant Factors for Successful Process Mapping

The single most significant measure of success regarding a business Process Library, the one thing that really counts when deciding if all the effort that has gone into producing the library has actually been worthwhile, is the amount of usage or take-up of the information in the library.

Clearly, if a process mapping team has spent months producing the content for the library, it is all for nothing if nobody then looks at the library. On the other hand, if the wider workforce is using the library as a regular reference source, if new employees are being inducted into their job using the processes in the library, if enquiry handling call-staff are directing enquirers to the library as a self-help source of information, then the Process Library is a success.

This is such a key point but it is so often overlooked, especially by IT focused projects. If nobody looks at the library, then the project has been a waste of time and should not have started.

So, if take-up is the key indicator of success, what are the things that encourage take-up, and what are the things that discourage take-up?

There are 3 things you absolutely must get right if you want to encourage take-up of the information in a Process Library:

  • Simplicity
  • Accuracy
  • Accessibility


Suppose the first time a member of staff accesses the library they are looking for information on how to take compassionate leave. They get to the process labeled “Request Compassionate Leave”, and the process has been formally modeled using say UML, it contains every possible branch condition, it contains all the system interfaces and it contains a whole load of (to them at least) irrelevant flags and data fields. The diagram is a mass of information completely obscuring the actual information that person is trying to find. Sure, it has other valuable purposes, but it is not providing useful information to that person because it is too complex for them to understand.

They are unlikely to ever revisit the library.

Complexity is a huge barrier to take-up of process libraries, the more complex the content of the library, the fewer the number of people that can use it. Therefore, simplicity of the mapping approach, consistently applied across all the maps, is vital if take-up is desired.


If on the first attempt to access content in the library, the content itself is out of date or just plain wrong, then the library will lose credibility. If an individual spends the time to use a Process Library, and they then perform that process according to the content of the library, they have a right to expect that the process will work and they will achieve their objective. If however, having performed the process in the defined way, they discover that it does not lead to the intended objective, they will be most unlikely to refer to the library again.

Accuracy of the process is therefore a paramount concern if the library is to become a useful reference source for the staff in the organisation. If the library is inaccurate, it will lose credibility and usage will stay low. As a consequence, the organisation will have to handle process enquiries in the same way they always did, with people having to staff phone lines and explain what is required in order to achieve a desired outcome.

Unfortunately it is all too easy for a process to fall out of kilter with reality; a linked form is out of date, the process is missing specific mandatory steps, the supporting document templates do not contain all of the required fields, an approval step has been removed and so on. Many of these things change on a regular basis in dynamic business environments, therefore, a way has to be found to create and maintain accuracy in the face of constant change.


Suppose the first time a person visits the library they are trying to find the “Request Compassionate Leave” process. They are presented with some top level processes which they navigate through, and they then start to click various buttons in an effort to get to the process of interest. But they don’t manage it. That person will not revisit the library because if a person cannot find what they are looking for from the library the first time they try to do so, they are most unlikely to try twice.

In many ways, modern search engines are setting the standard of expectation here. A person can sit at home and within a few seconds find information on practically anything. If their experience when they come to work the next day is they have to trawl around a library for minutes in order to find something, they will switch off very quickly. The content of the library must therefore be accessible through a range of familiar and useful search and reporting tools, and a well designed library architecture.

How to Create Simplicity

Albert Einstein was a big fan of simplicity, he is reported to have said: “Make everything as simple as possible, but not simpler.”

With a Process Library, the simpler it is, the more likely it is to be used. The art is in making it no more simple or complex than it needs to be in order to be useful.

We need some principles upon which we can build a simple, but useful, Process Library. Here they are:

  • Every process is a transformation from a set of inputs to a set of outputs.
  • An input can’t appear from nowhere, there must have been a process that produced it.
  • If a person spends time performing a process, i.e. producing outputs, there must be some other process(es) or people that use those outputs, otherwise, what’s the point producing them in the first place?
  • The scope boundary of a Process Library is a permitted exception to the last 2 points, i.e. it is necessary to be able to model ‘inputs from nowhere’ and ‘outputs to nobody’ in order to contain the library content within a defined scope.

The essence of a business process is that it transforms one thing to another. A Customer Order is transformed into a Delivered Product. A Supplier Invoice is transformed into a Supplier Payment. A Staff Vacancy is transformed into a New Employee. A process then is defined as:

‘A set of interrelated or interacting activities which transforms inputs into outputs’

Now, please perform a little thought exercise. You will need a pen and a piece of paper, and it will take no more than 5 minutes.

Divide your paper by drawing a line from the top to the bottom at the center of the page.

You now have a piece of paper evenly divided into two columns. At the top of the left column, write “Things I Do”, and at the top of the right column write “Things I Produce”.

Before reading past this paragraph, please populate the two columns with four or five entries in each by asking yourself two questions “What are some of the things I do in a typical working day?” (the left column), and “What are the things I deliver or produce in a typical working day?” (the right column). The entries in the two columns need not relate to each other.

An example is shown below:

Things I Do Things I Produce
Attend meetings Emails
Review emails Reports
Perform audits Sales forecasts
Write reports Meeting minutes
Appraise my staff Database updates

Look carefully at the types of words you have used in both columns.

Can you see that the words you have used in your left column are verbs? And the words you have used in your right column are nouns?

Quite naturally you have differentiated between the things you do and the things you produce using verbs and nouns respectively. And so will everyone else who has performed this exercise, and everyone who works in your organisation and everyone who ever uses your Process Library, because that is the way everybody thinks.

We need a method that reflects this way of thinking, Triaster call it the Noun-Verb Method. Recall that a process is defined as:

‘A set of interrelated or interacting activities which transforms inputs into outputs’

In the Noun-Verb Method:

  • each Input or Output is described using a noun
  • each Activity is described using a verb
  • no two nouns can be directly connected
  • verbs should only be connected rarely (those rare cases when there is no value to the Process Library user in specifying the intermediate output).

To see a (very simple) example of a map that has been developed using this method, please refer to the Triaster Showcase Process Library available here: From Vacancy to Recruitment

The basic discipline of always specifying at least one Output (Noun) after every Activity (Verb), has highly beneficial knock-on effects.

The first major benefit relates to the difference between Activity and Productivity. In the Noun-Verb Method, the verbs represent ‘work performed’. However, a person can perform work all day long and not actually deliver anything of any value! The nouns represent ‘product delivered’, i.e. they explicitly identify the benefit of performing work. So, in the example map referenced above, the first verb “Initiate Recruitment” is in and of itself not at all valuable, in fact, it represents a cost to the organisation. The value of performing the work however is explicitly documented in the output that is delivered, in this case the “Recruitment Brief”. In the Noun-Verb Method, the process author is required to document Activity and Productivity. As such, they are required to understand precisely why a given Activity does actually deliver something of value, and to record precisely what this is. Without the discipline of Noun-Verb, the tendency is to focus very heavily on the verbs, and the process map then simply becomes a list of things people do; it is what people deliver that matters most however, and the adoption of Noun-Verb requires equal focus on delivery.

A second major benefit of explicitly separating out nouns and verbs is that Investment and Return-on- Investment can be modeled. Clearly, the verbs in the process model represent areas of investment; a person has to be paid to perform a task, or machinery purchased and so on. The nouns on the other hand represent the return for making that investment. So, “Initiate Recruitment” might cost £700, and in return for this investment, a “Recruitment Brief” is received. Using the Noun-Verb Method it is possible to perform this analysis on a micro and or a macro level simply by aggregating costs.

A third major benefit comes from the recognition that the verbs in the model often relate to the work people perform, as such, attributes relating to Responsibility, Accountability, Time, Effort etc. are typically stored in the model behind the verbs (to see these attributes, CTRL-click any symbol in the map). The nouns however typically relate to the information sources in the organisation. Typical attributes therefore relate to the applications used to produce or store the output, the location of the template to produce it etc. By separating the nouns from the verbs, the handling of metrics that describe the model is made much clearer, more tractable and more useful.

The characteristics of the Noun-Verb entities are summarised in the table below:

Noun Verb
Productivity Investment
Activity Information (templates, applications...)
Return-on-Investment People (management, responsibilities...)

A fourth major benefit of the Noun-Verb Method comes from the ability to distribute process mapping across an authoring team of any size. The nouns in the model represent the interface between 2 interrelating activities. These activities may be performed by different people, different departments, even different organisations in some cases.

As will be discussed later in this report, the Noun-Verb Method enables you to assign Process Owners to the verbs. The Process Owner takes responsibility for documenting the contained processes. This can be achieved safely however, because they are not permitted to alter the inputs and outputs without reference to the downstream customers of the outputs, i.e. the Nouns that go into and out of the process cannot be altered by the Process Owner, but the process itself can be.

This modular approach to building a Process Library means you can scale the authoring team as makes sense for your organisation and project. This is called Distributed Process Mapping, and it is one of the key benefits of adopting the Noun-Verb Method.

The Noun-Verb Process Mapping Method is a powerful, yet very simple way to document a business process. It has been thoroughly proven in hundreds of organisations to deliver process diagrams that are useful to a widespread, non-specialist workforce, and at the same time to business analysts. The Noun-Verb Method perfectly balances out the need for simple, comprehensible process diagrams that are also at the same time sufficiently detailed to enable the identification and analysis of performance improvement opportunities.

The Noun-Verb method makes everything as simple as possible, but not simpler.

How to Create Accuracy

Correctly assigning responsibility for the production and maintenance of the library content is the way to create accuracy.

Suppose you were giving a presentation to 30 people, and you wanted to capture the name and job title of everybody who attended. You have two choices:

  • Ask everybody to tell you their name and job title, and you then write it down.
  • Pass round a piece of paper, and ask everyone to write their details on the paper.

The first technique has a number of problems associated with it. First off, there is the time aspect. If there are 30 people in attendance, it will be annoying for them if they have to wait while they each call out their name and you then write it down. Secondly, there is the accuracy problem. The likelihood of spelling everybody’s name perfectly is low.

The second method however suffers from neither problem. The responsibility for producing the content of the list of attendees has been distributed to the attendees themselves (who know their names perfectly and only need 2 seconds to write it down), rather than to you, who don’t know their names and will have to spend 10 minutes writing them down. Nothing is delayed, and accuracy is assured (although reading their writing might of course be a new problem!).

A Process Library causes a very similar problem. An organisation that wants its processes mapped has two options available to it:

  • Centralise responsibility for the production and maintenance of the content to a mapping team.
  • Distribute responsibility for the production and maintenance of the content to the business areas that perform the process.

The second option has the following benefits:

  • It is faster (because the work is being spread more widely)
  • It will increase ownership and buy-in.
  • Very importantly, it will be more accurate. But why?

The reason option two will lead to more accurate process maps is because the business areas responsible for performing the process are able to compare, on a daily basis if needs be, the content of the library with the reality of how the process is actually executed. And then bring the library into line with the reality.

A centralised mapping team on the other hand simply does not have the bandwidth to compare the library with actuality at the same frequency as a distributed mapping team. So, what tends to happen in a centralised environment is the library moves further and further from reality because the process changes happen faster than the capacity of the mapping team to update the library.

What tends to happen in a distributed environment is that Process Owners assume responsibility for a small proportion of the library, and they are therefore able to maintain it in-line with reality. The library gets more, rather than less accurate, and as a consequence it becomes an increasingly useful and increasingly referenced resource.

Centralised approaches to process development are however deeply engrained in many organisations, and often with good reason. It is therefore necessary to understand when the centralised approach is most helpful and when the distributed approach is most helpful.

A more detailed review of the centralised model goes something like the following:

  • A Business Analyst (BA) interviews the members of staff that perform the processes.
  • The BA then maps out the processes.
  • The process maps are reviewed by the staff, generally go through correction and review and are ultimately released.
  • Subsequent amendments to the processes are typically triggered through informal change notification when a member of staff notices a discrepancy between the actual process and the one described in the library.

Why is the first step in the above list necessary?

It is necessary because the BA does not know enough about the processes to be able to map them out. So, the purpose of the interviews is to transfer knowledge from the people that perform the processes, and who do have enough knowledge to map them out, to the BA (who does not). Furthermore:

  • The interview takes the time of both the BA and the staff that perform the process.
  • The interview process itself can be a source of inaccuracy, misinterpretation and misunderstanding.
  • The whole process is bottlenecked around the availability of the BA, who for very obvious reasons can only perform 1 interview or draw up 1 process at a time.
  • There is virtually no skills transfer from the BA to the staff.

The reasons given for why this centralised model is used are many and varied, but basically boil down to one of the following:

  • The members of staff do not have the skills to map their own processes.
  • The members of staff do not have enough time to do it.
  • The members of staff are specialists and are not employed or motivated to map out processes.
  • It is difficult to ensure that the process maps are produced to a consistent standard and contain the right type of information to achieve the objectives set for the Process Library unless the mapping is performed by a small team of experts.
  • The organisation as a whole does not have the expertise or confidence to develop a Process Library so has outsourced it.
  • The process mapping activity itself is viewed as non-value adding, though necessary for some regulatory or compliance requirement, and therefore nobody is sufficiently motivated to do anything other than the bare minimum.

Some of these are reasons are strong, and depending on the organisation cannot be overcome. It is in these organisations that a centralised approach is more appropriate. For example, would any of us want an eye surgeon to spend time mapping out a process when they could be spending time making people better? Assuredly not.

If however you work with an organisation that has a learning culture, and that is keen to develop and widen the skills of its workforce, it can make a lot of sense to provide some of the staff with process mapping skills. A person that knows the process, and knows how to process map, can draw the map more quickly than they can be interviewed about it.

When using several members of staff instead of one BA, there is a risk of inconsistency, and a risk of process disjointedness where there should be smooth connectivity, and of course a risk of variance in depth and breadth of content when moving from one process author to the next. How can these issues be overcome?

Well, actually, the question of depth and breadth of content is best left to the process authors anyway. Given that the process is being drawn by a representative of that business area, for the purposes of providing a useful reference source for staff in that area, who better to define the level of content that needs to be in the process map than someone who works in that area?

It is quite common to combine a centralised and a distributed approach by mapping an initial set of processes using a centralised team, and then distributing responsibility for the subsequent maintenance and upkeep of the maps.

Accuracy is achieved and maintained best when the time of the BA is devoted to the task of process improvement, and the administrative and quality support members of staff in the business areas take responsibility themselves for producing their own process maps.

How to Create Accessibility

Search tools are essential and help a person find information in seconds. A Process Library needs good search tools, but that is a technical implementation topic and is not covered any further in this report. Rather, we will discuss how good Process Library architecture creates accessibility.

Process Library architecture is the structuring and presentation of processes in a sensible, attractive and easy-to-use way that the end user can associate with and feel ‘at home’ navigating.

What are some of these structures? The best way to understand is with the aid of some real-life examples. There are many examples of real-life Process Library architectures here:

Please take the time to browse through these examples, there are many excellent designs and innovative approaches drawn from a wide range of sectors and organisations.

It is not possible in a report of this nature to provide an exhaustive survey of architectural approaches. However, there are architectural themes that appear commonly in successful implementations and some of these are outlined below.

Support, core, and reusable processes

A support, core and reusable process architecture is a very useful way of classifying and organising information in a Process Library.

A support process is defined as: “a process that would transfer readily to most other organisations in most other sectors”. A core process is every process that is not a support process.

For example, take the process of “Filming a Nature Documentary” at the BBC. This is a core process because it couldn’t readily be transferred to say a bank. On the other hand “Recruit a New Employee” is a support process because this can be readily transferred across all sectors. Support processes are required for an organisation to function, and core processes are in place to create the outputs required by the customer base of that particular organisation.

Both core and support processes can crop up repeatedly in entirely different parts of an organisation, three examples of which are “Request Holiday Leave”, “Proof-read a Document” or “Appraise a Member of Staff”. These types of process are referred to as reusable processes.

Three great examples of a Support and Core process approach are the National Oilwell Varco, Skanska and ACT libraries shown below (just click on any of the images to see larger images that show more detail).

National Oilwell Varco Skanska and Applied Card Technologies

Project based process libraries

Many Triaster customers have found it useful to construct a library for a particular project or projects. Take for example the Cambridge University library, structured around the delivery of two distinct projects:

Cambridge University

Management system approaches

Many Triaster customers create a Process Library because they want a better management system, or they want to integrate their existing management systems, or because as a consequence of corporate activity several previously independently managed organisations now need a single consolidated management system.

Process Libraries are a great way of organising a management system. Again, some of the Triaster customer approaches are quite explicit in aligning with management systems, and some are more indirect. Take for example the Fugro Process Library - see how the Quality and Health and Safety Management systems are explicitly integrated?

Fugro and Morris & Spottiswood

Note how the entire Morris & Spottiswood library is built around a top level management system model? Architecture can be a surprisingly complex and tricky thing to get right.

Decisions relating to architectural choices are best taken collaboratively with representatives of the intended audience, it is after all these users that will need to work with the library most often.

Process Library Governance

In this report, Process Library Governance is considered in its minimal sense and relates solely to the set of roles and responsibilities necessary to ensure a Process Library is simple, accurate and accessible. The wider questions of process governance are intentionally omitted.

There are four roles:

  • Library Owner
  • Process Owner
  • Process Author
  • Analyst

Library Owner

The Library Owner takes overall responsibility for the content of the library. Their responsibilities are:

  • Ensure all Process Owners, Process Authors and Analysts are trained and able to perform their responsibilities.
  • Assign a Process Author and an Analyst to map the top level processes.
  • Produce a Mapping Policy, and review and update it thereafter as appropriate.

Process Owner

In the Noun-Verb Process Mapping Method, recall there are two fundamental classes of objects; those pertaining to work performed - the Verbs, and those pertaining to outputs produced - the Nouns. Each verb in the top level process is assigned a Process Owner. The wider responsibilities of the Process Owner will vary from organisation to organisation, but specifically with reference to the Process Library, the responsibilities of the Process Owner are as follows:

  • Ensure the Inputs and Outputs of the Verbs they own are correct.
  • Ensure the value of any properties attaching to their Verbs are correct.
  • Ensure the value of any properties attaching to their Outputs are correct.
  • Assign a Process Owner to each Verb in the immediate drill-down (sometimes called among other things the Activity Decomposition, Activity Hierarchy or Work Breakdown Structure).
  • Assign a Process Author to draw the process map resulting from a drill-down.

Process Author

The Process Author’s responsibilities are essentially those of compliance with policy.

  • Each change to a process map is approved according to the project’s approval policy.
  • Each process map is drawn in compliance with the Process Mapping policy.
  • There are no orphans (this is a technical and easily enforced requirement that ensures that once a Process Owner has approved the Inputs and Outputs of a Verb, there is no deviation from this in the rest of the hierarchy).
  • Each Verb in the diagram is assigned a Process Owner.


The responsibilities of the Analyst are:

  • Ensure that every Output from every Verb is either:
  • matched with a corresponding Input to a Verb, or;
  • a terminating output, or;
  • an Input to a process that has yet to be mapped.
  • Ensure that every Input to every Verb is either:
  • matched with a corresponding Output from a Verb, or;
  • a triggering Input, or;
  • an Input from a process that has yet to be mapped.
  • Ensure the value of any properties attaching to External Inputs are correct:

This is a small set of roles and responsibilities, but collectively they are enormously powerful. They remove all the constraints of a centralised mapping method, and at the same time retain all the control and consistency. They are easy to understand and execute for any given Process, Owner or Author and they are the key to safely unlocking the benefits of Distributed Process Mapping.

Put these responsibilities together, and you have complete control. In essence, the Process Owner is responsible for the development of the vertical process hierarchy (increasing levels of detail). The Process Author is responsible for the correctness of any individual map, and the Analyst is responsible for the correctness of the horizontal (often called cross-functional) flow from the triggering Input to the terminating Output.

It isn’t uncommon for a single individual to perform all of these responsibilities, however, with increasing distribution of responsibility comes increasing benefits; better accuracy, faster content development, stronger ownership and increased communication between the players in a process to name a few.

It can also be seen that any process can be linked to any other process horizontally simply by relating the Output from one to the Input of another. Therefore, this breaks a very significant constraint relating to the physical size of the map. Oftentimes a Process Author will need to “snake” or “squeeze” elements onto a process map in order to get the process “on a page”. This reduces aesthetic appeal and increases complexity. With the Noun-Verb method however a flow can simply stop at the border of the page it is on, and continue on the next page. Fabulous! Each map can now be printed easily, is easy to understand and is easy to maintain.

Benefits of the Noun-Verb Method

The purpose of this section is to consolidate a description of the advantages of the Triaster approach, and to define the organisational environment in which these advantages confer real benefits.

For something to be of benefit to a person, it has to do two things:

  • Confer an advantage on them
  • Be an advantage they want to have

The second point is the most overlooked when considering if something is a benefit. For example, a clear advantage of travelling from England to America by plane is that it is a shorter journey time than travelling by ship. But this is only a benefit to travelers who want to get there faster; for people who don’t mind how long the journey takes, travelling faster, although still an advantage, is not a benefit to them because it is not an advantage they want to have.

Necessarily in this article therefore, a presumption must be made that the advantages of the Noun- Verb Process Mapping Method are in some sense desirable, in which case, gaining these advantages represents a tangible benefit. In a very real sense, this also enables a potential adopter of the Noun-Verb Method to determine whether or not the approach is suitable for them (for assuredly there are people who are not seeking these advantages and the method is therefore not beneficial to them). So, what are the advantages of adopting Triaster’s approach to process mapping?

  • The major advantage the Triaster approach confers is that take-up and usage of the mapped processes increases compared with other approaches. Of course, at Triaster, we believe this is a benefit because we don’t understand the value of producing processes if they are not intended to be subsequently referenced or used
  • It enables Distributed Process Mapping - i.e. it enables the responsibility for the production and upkeep of process maps to be delegated to a wider team than just the Business Analysts that traditionally fulfill this function
  • It is simple to understand, train and adopt - i.e. it enables process maps to be produced by people that are not highly skilled or experienced process mappers, indeed, good administrators with zero experience in process mapping are often the ‘best’ process mappers in this context
  • It enables content to be produced and updated quickly, literally within minutes of a change being required it is possible with the Triaster approach to have the change published to a wide audience
  • It enables a widespread, non-technical, non-specialist audience to use the information contained in the process maps

These are the advantages of the Triaster approach. In what environments then are these advantages desirable and can therefore become benefits?

It basically boils down to scale. How large is the intended audience of the processes (for whom are the maps being produced)? And how wide is the scope of the processes? Generally, in an environment where the intended audience is different to the authors, then the advantages of the Triaster approach confer a benefit. And the wider the intended audience, the greater the benefit becomes. Conversely, if the audience is the group of people that draw the maps, or a very small audience in addition to the authors, then the advantages of the Triaster approach do not readily translate into such obvious benefits. Similarly, as the scope of the mapped processes grows past the point where it is manageable by a single author, then the Triaster approach confers increasingly more benefit the larger the authoring team becomes.

Distributed Process Mapping, and the Noun-Verb Method are perfect tools to create Process Libraries; Process Libraries are repositories of process information available at the fingertips of everybody within an organisation.

Top 10 Tips for Success

  1. Identify the underlying business objective
  2. The production of a Process Library represents a sizeable investment of time, energy, focus and money. There must be a good reason why your organisation is willing to make such an investment. What is it?
  3. , Once you know what it is, write it down, and keep coming back to it, refining it and making it more and more representative of the true underlying business objective.
  4. Don’t even think of beginning to produce a Process Library unless the reason for doing so is crystal clear; it won’t work, you just won’t be able to gain the organisational support.
  5. Identify an active senior sponsor and formally initiate a project with them So, you have an underlying business objective.
  6. But this underlying business objective is in competition with every other business objective! And there is only so much an organisation can take on at any one time.
  7. It may well be that the business objective is not sufficiently important to your organisation right now to invest the time, energy, focus and money that will be required.
  8. The way to find out is to identify a senior sponsor who is willing to get behind you and help you create a successful Process Library. And the only reason they will do this is because they want to achieve the underlying business objective.
  9. There is virtually a one-to-one correspondence in Triaster’s experience between successful projects on the one hand, and the continued, active presence of an interested senior sponsor on the other. This senior sponsor must have command over the resources involved in the project so that time can be allocated to perform the necessary tasks.
  10. An active senior sponsor is necessary because in the early stages of a project, investment of time, energy and focus is required. This is shown as the “period of investment” in the “Time to Benefit” curve shown below.
  11. An active senior sponsor is vital to maintain momentum in the early stages and get to the point of breakeven (and for some time after too) where benefits begin to emerge.

Define your intended audience and identify why they need a Process Library and why they will benefit from having one. This is so important.

A Process Library cannot meet the needs of everyone, it simply can’t. A database or workflow designer who needs the Process Library to define new system interfaces has different requirements to the more general, non-specialist, non-technical workforce.

You know what the underlying business objective is. So it should be a straightforward step to work out the people for whom are you producing your Process Library. If it isn’t, then go back to the objective and try to define it in more detail. Or perhaps reconsider if a Process Library is the right way for you to achieve the objective in the first place?

It is not uncommon in Triaster’s experience for the needs of the few to outweigh the needs of the many and this is disastrous. In a company of a thousand people, there will be 990 who need the Process Library to help them do their job, and there will be 10 people who need the Process Library to help them automate systems.

Both requirements are of course entirely valid but should be treated separately. Nutshell it with a business case précis. By now, you should be in a position where you can write down something like the following:

  • OrganisationName wants to [insert the business objective].
  • SeniorSponsorName has agreed to initiate a project to achieve this objective, and to offer on- going support to the project until the objective is achieved.
  • In order to achieve the objective, [IntendedAudience] require access to a shared repository of business processes and related working documents in order for them to [insert reason why they need a Process Library].

Constantly revisit and refine this description, and have it with you wherever you go so that everyone you encounter knows and understands what you are trying to do and why. The more visible this information is, the more likely you are to gain traction behind the project.

Move the “Period of Return” in the Time to Benefit Curve so that it occurs earlier in time

Recall that benefits only really begin to emerge when users use the processes, therefore, go live as soon as possible with a small subset of the processes you intend to map. In other words, start in one area and go through the whole cycle of capturing and publishing processes to the library. Then expand into other areas.

The alternative is to capture a larger set of processes to begin with, and publish them all later in time. This can be a better alternative in some circumstances, but more often than not it is better to publish something as soon as possible.

Continually look for and remove barriers to take-up

Success is take-up. The more people that use the Process Library, the more likely it is that a benefit will result.

What is preventing usage of your Process Library? Constantly ask questions of your intended audience in order to find out. Is it relevant? Is it fast? Can it be understood? Is it maintained? Are people aware of it? Is it referenced from job descriptions?

Survey your organisation so that you can find out the ways in which more value can be added to the Process Library.

Provide good search and reporting tools

You know your intended audience and you know why they need a library. However, they won’t use the library if it takes too long for them to find what they want. So, try to think long and hard about the search and reporting capabilities your users require. Will they want to search by text string (almost certainly), by job role (almost certainly), and by attribute value (again, almost certainly). But what other search tools might they need? What management reports will they want? Very often the answer to these questions will lie in the underlying business objective.

Invest in design and architecture

The library must look great, perform quickly and be easy to navigate. Appearances count – massively.

User expectation of information systems is high, and getting higher. Of course page load times must be less than a second. Of course search results must appear quickly and contain useful information.

But if your end users think the architecture has been thrown together without thought then they will wonder what level of organisational backing there is for the library. If they can see the library doesn’t comply with corporate branding guidelines, they will wonder if it is an official system at all.

Great design on the other hand can help create a user base, just as great content can. Both are necessary, and neither can do it alone.

Try to continually devolve and distribute responsibility for library content

For all the reasons outlined in this document, getting people involved in the production and maintenance of library content can make a lot of sense.

On balance, if you can encourage wider adoption of responsibility for library content production, then you will also be encouraging a wider sense of ownership and increasing the chances of your intended audience using the library.

Integrate the library into your organisation’s ways of working

The Process Library is a resource that delivers benefit only when it is used. And the more it is used the more benefit it delivers.

  • Do your job descriptions contain references to the corresponding processes in the library?
  • Do your training & induction materials refer to processes in the library?
  • Are your staff appraised according to the processes they are responsible for?
  • Do you inform your users when the library is published or new updates are released?

Constantly try to find new ways of driving up usage of the library.


A Process Library is a shared repository of processes and related forms, procedures and working documents that is accessible to all authorized personnel.

It takes time, energy, focus and money to produce a Process Library, so it is important to maximize the chances of the library being successful.

The single most significant indicator that process mapping has been successful is the take-up or usage of the Process Library.

The three things that prevent take-up the most are:

  • Complexity (the process itself may be complex, but if the document describing it is too complex, few people will be able to use it).
  • Inaccuracy (if, having spent the time to reference the Process Library, it contains inaccurate material, potential users will turn away in droves).
  • Inaccessibility (if it takes more than a few minutes, or even a few clicks, for people to find what they are looking for then they will use other less reliable information sources).

Conversely, Simplicity, Accuracy and Accessibility will enable take-up.

The best way to create simplicity is to adopt the Noun-Verb method, or something equally as powerful and easy to understand.

The best way to ensure Accuracy is to delegate responsibility for the production and maintenance of the library’s content to the business areas that perform the processes. This is called Distributed Process Mapping.

The best way to ensure Accessibility is to provide good search & reporting tools, and provide a well designed architecture.

Good Process Library Governance will ensure the library remains Simple, Accurate and Accessible long into the future, thereby delivering increasingly better returns for increasingly less investment.

Used with the permission of Triaster Limited,

Our Partners