Theory of Constraints Handbook - James Cox Iii [100]
6. Monitor “actual to plan” for what causes project cycle time to expand or contract and reduce all sources of variation (in the right order).
How does one reduce variation in an environment where each project and task appears to be unique? Again, one has to understand that variability takes different forms in projects. There are four types of variation that can be addressed in the project environment: project scope, task, iteration, and resource-to-resource.
One major cause of project scope variation (scope creep) is not gaining full consensus on the project scope upfront. This occurs either through not having all of the key stakeholders in the room ahead of time or by not pursuing the correct questions with them. By having the correct participants specify upfront their problems to be addressed by the project, the group can agree on what really needs to be delivered to solve the problems—the resulting project objectives. Additionally, with the right participation and the problem better understood, the correct scope needed is better able to be identified upfront, thus reducing scope creep.
Since tasks in projects are most often unique to the type of work of the specific project and therefore will not necessarily repeat from project to project, we often need to focus on understanding which tasks have the greatest potential for possible variability—the largest spread (longest tails).
Task variability (Fig. 6-16) refers to the difference in time between the task going pretty well (aggressive but possible) and the potential for things to go wrong (highly probable). The larger potential variations can be addressed upfront to minimize their occurrence by inserting predecessor tasks, utilizing different methods, or preventing variability from flowing to the task from an upstream predecessor task.
Iteration variability can affect the ability of a project not only to go faster, but also to be accomplished reliably. In product development, it may be referred to as a loop. “A project may go through the loop multiple iterations—testing, retesting . . . analysis, reanalysis . . . query, requery and so on. It cycles through until we have the results the client contracted us to achieve and- or -until we know everything we need to know.” (Jacob, Bergland, and Cox, 2009, 61). Iteration variability should be identified during planning and checked to see if it is a result of waste due to defects or transportation. If so, try to reduce the iteration. Quantify the impact of the repeatable variation within and across projects for a possible LSS event.
Many in project environments believe that there are significant differences in time taken between skilled resources within a group—resource-to-resource variability. This variability is often reduced when each resource is allowed to focus on a task without multitasking. If resource-to-resource variability remains, capture and address appropriate resource-to-resource variation with mentoring provided during project execution.
At the end of each project completion, the team should perform an analysis of the variability identified before execution versus the variability actually incurred. Categorizing the tasks by which task met or beat their more optimistic (aggressive, but possible) times allows the organization to better establish the times for planning and for protecting against variability in the next project. By categorizing the tasks met or exceeding the highly probable estimate of variability, analysis should be done on the impact of these more variable tasks that require project recovery actions. Which type of variation is hurting the project the most? From which tasks or resource types? Analyze those items that provide opportunity for system-wide lead-time reduction by addressing the variation through LSS events.
FIGURE 6-16 Task variability in a project. ©1991–2010 Avraham Y. Goldratt Institute, LP. All rights reserved.
Leaning Traditional Project Management
Traditional Project Management will need some refinements