This Focused Performance Weblog is a "business management blog" containing links and commentary related primarily to organizational effectiveness with a "Theory of Constraints" perspective. TOC is noted for its applications in Project Management and Multi-Project Management (Critical Chain) and Operations Management (Drum-Buffer-Rope), as well as in Marketing, Strategic Planning and Change Management (TOC Thinking Processes). If you are on an archive page, current postings are found here.
Thursday, April 17, 2003
Down 'n Dirty with TOC and PM (Part 5) -- In this final set of postings in the series, Hal summarizes with a set of practices for day-to-day consideration, to each of which I'll add my two cents...
"Planning is a practice that runs throughout the life of the project" -- And planning, whether in the initial broad view, or in the later, just-in-time fleshing out of details, is a matter of understanding future dependencies - both necessary logical handoffs and "resource dependencies." For a task to be able to move ahead "as planned," it need both the inputs to the work and the necessary resources to do the work.
"Have an everyday focus on doing what you said you would do." -- If the first point of this summary translates to "plan the work," the second point is to "work the plan" to the extent that Murphy's Law and the limits of clairvoyance will allow. Be prepared to make course corrections to keep things moving, but do so with an eye on where you are going in the end, and how they might impact the work remaining to get there.
"Shield the constrained resources from variations in the release of work to them." -- In making project promises, pay special attention to the constraint as the critical chain of dependent tasks. Doing so will allow you to subordinate the "promise" of other work and its uncertainty in order to avoid having a critical task waiting for input from a non-critical task.
"Conduct the project anticipating that you and the team will learn." -- Just-In-Time planning of details is a way of taking advantage of this learning. And it is best done with a planning roadmap that identifies and lays out the major dependencies and dynamics of resources and work which is supports. Detailed planning can be best performed as needed if there is a framework that has the space (time) to drop in the details, and buffered flexibility to absorb learning (aka deviations from original expectations) that occur en route.
"Measure your planning reliability." -- Accept the inevitability of uncertainty and variation, make your promises with it in mind, and use your experience to address its sources, especially where it provides the biggest bang for the buck -- in the major constraints to your projects.
And unless he's significantly altered his draft version, Joe also summarizes with a few key points...
"A continuing conversation is based in daily workgroup meetings." -- Even when the "workgroup" for a task is a single resource, a bit of daily time to consider risks, requirements, and any adjustments to expectations of the future, and to communicate them as appropriate, is a prudent suggestion.
"Metrics must be made daily" -- Whether, as Joe is talking about, the metrics are about production in unit terms, or translated to terms of time remaining to completion of the effort at hand (the basis for task status reporting in a Critical Chain environment), more frequent is "more better" to highlight deviations from expectations.
"Assessments are the missing link." -- Not only must project systems collect learnings (good, bad, or neutral); mechanisms must be developed to take advantage of them in the future, so that better understanding of sources of uncertainty and variation can be applied to future promises.
"The goal is what drives the assessment." -- The goal is what should drive all actions and decisions. And the best way to understand what is blocking the goal is to understand the constraint(s) of the system that we are counting on to deliver it..
In this series, both Hal and Joe have emphasized resources (and the policies and paradigms we use to manage them) as constraints, and in the down and dirty dealings of day-to-day doings, that is what it boils down to. But my role in this series is to remind you that the reason we're doing the day-to-day work lies at the end of a string of days -- at the end of probably more than one chain of tasks -- and that while dealing with the current and immediate constraints, how we do so must take into consideration their import and impact on the larger constraints of the project as a whole.
I hope you've enjoyed this multi-blog series from the three of us. Feedback will be appreciated.