the 7 steps system development model

So, you need a system?

As 100% of those interested in Business Development (statistics lie!) present with a need “to build a system,” we thought a simple example may be of interest. Based on our understanding of the principle and enhanced with our own experience we believe this example may be of help.

the 7 steps EMyth development model

Some ground rules; EMyth in their lesson Designing Systems, published this model that develops a structure for us to follow, so let us apply this to a simple project. A system isn’t a system until it is documented and forms part of a System Action Plan. Determine the exact outcome you want from the system and document it.

A system has unique workflow to produce a specified outcome. Should you include tasks, or steps, within the system that are not directly related to the outcome, then they are normally steps in another system and should be removed to that system. Don’t think about who will be doing the work, just the work to be done, we will allocate it to people later. Engage the knowledgeable current system owners, as there is gold in “tribal knowledge.” But, don’t document systems that don’t work, evaluate and innovate first.

Quantify to Orchestrate and Orchestrate to Innovate follows the EMyth Business Development Cycle ~ the principle of excellence. From our experience we have found that documenting the steps in a process is not enough. There are a couple of KEY characteristics to be defined in each step to make the process work. Remember, when we are finished with documenting the system, it should be a foundational part of some Orchestration activities that allow management to produce the desired outcome which systems enable ~ reliability, repeatability and accountability. 

  • hiring competence to enact the system
  • measuring competence in delivering the system
  • a defined and working system can form the basis of “good change” “kaizen

specify results and name the system

Our system is called ~ brush your teeth in the morning ~ and the outcome is specified as "WorkReady!" There is no rocket science here and any outcome will be acceptable as long as all the participants are on the same page ~ often here we speak about not building a cathedral when a mud hut would do; so, be very careful of getting into technician mode.

(click to enlarge)

Here, all we are trying to do is visualise the process flow. A good way to do this is to allow everyone who has anything to do with the system to “brainstorm” the flow onto a white board. Don’t stifle innovation, or exclude “stupid ideas”; revise, rub out, scribble down everything. When you’re finished, bring it back to the your own drawing board to complete the documentation of the process.

specifying the tasks

Here lies what we think is the secret! Systems designed for you by others (read World Class – Best Practices) fail to take account of a very important attribute of the system. That is, YOUR expectations and your CUSTOMERS expectations. After all, we are building a system to deliver an enterprise process effectively (low waste and repeatable) and efficiently (reducing time and improving quality). But, we are building it to meet the expectation of the owner ~ YOU the entrepreneur. The importance of this point, is that almost ALL inter-personal disappointments between staff and owner (lament "I can’t get the right people") ~ and enterprise and customer (customer transaction satisfaction) stem from this one aspect ~ expectations were not communicated or known and therefore not delivered.

how do we overcome that?

(click to enlarge)​

Each of the tasks in our diagram must translate to a documented outcome activity in the system. Remember, if the task is not crucial to the delivery of the outcome it belongs in another parallel, preceding or succeeding process. The concept of the project paradigm is important to understand what we are building. If you include everything, it gets too complex, if you build it as one task, the handover ~ the “passing of the ball” of the output ~ sometimes called the Unit of Work* (UoW) can be “dropped” between phases and consume a lot of management (orchestration) energy.

So, we now understand the high-level view so we can begin to put together the UoW* for each of the tasks in the workflow. Within each of these tasks, there are characteristics that are key. Obviously, what we do in the task/phase & what the input and output are is self-evident. Like a factory with a receiving dock with stuff arriving, for the factory to work on, needs to be of a certain quantity and quality. The receiving clerk ascertains this and it becomes a crucial measurement of the factory ~ you can’t work if there is no raw material.

(click to enlarge)​

Just so, a process allows the manager to measure this input that can become the KPI (Key performance indicator) of the process. Once work enters the phase/task it enters the domain of the technician who is enacting (enabling) the process. In this phase we have 4 attributes that will make all the difference to the quality and repeatability of what you are trying to achieve.

ensuring productivity and efficiency

Here is the gold! Without these characteristics of the phase, we would just define the work to be done, the time it takes and the desired output, but we often don’t see the definition EXPECTATIONS. Expectations can be tangible, like those just mentioned, but can also be intangible. The closer you can get to defining YOUR and the CUSTOMERS expectations ~ by the way ~ the customer can be external (paying our salaries) or internal (the owner of the following process). The better the process will deliver.

All activities have some kind of communication required or created, the documentation of the details of the task, internal like number of widgets built, or external to make another aware that the widgets have been built. This aspect provides you with the ability to GOVERN your process and go back in time to ascertain bottlenecks and “dropped balls”. Lastly, the right hand block represents the resources that the operator would need to "use" in delivering this phase ~ like, I wouldn’t be able to perform the task of writing this white paper if I didn’t have my MAC (or some level of skill or training)

conclusion

Seems like a lot of work? Too many details, lets just get on with it?  How will that produce a different outcome to the one you are current trying to improve? Remember the mud hut! What you have just created is an Asset of Value of note ~ someone valuing your company to buy, invest or capital loan will use these systems as a positive discounting factor!

  • a detailed description of a process against which you can;
  • hire and
  • train and
  • measure and
  • which you can monitor “remotely” i.e., when you are not there, so that it continues to produce the expected quality results repeatedly and on-time!
  • most importantly, producing the expectations for the satisfaction of your customer!