Process Mapping Logo

Process Mapping - Methodology

Track Record. Trustworthiness. Competence.



These are the goals of the system or changes. These need to be:

* Specific

* Measureable

* Attainable

* Realistic

* Time-bound


These should be recorded, detailed, discussed and evaluated. The end result is a definitive list of goals that the system is intended to meet. Examples could be:

* Reduce data input times by 50% within two months.

* Reduce data entry errors by 75% within three months.

* Automatically process 90% of customer enquiries within six months.

* Reduce manual exception handling by 50% within one month.

* Reduce the average time to respond to customer requests by 60% within three months.

Data to capture

The things that are required in order to both define and measure these Goals are the following:

* A Description (as above).

* An actual current metric, eg minutes or seconds for an average input time, or two working days for a customer response.

* The target for this metric. This could be in terms of a percentage, or an absolute value, but whichever is chosen, the other can be calculated from this. For comparison measurements (ie several different metrics at once), percentages are preferable as a measure.

* An expected timescale for the goal to be reached. This may not be essential to adhere to, but it does provide a target. As long as trends indicate the goal will be met in time, date targets can often be flexible.

* The priority for each Goal. These should be Critical, High, Medium or Low.

* If at all possible, a monetary, or other relevant, figure should be calculated for each Goal. This is often quite difficult, but it does allow for a more persuasive Business Case, and will also facilitate the generation of a Return On Investment (ROI) report.

Note that the value expected for a Goal need not be purely, or even at all, monetary. Non-monetary Goals such as customer satisfaction and reduced risk are very common. It is harder to justify or calculate the ROI, but these are often driven by outside influences, and the system is required in order to meet these Goals. There are also regulatory requirements that must be adhered to, and once again the cost may not be easy to determine.


The exercise of defining all aspects of these Goals is typically very revealing for many stakeholders, and for many differing reasons.

For the Designers, it gives a great deal of focus for the system Design. Often we have requirements, but we are not certain what weight to give to certain features. If we know, for example, that data entry speed is critical, then we may focus on swift data entry and easy form navigation rather than 'elegant' design. If reducing data errors is critical, the focus may be on explaining what data is expected, providing defaults, and validation of all data.

For all stakeholders this exercise is a firm framework for their expectations. There are often (actually, probably always) many conflicting demands made on system design. If the proposer of a feature is forced to define a Goal, and how their desired feature will help to reach that Goal, it will carry a lot more weight. If it cannot support a Goal, it can be seen as a 'desire' and will understandably carry less weight. Most people are reasonable, and will manage to tolerate the exclusion of a desired feature (see below) if they cannot justify it in monetary, or other relevant, terms.