On the importance of definitions

As analysts we're always told to make our requirements SMART - specific, measurable, attainable, realistic, and time-bound. We also keep attributes about our requirements - priority, stability, etc. However, the meanings of "high", "medium", and "low" when it comes to this attributes is often badly defined. For example, "high stability - unlikely to change" isn't a really useful definition.

This blog post looks at a real world example where we tightly defined what a particular attribute meant. The impacts of tightly defining the definition meant that the project workload was reduced by 90%.

Project Background
This project, as with lots of projects out there, isn't one I can give you actual details of what the project was trying to achieve. However, the essence of the problem is that the organization had identified a particular business scenario where they would need to perform many additional processes. Due to the unlikelihood of the scenario ever happening, they decided to determine and document manual processes instead of building a technology solution.

We had approximately 200 process to determine and document.

Levels of detail?
The first step of the project was to determine the scope of all the business processes. Once we did this we added two attributes to each process: level of detail required for the detailed process documentation and level of accuracy required if the process is ever performed. Our initial definition for the level of detail was this:

• Low: the person performing the process requires a low level of detail in order to achieve the outcomes.
  
• Medium: the person performing the process requires a medium level of detail
• High: the person performing the process requires a high level of detail.

It's nice - but somewhat meaningless. I started thinking - what do we really want out of a definition? After some thought I came up with this:

• Precise
  
• Objective (we were having troubles due to other ambiguous things in the project so I didn't want any subjective definition)
  
• Testable

In retrospect, I could have gone with SMART attributes as well as SMART requirements :)

Redefined
Using those rules, I came up with these definitions:

• Low: if the business scenario ever happens, the person responsible for the process can execute the process with appropriate subject matter expert help and no other information but the name of the process.
• Medium: if the business scenario ever happens, the person responsible for the process can execute the process with appropriate subject matter expert help, a list of required input data, where to get the input data from, a list of required output data, and where to send the data to.
• High: if the business scenario ever happens, the person responsible for the process can execute the process with appropriate subject matter expert help, and a complete mapped process using BPMN2.

The unexpectedly great thing about these definitions is that they focused us on what the users of the processes actually needed.

Outcomes
After a couple of weeks of debate, we determined that there were 2 medium detail processes. The remainder of processes required a low level of detail. Rather than requiring four analysts for 8 months to determine and describe processes, we finished with two analysts in a month.

(Yes, I am somewhat proud of this outcome).