An important indicator of progress, directly tied to the workflow of a product as it is being produced is essential. Depending on the process, It may be easily measured, such as a fluid flowing through a pipe or the quantity and rate of finished product. Sometimes it may be possible to take interim samples. However in many environments when using project management to plan and schedule: new product development, non-physical product content such as knowledge work etc., the workflow may not be easily measured. Yet, it is crucial to evaluate the acceptable rate of flow in real time. This is necessary in order to identify and evaluate the cause of unacceptable performance and taking corrective action. And this must be accomplished as soon as possible. Therefore, managers need real time operational metrics to monitor the flow. Existing performance metrics are effective, yet these lagging indicators may lead to poor productivity when the flow is unacceptably disrupted.
MEASURING FLOW
Dr. Ichi Ohno challenged the conventional thinking of the day and the widely accepted practices in production planning and scheduling, developing the Toyota Production System (TPS). It started in Japan, spreading across the world, influencing and adopted by many industry sectors. This was the basis for Just in Time (JIT), KANBAN eventually evolving into LEAN Manufacturing. His vision and contributions had an indelible impact, extending beyond production into many aspects of business.
Meanwhile in Israel another visionary, Dr. Eliyahu Goldratt challenged conventional thinking and practices, developing the Theory of Constraints, (TOC). They both recognized the importance of improving flow, essential for reducing lead times and increasing throughput. Goldratt initially focused on production, developing the Drum, Buffer, Rope (DBR) solution, producing remarkable results. He continued developing solutions for the entire supply chain. Most notably, he challenged the widely used Critical Path project management solution, developing a new breakthrough Critical Chain project management solution, (CCPM).
In execution many of the tasks may not start or finish on the planned dates. So the expected start and expected finish dates of the tasks are now updated, subsequently the actual start dates and actual finish dates are recorded. When the project is started all of tasks should be considered as planned workflow, and remain constant. Then, in parallel, the tasks are separately tracked and considered as actual workflow; when actually worked on or expected to start in the future. Inevitably some of the tasks are pushed to the right and new expected start and finish dates are established. The tasks finishing earlier than planned will also be recorded. It is important to note the original planned schedule will not change. This is a clear indication of the disruption to the original planned workflow. The team will take corrective action based on the information provided by the legacy software risk management tools. The original planned workflow does not change, the actual workflow will reflect what de facto is happening in the project schedule. The question that needs to be asked is which workflow is important? The short answer is both. It is important to visualize the disruption of the workflow, taking action to close the gap between the planned workflow and the actual workflow.
When using Critical Chain methodology the critical chain is defined as the longest chain considering task and resource dependency, whereas the Critical Path is defined as the longest chain of task dependency. In addition when using CCPM the planned task includes the scope of work, the time duration, that is the ‘touch time’ devoid of all safety and assigning the required resources. So, the disruption to the planned task resource availability is more accurately seen by the user. Therefore, due to the inevitable variability in execution, the probability of resources being available when needed are less likely. This a major contributing factor to accumulative workflow disruption. Now we can discuss a possible solution.
Solution
Firstly we need some new definitions to help visualize measuring flow in projects:
Workflow Days – WF Days, this a measurement of the amount of TIME required to complete all of the tasks in the project.
Planned Workflow Days – PWF Days, The summation of the amount of the planned TIME to complete all of the tasks in the project.
Actual Workflow Days – AWF Days, The summation of the amount of the actual TIME to complete all of the tasks in the project.
Workflow Risk – WFR, Measurement of the project risk caused by Workflow disruption.
This can be expressed as follows: WFR = _AWF Days_
PWF Days
A graphic depiction of Workflow
The chart, Fig 1. below Shows the PWF in Orange and the AWF in Blue. Ideally when the project starts they will be the same. However if the project starts later than the planned start date the AWF may be greater than the PWF, this is the case in the chart below. This shows the WFR of the project immediately upon starting.
Fig 1.
The PWF and AWF Days to the left of Today’s Date is historical. The PWF and AWF Days on and to the right of Today’s Date are a prediction, (Fig.1). The team should be focusing on closing the gap in order to reduce the WFR. A separate similar graph with the summation of PWF and AWF of all the individual projects will show the portfolio of projects risk.
Our extensive testing and observation with real projects confirm this is a very useful early warning indicator of risk level in a project. It is possible to automate this thinking into a CCPM solution, observing the increasing level of WFR in real time. Combining with the information provided by the other risk management tools in the CCPM solution you can evaluate the impact this disruption in flow is causing even earlier. One of the breakthrough elements of the CCPM solution was creating time buffers at the high risk areas of the project. The buffer penetration in execution provides real time indication of the impact variability is having on the project. However the WFR adds another dimension. As powerful as the buffers are, they are a symptom of increased risk in the project. The WFR in many instances will highlight the increasing level of risk prior to the buffers being penetrated. Obviously, the earlier the increasing risk is identified, providing valuable information for management to evaluate, the earlier the appropriate action can be taken when warranted.
This can be the basis for developing and automating into legacy project management solutions. The users will then be able to in real time observe the increasing threat level to a project and portfolio of projects.
The capability to observe in real time, the disruption to the workflow and identifying the cause prior to jeopardizing the project commitment brings a new dimension to project management.
Bibliography
- Japan Management Association, Tokyo (1985) translated by David J. Lu (1989) Kanban, Just in Time At Toyota, Productivity Press, Portland Oregon
- Goldratt, E., M.; Cox J. (1984) The Goal: a process of ongoing improvement, The North River Press, Barrington, MA
- Goldratt, E. (1997) Critical Chain, The North River Press, Barrington, MA
Appendix
Fig 2. Portfolio Workflow – Red Background showing Workflow Days exceeding Upper Control Limit. Portfolio is in Chaos. A Green Background acceptable; A Yellow Background; WF is rising.
Fig 2.
Source: Copyright Exepron 2023
Fig 3. Below – Individual Projects Workflow – Green Background project showing Workflow Days are acceptable; Yellow Background project showing Workflow Days acceptable but Workflow Risk is rising; Red Background project showing Workflow Days unacceptable and is now in chaos.
Fig 3
Source: Copyright Exepron 2023
Daniel P. Wals Box 222099 Carmel, CA 92067 Phone: 1.858.945.6756 Email: danpwalsh@aol.com
After a successful career in leading large organizations including Director of Operations for a five billion dollar enterprise and CEO for a $750 million company, in 1994 Daniel Walsh founded Vector Strategies, a Theory of Constraints, (TOC) focused company. He and Vector Strategies, recognized experts in developing and implementing powerful strategies that quickly and dramatically improve market presence and profitability. He has worked with companies in the pharmaceutical, construction, engineering; software, manufacturing, aerospace & defense industries. Numerous Fortune companies are among his clients, including Textron, IBM, Sun Microsystems, Boeing, Lockheed and the U.S. Department of Defense.
Daniel Walsh’s success is based on his extensive experience as an executive and thought leader; as well as his development of innovative and cutting edge systems architecture and value added networking techniques. His focus is firmly grounded in the tenet that real and sustainable improvements in an organization must be measured on how successfully they increase profitability through value innovation. He is the co-founder of Exepron®, a 21st Century cloud based project management software solution.
His current efforts are focusing on developing synchronous enterprise value chain solutions in multiple industry sectors. His research and development are centered on identifying the need to identify and leverage the strategic constraints of the enterprise; which is the key to increasing throughput. This culminated in the development of the Integrated Enterprise Scheduling®, (IES®) solution engine. Initial empirical results from deploying the IES® in a dozen large companies over a five year period have been very promising. Many executives and thought leaders are convinced this may very well be a universal unified scheduling solution required for maximizing the profit of an enterprise wide value chain.
Daniel Walsh is a sought after lecturer, coach, strategic thinker and is a trusted advisor to many senior corporate executives. He currently is a member of numerous corporate boards and a former Chairman of the Theory of Constraints International Certification Organization Board, the global professional organization dedicated to setting the standards, testing and certifying competency in the Theory of Constraints.