The Eighty/20 Process evolved from our deep held belief in the 80/20 rule, or as it is sometimes called Pareto’s Principle. For anyone who has not heard of this rule it can be applied to many things, but in this case it suggests that a company can get 80% of the results from 20% of the effort. Adopting this rule at every level of our process has had a massive impact on the overall success of our customers.
The Eighty/20 methodology has a number of distinct phases:
There is a step, however, that needs to be completed before using the 80/20 rule. That is a process that determines exactly what is to be achieved. The process forces us to think through and clearly document the business problem we are trying to fix and to list all the benefits that will be achieved if successful. This is what I call the Assessment phase. Getting this phase right usually enables us to deliver benefits that impact the strategic success of a company in a relatively short timeframe.
Once there is agreement on the problem, it is the job of the assessment phase to create a clear vision of what the ideal, long-term solution looks like from a high level. In most cases this allows us to break that solution down into number phases called building blocks. The first building block should not only deliver 80% of the benefits, it should also lay down the infrastructure upon which a company can build the ideal solution.
Every penny spent on the assessment phase can pay back a thousand times over. In every new engagement I strongly recommend before doing anything, that each client spend at least two days with us evaluating where they are, what their problems are and where they want to go. Assumptions made at this stage can be disastrous so it is important to talk to someone who knows what questions to ask and what information is important. There is a great temptation to rush in with a preconceived idea and a half thought out solution, but experience has taught us that there is no such thing as a one size fits all approach to scheduling.
Once the overall objectives have been agreed on, then a full understanding of the gap should be documented showing where a company is and where they want to be. This document needs to detail how the current systems work with a clear description of their limitations.
As you explore the possibilities, ideas will start to crystallize into a clear vision of what the business solution will look like from a high level.
Eighty/20 Design Phase
At this stage the consultant will deliver the Detailed Specifications. This is a document that includes a flow chart of the new process and a detailed list of the data that will be required.
The Scheduling Road Map document is designed to explain at a higher level how the new scheduling system will impact each of the functional areas that interact with the scheduling system. This is really important and must not be glossed over because the real success of your system depends on changing the way companies work together. Those that can’t change will miss out on the really big benefits of your new APS system.
It is the consultant’s responsibility to review both the Detailed Specifications and the Scheduling Road Map with the client. Although it makes no sense to move to the Development Phase without agreement from all the key people, there are times when it might be needed to build a prototype before finalizing all requirements. This is a better option than paralysis by analysis, which can kick in when people are unsure about their options. The prototype allows everyone to get a better understanding of how the new system will work.
Eighty/20 Development Phase
The reason we try to create a working model of the system as early as possible is that sometimes it is very difficult for users to comprehend the scope of the new system until they start working with it. This means they are unable to understand some of their options or anticipate some of the potential problems until they can actually see and touch it.
Either way, like the assessment and the design phases, the development/prototype phase should be accomplished using the Eighty/20 process with the emphasis on getting the fundamental functionality right before worrying about the rest.
A whole book can be written on this subject alone but the important thing to understand is that there needs to be two levels of testing.
Unit testing is designed to test the basic functionality of the software. Ideally unit tests should be identified in the design specs.
Integrated testing is designed to test the functionality of the integrated system and requires the tester to create a documented script for each possible business scenario such as what happens to a new order, a change order, and a deleted order. It is strongly recommended that the users be given responsibility for creating their own test scripts because this is a great way for them to learn how to use the new system and the best way we know of identifying any kinks in the new business process.
Each script should identify the source data, a list of the steps to be performed, and the expected results. Integrated tests are usually performed in a CRP. The idea is to get everyone who will be impacted by the new system into one room where they can interact with each other for a concentrated period of time. The CRP will usually take three to five days.
The implementation phase starts with a “Go Live” plan of all the activities that need to be completed to turn off the old system and turn on the new system.
Whenever possible it makes a great deal of sense to run both systems in parallel. This allows you to validate the results you are getting from the new system against the old system before you turn off the old system.
Like the CRP, the “Go Live” plan should document a number of tests or reports that would validate how well the new system is working. Once all the tests have been validated then the system is considered to be “Live” although the consultant still needs to have someone available at short notice to fix any issues that may arise over the next few months