“So how does Lean fit with Macroscope?” “Are they compatible or essentially different?” “When would you use one or the other?”
These and similar questions come up on a regular basis. Here are a few thoughts to trigger some discussion.
I had an interesting question recently, from a person who had just been introduced to Macroscope. The person was a specialist in the implementation of products from one of the major ERP vendors. In essence, the question was, “Why can’t I get everything in one place that I need to do an implementation of ___ (Product ‘XYZ’)?” He was asking why it was necessary to go to the Project domain for all the PM material, to the Solution domain for the general -purpose SDLC material, and to the XYZ vendor’s methodology for the product-specific material.
I gave a partial answer right away, but after some more thinking, here’s a more complete answer.
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.)
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.
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.
