A client who had been with me in a Results Chain modeling class – recently told me of her challenge getting her internal client to agree on the definition of an outcome. Even though the main focus of everything on the model was toward an increase in a key metric, he refused to define the outcome as “…increased”. He simply wanted to state it as something “to be monitored”. (But he still wanted to see the root initiative take place.)

His fear was apparently – that by stating the outcome as we normally would in a Results Chain – he would be personally committing to that outcome, and he would be held accountable for it! (He was in a public sector organization.)

Validation

The process of requirements validation is highly enhanced when following the above approach. Since processes are organized according to business responsibilities, it is a very straightforward task to identify the appropriate subject matter expert who can ensure that our models do match the business need. It is also a straightforward task to identify the business stakeholder who can approve any particular details – because of the links to necessary business services and desired business outcomes. And as noted above, a Results Chain greatly expedites any such discussions.

This posting is a bit long, but I hope you will find it informative and useful in your understanding and application of Macroscope. You will, at least, see how I apply these concepts in real life!

If one begins requirements analysis by asking the question, “What are the requirements”, the answers are inevitably not about business need, but about desired features of the automated components of the solution.

This is the first in a three-part series. 

“What are the requirements?” When we start by asking that question at the beginning of a systems-solution project, we easily get the wrong answers. And as a result we have a high risk of solving the wrong problem and/or missing the most valuable business opportunities for improvement.