This Focused Performance Weblog started life as a "business management blog" containing links and commentary related primarily to organizational effectiveness with a "Theory of Constraints" perspective, but is in the process of evolving towards primary content on interactive and mobile marketing. Think of it as about Focusing marketing messages for enhanced Performance. If you are on an archive page, current postings are found here.
Saturday, January 31, 2004
Estimates and Buffers in Critical Chain (Part 5 - Using Buffers) -- OK, folks. We're in the home stretch of this series on buffered promises, buffer sizing, estimating, and buffer management in Critical Chain-based project management (CCPM). Putting it together has raised a bunch of other thoughts for your truly, but enough's "good enough," for now; that is, it'll be enough after this final installment on the mechanics of Buffer Management. Let's start with a bit of history on the evolution of those mechanics...
(1) Way back in the early days (1992-97) of CCPM, Buffer Management started with a simple (many now say simplistic) tripartite "red-yellow-green" process in which the buffer was divided into three equal parts for the life of the project. If consumption of the buffer was less than 1/3 of it's original size, project health was considered OK (green). As it crossed the 1/3 line into the middle (yellow) third, it was deemed that appropriate action was to "watch and plan" possible recovery actions that would be implemented if the project deteriorated to the extent that the 2/3 consumption (red) line is crossed. The idea of delaying implementation of recovery action was to avoid unnecessary "tinkering" with the system and distraction of the project team.
(2) A refinement of this approach, to catch with the possibility of major problems going too far too quickly, added a watch on the trend of buffer consumption; sort of a SPC-like approach. If the rate of project buffer consumption proved to be consistently faster than the rate of completion of the critical chain, a "yellow-zone" watch and plan state would be triggered. If that trend continued for a number of reporting periods, the developed recovery plan would be implemented.
(3) Later, recognizing the fact that as the project approaches completion, less buffer is required to protect against uncertainty, the original straight division of buffer into thirds - (1) - transformed to a sloping set of thresholds, with larger and larger "green" portions of buffer as the more of the project completed. (note that the slope on a chart can go in either direction -- up or down -- depending on whether your tracking buffer consumption against chain completion or remaining versus needed buffer.)
(4) A variation on the sloping green-yellow-red concept - (3) - replaces straight-line borders with borders that reflect the varying amounts of buffer needed to protect the remaining tasks.
(5) These "fever charts" have also been adapted for quick views into the relative health of multiple projects.
One of the things that seems to vary from implementation to implementation is the positioning of the thresholds relative to the buffer size. The tradition of splitting the buffer into three equal components is strong with consultants and authors who tend to respect the theory associated with avoiding unnecessary tinkering with the project. However, in reality, I have yet to implement the process in which there is not a strong pressure to implement "buffer recovery" actions as soon as they are discovered, and to tell the truth, that's tough to really argue in most cases in which projects are a mix of date promises and ASAP efforts. As a result, sometimes the yellow zone is shrunken or even eliminated altogether.
But this still begs the question as to where the border between green and yellow should be. What I like to recommend is to take advantage of the strengths of the two buffer-sizing processes, sizing the buffer with the "Half-the-Safety" and defining the yellow zone at the "Square-Root-of-Sum-of-Squares" size. This results, in typical real life chains, in a nice comfortable green zone to allow the project to run while absorbing Murphy's Law before the SSRS 85-90% confidence point gets broken. For due-date driven projects, I also prefer a "sloping" approach, as in (2), (3), or (4) above, to allow a healthy project run without distraction or pressure to tinker into it's later life.
(Unfortunately, the CCPM software packages I've worked with recently don't easily mix "Half-the-Safety" with "SRSS" calculations, so therefore require a bit of simple Excel manipulation to accomplish this. That said, setting the green-yellow threshold at about the traditional 1/3 position works more than -- dare I say -- "good enough.")
For that matter, all of the above described buffer management methods tend to be based on the "Olympic Stadium" example; the kind of projects that have promise dates that are being protected by the buffer and buffer management, and that accrue little benefit from considerably earlier finishes. However, when one shifts to an ASAP (the sooner we finish, the sooner we can ring a cash register) project environment, the emphasis also needs to shift -- from the health of buffers protecting not-to-exceed dates to projections of anticipated completion and to the encouragement of focused performer attention for maximum speed with quality. Since many of these usually have some associated "not-to-exceed" date attached to them anyhow, the basics described above can still apply, but with a bit more emphasis is on "when can this get done?"
The original buffer provides an initial range of possible completions. As the project proceeds, learning and experience refine expectations. By performing rolling recalculations of the "buffer required for remaining work" (for which my preference is the more aggressive SRSS method), we get better refinements (narrower ranges) of when we can expect the project to complete. Also, by focusing on the movement of that range in time or the SPC/trend view of buffer consumption, we can be forewarned that things might be going awry, schedule speed-wise.
Projects are exercises in turning uncertain events into reasonably certain promises. The processes common to Critical Chain-based project management, 2-point range estimates, buffered schedules and promises, and buffer management of project execution all explicitly deal with the inevitability of uncertainty, variation, and risk. They can be used to good advantage for protecting promises and realistically projecting project completions.
This concludes this little (???) tutorial on buffers and estimates in Critical Chain environments. A number of auxiliary thoughts and ideas popped into my head as re-reading and writing these installments, which will probably arise in future weblog postings. (One for example, is the relationship of "old wine" PERT scheduling to Critical Chain's "new bottle.") Also, you'll notice that this last installment included some graphics. I might go back at some point and put pertinent pictures in preceding posts as well. I'll let you know if/when I do.
If any of these entries have triggered questions or comments, please use the comment links to submit them so we can turn my monologue into a dialogue.
Frankly, I've always thought that publicizing the "best practice" idea was simply a way to sell conference tickets and books. The problem, as I see it, is that it's not clear what it means for some practice to be "best." Best at what? And by what standard? What's best for me might not be best for you, and so on...
[via bBlog] I particularly like Weiss' eternal maternal question on the application of best practices...
"If Johnny jumped off a cliff, does that mean you should too?"
He comes to a conclusion similar to one that I arrived at a while ago. Case studies, best practices, and benchmarking are good for learning about possibilities, but do not necessarily translate directly to an appropriate solution for your situation. At best, they'll help you play catch-up, but probably won't help you pass your competition.
posted by Frank - Permanent Link -
Friday, January 30, 2004
Lies, Damn Lies, and Statistics -- An interesting definition, considering all my recent stuff about buffers.
"Statistician: A man who believes figures don't lie, but admits that under analysis some of them won't stand up either." - Evan Esar (1899 - 1995), Esar's Comic Dictionary
...and if you're not offended by the kind of words that might earn a radio station a $275,000 fine if the FCC has its way, here's another view of relying on statistics from gapingvoid.
posted by Frank - Permanent Link -
Estimates and Buffers in Critical Chain (Part 4 - Buffer Management Basics) -- In the firstthreeparts of this series on estimates and buffers in the Critical Chain project management methodology (CCPM), the focus was on their development and sizing. In this installment, the subject shifts to using buffers to manage project execution. While, on the surface, buffers appear to be primarily a means to protect a project's schedule promise from inevitable uncertainty, they are also at the center of day-to-day decision-making in a CCPM environment.
Planning and scheduling is about making promises. Managing project execution is about keeping those promises in the face of uncertainty, variation, and risks both identified and unidentified. Once a schedule is developed and commitments are made, we enter the real world of project execution. A plan and schedule are merely models of expectations associated with the project. Reality will create deviations from those expectations as early as day one of the project. These deviations are the both the result and precursors of changing risks and opportunities associated with the project.
As reality deviates from the model of expectations, tasks will take longer or shorter than accounted for in the schedule. As tasks are worked, better understanding of the reality of the project is developed (including potentially significant changes in the details of the project's product). As the project progresses, more becomes known about later tasks as a result of findings in earlier tasks. These variations in performance, new knowledge, and resulting refinements in expectations need to find their way into the understanding of the project and its promises. In a Critical Chain-based project, buffers are consumed or replenished accordingly, acting as shock absorbers designed to protect promises from the unavoidable variation in task performance.
But sometimes those deviations are greater than anticipated. Sometimes, the shock absorbers threaten to "bottom out." Sometimes corrective actions are needed to mitigate the accumulation of anticipated and unanticipated variation. How does one assess the current risk and whether and how to act?
Critical Chain-based risk management and project "control" does not end with building the schedule and making the promises. The full name of the Theory of Constraints solution for single-project management is Critical Chain Scheduling and Buffer Management. Buffer Management is the key CCPM process for monitoring and controlling projects. It provides the basis for ongoing awareness of changing risk and guidance for when that risk suggests a need for action.
The use of Buffer Management is not unlike the use of statistical process control (SPC) in production environments, helping differentiate the impact of common cause variation (related to anticipated, accepted risk in the project world) from special cause variation (unanticipated or unplanned risks). It is based on straightforward methods of assessing both the consumption of buffers relative to project completion or the trending of that consumption, and requires minimal data gathering to facilitate its calculation. As a result, buffer reporting becomes a tool that is usable not only by the project management elite, but also by top management as well as project performers and their managers to assess and appropriately act on risks as they raise their head.
Like Project Risk Management, Buffer Management is a future-facing process. At its core is an approach to updating tasks that eschews emphasis on what has been done or “percent complete” in favor of what matters in terms of the promise – what remains to be done. Just as risks are potential events yet to be encountered, task updating based on estimates of the duration to the completion of active tasks reflect any remaining risks for that task. Similarly other traditional methods of soliciting concerns of risks for future tasks can also be translated to changes in expected durations of those tasks or to insertions of new tasks into the original chains in the project network.
Combining the cumulative previous buffer consumption with the current task’s remaining duration (or new understanding of future work) provides a new, current view of the state of the buffer. Comparing how much buffer remains to the amount of buffer required to protect the project’s promises from the variation expected in the remaining work allows an assessment of the health of those promises. (Technical details of various means of doing this comparison will be covered in Part 5 of this series.)
Risk assessment during project execution can be assisted by determining if buffer remaining is less than buffer needed, or if buffer consumption exhibits a troubling trend. Risk response planning can be based on thresholds of buffer consumption or comparisons of the rate of buffer consumption to the rate of related task chain completion. These thresholds (sometimes taking on the ubiquitous "green-yellow-red" nomenclature) are used to determine whether it is appropriate to act to mitigate the impact of these risks or accept the remaining risk as within the ability of remaining buffer to deal with it. Sometimes it can be even more important to avoid developing and implementing unnecessary corrective actions, especially when those actions require significant time and attention to develop. In that case, awareness of a healthy buffer allows for a comfortable and confident decision to do nothing.
In the development of risk responses, Buffer Management also provides input to how much response is necessary. The implicit understanding of risk inherent in the use of buffers carries through the project by allowing project teams to assess how much buffer is required to protect the due date promise from the remaining work. This allows them to determine how much buffer, if any, has to be recovered when faced with a previously unanticipated risk event, so that the effects on the project promise can be determined, reported, and appropriately addressed.
Before ending this installment of the series, another aspect of Buffer Management "basics" must introduced. Not only is it applicable to the protection of individual project promises; it is also a key to effective Multi-Project Management. In a shared-resource, multi-project environment, there are often situations in which certain resources are called upon by more than one project. The result is what I believe is the question that what project management is all about, "What should I be working on to assure maximum benefit to the organization?" With consistent, portfolio-wide buffer management, the relative state of the individual projects' buffers can be easily compared and "what-if'ed" to provide guidance for determining the right answer to that question.
Look for the next installment in this series, which will dig a bit deeper into the mechanics of Buffer Management, and discuss some implications of the methods of buffer sizing in that context.
Google Vanity -- I've been tops in the search for "Frank Patrick" for a while, but I've just noticed I'm bouncing between page 3 and 4 (at 10/page) for "Frank" and for "Patrick," and somehow, 5 of the top ten entries for "Frank Patrick" refer to me today. Vanity, thy name is Frank. (Now if we could just get rid of those architects Lloyd Wright and Gehry, that little girl Anne, and the cartoon strip with Ernest, not to mention those other New Jerseyans Sinatra and Lautenberg, and while we're at it, there's that St. Patrick guy...)
posted by Frank - Permanent Link -
Friday Follies: Computer Transplant Surgery -- I'm familiar with overclockers and modders from watching The ScreenSavers on TechTV. Some are pretty cool, with high geek-quotient both aesthetically and technically (and well beyond the unfortunately proven limits of my own technical skills), but this one is just sick...
I got a shiny new Apple G5 for Christmas. I loved the case, but I’m no Mac user. So I.... - Get a brand new dual processor G5, then - Rip out everything, - Cut out the back of the case so I can use a PC motherboard, and - Install an Athlon motherboard.
[...] When I showed my friend, who happens to love Apple, he looked sick. He did not say anything to me. He just put his hands on his head and was in shock. I wish I had a picture of that.
[...] It’s a good thing my parents don’t know anything about computers, because I’m sure they would be really angry if they knew what I did. I have to say that I'm happy - I can keep on using XP.
The link includes pictures of the deed in progress. As a voluntary Mac user for almost 20 years now and occasional forced Windows user, all I can say is that this must be the kind of thing that happens when you go off your meds.
Later (2/2/04)...Thanks to Jason's comment, I now find out I was had, as were a whole bunch of other people.
posted by Frank - Permanent Link -
Thursday, January 29, 2004
Upon Cleaning Out My In-box This Morning -- A passing thought...Who needs social nets when we've got friends of friends automatically delivered to our inboxes via email worms?
posted by Frank - Permanent Link -
Estimates and Buffers in Critical Chain (Part 3 - Estimates are Conversations) -- The firsttwo parts of this "tutorial" on estimates and buffer sizing in Critical Chain schedules addressed the use of "open" buffers as an explicit acceptance of schedule uncertainty and several common methods for deriving buffer size. This installment will introduce the recent commentary by Eli Goldratt that triggered the series, and deal with the implications of Goldratt's proposed "Half the Chain" approach to buffers versus the other two, which rely on 2-point range estimates.
In a recent piece in CC@Work (a webletter of Critical Chain software provider Realization), the author quotes Dr. Goldratt on the use of 2-point range estimates (which, with a nod to the nominal confidence levels that they cover, he calls 50/90)...
"50/90 is useless. In projects, no one will ever know what the distribution curve of task duration looks like for any task. Moreover, with chaos all around them, people cannot distinguish between the real variability of a task and the variability resulting from chaos...When implementing CC for the first time, the way to get safeties out of the estimates is to take the current task estimates and cut them in half. As an implementation matures, people get experience in giving tighter estimates and you want to cut the estimates by a number that is less than half."
Let's get the semantics out of the way first. While he has a point regarding the unknowable distribution of possible task durations calling into question the reality of 50% and 90% confidence levels of these estimates, many of us use those numbers (if we do) merely as additional description of "aggressive/average" and "safe/commitment-level" estimates in introducing Critical Chain concepts to a team or organization. The words that most of us put around the concept clearly admit the "unknowable" nature of the estimating process. With it's basis in Goldratt's early work on the subject, "50/90" has, at best, simply become an easy-to-remember shorthand for the 2-point range estimating process that is in common usage in many, if not most, Critical Chain implementations. At worst, it's an unfortunate, possibly distracting carry-over from the early days.
Regarding "real variability from a task" versus "variability resulting from chaos," there is little point at drawing that distinction unless and until the chief causes of "chaos"-driven variability can really be separated out (which partially occurs in successful CCPM implementations). In the early goings of a Critical Chain implementation, they are often both included in the "safe" estimate, at least to the extent the experience and past pain is not overcome by the promises inherent in the training on the approach. The distinction simply doesn't matter regardless of the process used for estimation and buffer sizing. (And anyhow, in execution, the work is going to take as long as the work takes, or is allowed to take, or is forced to take. If the performer behaviors that are the raison d'etre of CCPM are effectively effected, then the organization's learning will allow the recognition of the two sources of variability, but in all likelihood, not before then.)
All that said, 50/90 [2-point range] estimates are far from "useless!" They are the basis for important conversations in the planning process about the risks and opportunities related to the tasks being estimated. The difference between the two estimates highlight opportunities for and potential value of mitigating or even avoiding foreseeable risks associated with the tasks in question. Yes, at that level, they may constitute "noise" in the larger scheme of things if the appropriate work practices are not fully embraced, but there is, in the process, the opportunity to discover meaningful dependencies and to highlight potentially wasteful practices that can be eschewed.
But even more important than the numbers, the conversation that surrounds the range estimating process is important to show the respect for the team...respect for their concerns about the work...respect for their experience...and respect for them as members of the team. Goldratt's recommended practice of "cutting estimates in half" can be perceived as an affront to the team and its experience, and become an obstacle to a smooth implementation of non-trivial "cultural" changes that accompany the implementation of the Critical Chain methodology.
Finally, in the cited comments, he suggests that as "people get experience in giving tighter estimates...you want to cut the estimates by a number that is less than half." How much less? Who determines the necessary experience? When is it appropriate to do this? How much tighter? There is nothing in this "Half the Chain" approach that addresses these questions. At least with the methods that use range estimating, there is a smooth path for tightening or loosening estimates as appropriate and as performers and estimators become accustomed to working in the new environment that CCPM allows.
The citation of Goldratt's opinion continues...
"Along the same lines, advanced statistical analysis to optimize safeties is an exercise in futility. Moreover, since delays propagate across chains in execution (through resource dependencies), buffer sizes should reflect system-level variability, not task-level variability...Buffers should be 1/3 of the total lead-time or half of the length of a chain. This should be consistent across projects. So, next time you are tempted to use 50/90 or some statistical analyses, beware. Simplicity, not complexity, is the answer."
The mention of "advanced statistical analysis" is a swipe at the "Square Root of Sum of Squares" approach. Again, Eli is attacking the idea that the numbers have real meaning as numbers, rather than as views of possibilities. And again, he is assuming that system-level variability is excluded from the range-estimating process while it is very much embedded in the minds of people offering the "safe" estimates.
But to say, by flat out edict, that "buffers should be 1/3 of the total lead-time" regardless of the lesser or greater variation that may be encountered in a project smacks of black-box, top-down, top management versus project manager versus team, command-and-control mindset that is not an appropriate approach to guiding today's project performers (formerly known as resources). Sure, I get a bit nervous when buffers approach 1/4 of the lead time, and yes the 1/3 "rule of thumb" is a good guide for assessing the estimating process, but who is to say that a highly uncertain discovery or problem-solving project shouldn't have a buffer that approaches 1/2 of the lead time?
Introduced appropriately, with a sense of realism about whether the estimates have meaning as specific numbers or as "good enough" views of expectations, and with some minimal training regarding the differences between safe/commitment estimates and aggressive/average estimates, the methods that rely on 2-point range estimates provide as good, if not better (whatever that means) project promises without the buy-in and teamwork drawbacks of the "cut-the-estimate-in-half Half-the-Chain" approach. The "Half-the-Chain" approach may have proven "good enough" in early tests of CCPM, and probably still does technically work, but there is much more to be gained from the conversation that is at the heart of the range-estimating process. That said, you might have noticed the non-meaningful difference in the "Half the Chain" and "Half the Safety" in Part 2's examples. If the buffers are usually the same, and the latter approach is more team-friendly, I'll take the latter every time.
While this discussion might be seen as an interesting "difference of opinion" among Critical Chain practitioners -- actually, I suspect it's a difference of opinion between primarily Dr. Goldratt and most practitioners in the field -- the real concern that it raises for me comes in the message from Realization that closes the piece...
"Realization has introduced "buffering policy" in its software that helps institutionalize consistent buffering. Top management specify how much buffer projects should have, and the software makes sure that projects conform to that policy as they enter execution. In addition, we are seriously considering taking the option of two estimates (50/90) out from our CC Planning module by Q3 of 2004. If you have any feedback or concerns, please write to us at firstname.lastname@example.org."
In the name of "simplicity" such top management policies are troubling for the same "black-box, top-down, top management-driven" concerns I raised above. Yes, there should be a consistent means of planning, promising, and performing projects in an organization. But there doesn't have to (shouldn't) be a consistent absolute buffer proportion across all projects.
While I have no concern that other CCPM-savvy software solutions (cc-Pulse, Sciforma's PS8, and ProChain) will abandon the common sense and teamwork-friendly 2-point estimate processes, the combination of a major player doing so with the "blessing" of Dr. Goldratt can only muddy the waters for the further acceptance and growth of CCPM as it approaches a critical mass of acceptance beyond the early adopters.
I'd be very interested to hear comments from other CCPM practitioners, proponents, or users who might be reading this. Please use the comment link at the bottom of this entry for your thoughts. I would particularly like to hear from users of Realization's Concerto software to see if their possible direction down their proposed path has had any impact on the way projects are planned in your organization. Maybe you can shed a little more light on what they are thinking. If my concerns resonate with other CCPM consultants, educators, and users, you might also want to share your thoughts with them via the email link mentioned above.
Now that I've dealt with the reason for this series with this rant, the next and last part of it will go into more on the interpretation and uses of buffers as well as some thoughts on possible different applications of two range-estimate-based methods.
Using tiny sensors, transmitters and some software, researchers at Sandia National Laboratories have turned personal computers into advanced polygraph machines that they say are capable of monitoring people's emotions and abilities.
Here's how it would work: You're in a meeting, and each person in attendance is hooked up to a computer that's monitoring their perspiration and heartbeat, reading their facial expressions and head motions, analyzing their voice tones and then presenting them with a running account of how they are feeling. This information will also be transmitted to everyone else in the meeting.
Talking too much? A pop-up window appears on the screen to tell you to shut up. Feeling edgy? A message reminds you to calm down. Got a big account or project to assign? Scan the feed to see which employee is feeling the perkiest that morning.
Talk about your micro-management.
One corporate executive who heard about the project [...] asked, "Where do we get the version that tells people they are boring in meetings? Please hurry and send that system to us. A truck full or two should cover us."
Have You Looked in Your Inbox Today? -- In case you're wondering what's going on with your email today, Cnet covers the latest Windows worm, apparently propagating with explosive speed:
The virus--known as MyDoom, Novarg and as a variant of the Mimail virus by different antivirus companies--arrives in an in-box with one of several different random subject lines, such as 'Mail Delivery System,' 'Test' or 'Mail Transaction Failed.' The body of the e-mail contains an executable file and a statement such as: 'The message contains Unicode characters and has been sent as a binary attachment.'
'It's huge,' said Vincent Gullotto, vice president of security software maker Network Associates' antivirus emergency response team. 'We have it as a high-risk outbreak.'
In one hour, Network Associates itself received 19,500 e-mails bearing the virus from 3,400 unique Internet addresses, Gullotto said. One large telecommunications company has already shut down its e-mail gateway to stop the virus.
Once the virus infects a Windows-running PC, it installs a program that allows the computer to be controlled remotely. The program primes the PC to send data to the SCO Group's Web server, starting Feb. 1, a virus researcher said on the condition of anonymity.
A prospect of mine didn't get a proposal I sent recently. We assumed it might have gotten mixed in his spam filter this week, and with the big pile of stuff in there, got overlooked and deleted. If Microsoft doesn't get it's act together, email as a usable business tool will go the way of the carrier pigeon.
"It is a bad plan that admits of no modifications." -- Publius Syrus (ca. 42 BCE)
I think we can all agree with that one.
posted by Frank - Permanent Link -
Food for Thought -- Laurent and Johanna have some tasty tidbits on the role of informal communication and food in team building.
posted by Frank - Permanent Link -
Monday, January 26, 2004
Estimates and Buffers in Critical Chain (Part 2 - Calculating Buffers) -- In the first part of this series, I started with a bit of Critical Chain "buffer basics." Today, we move back a step to describe the various means of sizing these buffers. There are three common methods, all supported in one form or another by most CCPM-friendly project scheduling software solutions...
The earliest proposed method, found in Eli Goldratt's original introductory book Critical Chain, is to take the estimated duration of the chain in question, cut it in half to account for the assumed task-embedded safety, and put half of what was cut back into the promise in the form of a buffer; project buffer if the chain of tasks in question is the project's critical chain, feeding buffers where non-critical chains feed into or merge with the critical chain. This obviously assumes that the original task estimates contain a non-trivial amount of safety within them to start with. For want of a better name, I'll refer to this method of buffer sizing as the "Half the Chain" approach. (The pros and cons of this approach, as well as the others, will be covered in detail in the third part of this series.)
Example of "Half the Chain" -- In a single chain project of ten tasks, with "safe" estimates totaling 200 days, the chain would be cut to 100 days, and half of what was cut -- 50 days -- would be added back as a buffer, for a maximum duration promise of 150 days.
The other two approaches to buffer-sizing start with a 2-point range estimate for project tasks. In both cases, the larger of the two estimates would be a "safe" estimate that the performer would be comfortable committing to, with a confidence level of 80-95% that it will be long enough for the anticipated work. This estimate respects the concerns of the person estimating (and ideally, doing) that anticipated work.
The second estimate is more "aggressive." It is typically described as one with about 50% confidence...half the time it will be beat, half the time it will be missed. I like to ask for an near "best-case" situation when soliciting this smaller estimate, suggesting the performer/estimator approach it with the assumptions that it is the only thing they are working on, that they are protected from interruptions, that all their inputs are ready and of good quality, that their boss is on vacation during the work, and that the task is done with minimal problems. It should be short enough that they're not really comfortable with it as a commitment, but long enough to allow them to consider striving for it (and not just blow it off).
(Note: Some Critical Chain practitioners are uncomfortable characterizing the smaller estimate as "aggressive." Given it's typically median position in the range of confidence levels, they prefer to refer to it as an "average" or "expected" time. All things being equal, I would agree, but all things aren't necessarily equal. I like the "aggressive" nomenclature due to the fact that in overcoming the memory of performance hindered by Parkinson's Law and multi-tasking, the historical "average" times can also be equated too closely with longer estimates as "safe" self-fulfilling prophecies of their experience. Also, considering the common and long-standing use of estimates as commitments, the "average" times that we are looking for are indeed "aggressive.")
It is not uncommon that the ratio of these "safe" and "aggressive" estimates is 2:1 or greater. (That said, if there is no real uncertainty associated with the task in question, they could also be very close, or even equal.)
As I said, the other two approaches to buffer sizing start with these "safe" and "aggressive" estimates. The most common approach is the "Half the Safety" approach. The project network is built and leveled using the smaller, "aggressive" estimates and buffers are sized with half of the difference between the sum of the two estimates for the chain of tasks in question.
Example of "Half the Safety" -- In our previous single chain project of ten tasks, with "safe" estimates totaling 200 days, the solicitation of the "aggressive" estimates result in a total chain length of 90 days.
The safety associated with this chain is 110 days of the 200. With the chain sized based on the "aggressive" 90 days, the buffer is added as half of the safety removed (55 days), for a total maximum duration promise of 145 days.
The third approach to buffer sizing is rooted in the statistical justification for why the other approaches provide a "good enough" buffer, and is known as the "Root Square Error," or more commonly, the "Square Root of Sum of Squares" approach (SRSS). It suggests that the minimum buffer size for a set of tasks that have been described by a pair of "safe" and "average/aggressive" estimates can be derived by taking the square root of the sum of the squares of the differences in these estimates. If the safe estimates are in the 90-95% confidence area, then the buffer size derived by this method should provide similar 90-95% confidence for the promise of the chain. Admittedly this approach makes some assumptions about the distribution of uncertainty and independence of the tasks in question, but still provides a mathematically discussable and reasonably "good enough" view of the minimum buffer size one should consider using.
Example of "SRSS" -- In our previous single chain project of ten tasks, with "safe" estimates totaling 200 days, the solicitation of the "aggressive" estimates result in a total chain length of 90 days.
With the chain sized based on the "aggressive" 90 days, the buffer is added as the square root of the sum of the squares of the differences (37 days), for a total maximum duration promise of 127 days.
The first two methods in the example suggest 50 and 55 days for buffer size (well within the "noise" for total project promises of 150 and 145 days), while the SRSS formula provides a suggested minimum buffer of 37 days for a 127 day schedule. The implications, pros, and cons of these methods will be discussed in the next part of this series.
Friday Philosophy - Edgy Laws -- One of the best collections of serious thinkers on the web is Edge. The social, natural, cognitive and philosophical scientists gathered there is a who's who of modern thought. Every year or so, they pose a question to these folks...big questions like "What questions are you asking yourself? (1998), What is the most important invention of the past 2000 years...and why? (1999), "What's your question? (2002), and others. This year, it's "What's Your Law?" We all know Murphy's Law (Whatever can go wrong, will.), Parkinson's Law (Work expands to fill the time allowed.), and Cole's Law (Thinly sliced cabbage with a tangy mayo-based dressing.). Some of my favorites from this collection take that spirit one step further...
Mark Mirsky - Imagination precedes reality.
Art De Vany - The future is over-forecasted and underpredicted.
Stewart Brand's Pace Law - In haste, mistakes cascade. With deliberation, mistakes instruct.
Stewart Brand's Asymmetry - The past can only be known, not changed. The future can only be changed, not known.
George Lakoff - Frames trump facts.
Howard Gardner - Don't ask how smart someone is; ask in what ways is he or she is smart.
John Horgan's Second Law - Every garbage-removal system—whether Zen, skepticism, or existentialism—generates garbage. If you want to clear your mind, the best you can hope for is to find a system, or anti-system, that removes more garbage than it generates.
Art Kleiner - Every organization always operates on behalf of the perceived needs and priorities of some core group of key people. This purpose will trump every other organizational loyalty, including those to shareholders, employees, customers, and other constituents.
Matt Ridley - Science is the discovery of ignorance. It is not a catalog of facts.
Richard Nisbett - When you have the beginnings of an idea about something, the worst thing to do is to consult "the literature" before you get started to work on it. You are sure to assimilate your potentially original idea to something that is already out there.
Verena Huber-Dyson's Law of Sane Reasoning - Hone your Hunches, Jump, then backtrack to blaze a reliable trail to your Conclusion.
Steven Levy - The truth is always more interesting that your preconception of what it might be.
There's lot's more here if you're interested. By the way, one of my laws is "Resistance is in the eye of the proposer." Another, related to projects, is "No matter what the plan, schedule, or estimate, the work will take as long as the work takes." What's your law?
posted by Frank - Permanent Link -
Thursday, January 22, 2004
Estimates and Buffers in Critical Chain (Part 1 - Why Buffers?) -- Over in APICS' Constraint Management SIG (CMSIG) discussion group (sadly, no web archive available), there's been an interesting discussion on estimates and the determination of buffer size for use in Critical Chain Schedules. On the surface, this can be seen as yet another discussion of the minutiae of a process that is meant to free us from worrying about minutiae. On the other, it can also be seen as an honorable exercise in understanding our preferred and proffered processes in an effort to improve their utility. I see it as an important discussion among TOC/Critical Chain practitioners who help to implement the approach in the real world, especially due to some recent comments from Eli Goldratt on the subject and the potential impact of those comments. But more about that later.
Buffers are the means of explicitly stating the uncertainty involved in a project in terms of impact on schedule or budget. The most common use of the terminology in project management is in the Project Buffer and Feeding Buffers found in critical chain schedules. Feeding Buffers are about protecting the critical chain/path from interference or delay from "non-critical" tasks -- to help "keep the critical critical." and to protect the project promise from the delays associated with integration of activities. The Project Buffer is meant to describe the anticipated range within which a project is expected to be complete, given the understanding of the project at the time of planning (or re-planning). The outer limit of the project buffer is often interpreted as a reasonable "not-to-exceed" promise. The greater the uncertainty associated with the work laid out in the network of project dependencies, the larger proportion of schedule duration we would expect the buffer to occupy.
Depending upon how estimates are derived -- in most cases through a bottom-up, 2-point range estimating process -- they provide the primary basis for sizing buffers. In the discussion I refer to above, Larry Leach, author of Critical Chain Project Management and PMI's frequent Critical Chain trainer, points out that by allocating some of one's estimate to a common buffer,...
A portion estimating the mean goes into the network, and the rest goes into the buffer. Since much of the buffer adds [in a statistical manner], the total buffer will be significantly less than the amount removed from the tasks...simple math. The more you move [from the tasks] to the buffer, the larger the buffer, and the shorter the overall plan.
In this way, buffers are not unlike an insurance pool that, in the aggregate, requires cumulatively less contribution from the individual components to protect against risks that would impact the schedule as a whole. The amount of "safety" needed to promise a project at the same level of confidence is less if the pool did not exist; less than if the safety was spread among the tasks. Larry continues...
If people get hung up on the duration used in the plan part [the network of tasks], they aren't getting it. No matter what number you use there, the probability of that exact duration is exactly the same as any discrete duration number: exactly zero. [...] The only stupid manager is the one who would present any estimate without a buffer. Because, if they promise to make it without a buffer, then I know they are sandbagging, and their estimate is much higher than it needs to be.
One of the major benefits of making promises based on such buffered schedules is that even if details of later aspects of the project are not perfectly clear at the time of planning and promising, "good enough" assessments of that lack of clarity can often be made, and explicitly laid out in the project's plan and schedule. Another benefit is the ability to use the buffers as the basis for assessing the health of project promises without the artificial priorities and undesirable effects that come from relying on task due dates for such purposes.
There are three commonly used approaches to sizing buffers in critical chain schedules. They will be the topic of the next part of this series.
Manager as Permission Giver -- An interesting insight from David Anderson, on the role of "manager as permission giver." One thing I noticed in his examples is that the manager says "should," the developer says "I can't because...," and the manager says "Don't worry about the 'because' -- I give you permission to do what you should despite it." A classic combination of dilemma and reservation.
[Later...] Then again, the "shoulds" might also be subject to permission to ignore as well.
posted by Frank - Permanent Link -
NBC to Repeat 'The Apprentice' Episodes on CNBC -- As someone who watches entirely too much television, somehow I didn't pick up on this business-based "Survivor" clone when it started a couple weeks ago, but I have heard good stuff about it. Now that it's starting again on CNBC tonight, it might be worth a look. And a laugh.
I wonder why business doesn't provide more fodder for small screen drama (as opposed to movies. Or comedy for that matter.
That said, come to think of it, my all-time favorite sitcom -- WKRP in Cincinnati -- was largely a workplace oriented show. Dealing with everything from the sales efforts of Herb Tarlek, to the management of a diverse workgroup running the gamut from Johnny Fever to Les Nessman, to classic marketing promotions that sprang from the head of the Big Guy, that was a great show.
"As God is my witness, I thought turkeys could fly."
If you choose to spend time and money to learn something and then make a decision based on that information, the odds of success should be better than not having obtained that information. You can compare whether its better to get the information or plunge ahead without it.
I've often had problems with this approach, though. When payoffs are potentially very large, small changes in the odds don't make much of a difference if they consume much time. This leads to plans that consume maximal resources, assume maximal risk at all times in order to get to the payoff fastest.
Resources are never sufficient for this kind of effort though. And if one project gets this kind of treatment, every other project gets no resources.
It's all a question of "good enough." But what is "good enough?"
posted by Frank - Permanent Link -
"If one can get the team to vocalize potential risks at, eg, the daily stand-up (is this a 4th question for the group, then?), then that will indeed be a considerable improvement."
People hesitate to "vocalize potential risks" because they are, in many cases, ignored or pooh-poohed because someone doesn't really want to acknowledge them. In less flexible applications of project planning and promising, these risks can be seen as very disruptive, and therefore, are not sufficiently solicited or respected without formal "risk management" processes. One of the benefits that I see in both agile and critical chain approaches to projects is that they explicitly recognize, accept, and embrace the presence of uncertainty in their various component processes.
The reticence to regularly and openly discuss risks in projects with little or no "play" or flexibility in schedules and plans is, in my opinion, rooted in the sometimes laudable, but often foot-shooting desire to "make it so," usually associated with what might be perceived by some as a "plan-driven" bias. Too often this is encouraged and institutionalized by a "do whatever it takes" attitude from management above. The resultant hesitancy to discuss risks is akin to the concern about reporting issues (risks that have come home to roost) in environments in which the messenger is more often shot than not. As such, while my formal agile experience is nonexistent, I've seen much more willingness to bring up risks in CC environments than in environments in which only minimal add-on contingency is kept in the hip-pockets of project managers.
In my critical chain experience, I see several things coming together to encourage open discussion of risk.
First, in planning, the 2-point range estimating process common to CC implementations sets the stage for the acceptance of discussion of risk. The difference between a solicited safe "CYA" estimate and a smaller "aggressive but within the realm of possibility if most things go right and therefore worth striving for" estimate carries within it the seeds of a conversation about risk that can either be addressed at that time or set aside and "accepted" by inclusion in the project's buffer. While the latter represents what is possible, the former respects the concerns of the performer from the get-go on the project, and as such, helps them be open about new concerns as they arise.
Secondly, the very open display of uncertainty in the form of buffers in a CC schedule (along with the near elimination of interim task dates) allows for a willingness to modify future plans due to either new learnings along the way or new risks that might be identified or triggered. Even in cases in which project end promises carry some weight, if there is buffer available to absorb new issues or necessary mitigations, and if everyone in the team and stakeholder group (including indoctrinated/trained top management and project owner classes) knows that things will slip around along the way, it is easier to contemplate the insertion of responses into the plan...and therefore easier to discuss their possible need.
And third, the basis of task status reporting is always in terms of the future -- how much time to achieve the completion criteria of the current tasks. This relieves much of the pressure to justify or defend what has been done in the past and keeps everyone's eyes peeled on the future...where risks reside. The typical weekly "buffer management session" in which such reporting is summarized is all about the impact on future work and promises, and is often augmented by volunteered concerns/risks associated with future deliverables as well as the current work.
Risks have meaning only in the context of goals, objectives, success criteria, and promises associated with a project. A planning and promising process that allows for the fact that Murphy's Law has not yet been repealed also allows for and encourages more open discussion of where that law might apply. Critical Chain does just this in the ways that I've described. I suspect that there are similar characteristics and experiences in agile environments as well.
(Read more on the symbiotic relationship between Critical Chain and Project Risk Management here.)
posted by Frank - Permanent Link -
Tuesday, January 20, 2004
Uncertain Language -- What do these...
- A good chance - Almost certain - Better than even - Definite - Highly probable - Highly unlikely - Impossible - Improbable - Likely - Possible - Probable - Quite likely - Rare - Seldom - Unlikely
...mean to you?
And what do they mean to the people with whom you use them or from whom you hear them?
Critical Chain - Old Wine, New Bottle? -- In the seven years since the publication of Goldratt's Critical Chain (sheez! Has it been that long?), one of the most common comments I've heard about it from seasoned project managers and project management thinkers is that it is "nothing more than old wine in a new bottle." I just heard it again last week.
I've got some argument with this assertion, but I must say, to some degree, there is something to it, as I see many project managers trying to do in an ad hoc manner many of the things that are institutionalized in critical chain-based project environments. I can even point to parallels of pieces of the critical chain approach in PMI's PMBOK Guide. But then, common sense is just common sense. The problem is, common sense is too often not common practice.
Having recently sub-contracted myself out to teach a non-critical chain, PMBOK Guide oriented class in estimating and scheduling, I came to realize that if one takes PERT to its logical conclusion -- something that is rarely, if ever done -- you've got a historical basis for rationally buffered schedules. But like I said, it's rarely ever taken to that logical end. Like much of the body of knowledge associated with project management, it's good practice, just not common practice.
But back to the oenological metaphor...
Old wine Critical Chain-based Project Management may be, but if it's been largely overlooked in the back dusty shelves of the wine-cellar, better it be put in shiny new bottles with modern, informative labels, so that it will be drunk and appreciated.
Successful Projects and Successful Blogging -- The neat thing about this blogging stuff is the ever-widening network of folks to learn (and steal) from. A new (to me) blog that's triggered a recent post and a number of "to-posts" is Jim Berkowitz's CRM Mastery E-Journal, not only for his stuff, but for new (to me) names to whom he links. Case in point, on characteristics of successful projects, he excerpts...
"(1) Successful projects have champions; (2) successful projects have metrics, (a predefined method for calculating ROI); and (3) successful projects begin with a lot of skepticism."
I wonder who Bill will lead me to.
posted by Frank - Permanent Link -
Graphlogging -- Seb asks about "boxes-n-arrows graphing tools." I've probably mentioned this before. If I haven't, I should have. I strongly recommend Inspiration, a package that works equally well on Mac and Windows. The interface is so simple, it's spoiled me against things like Visio (Win) and OmniGraffle (Mac). Its primary market is schoolchildren; hence the nice straightforward interface.
Inspiration exports good-looking gif files as well as more complex sets of linked html pages (Seb, I forgot to mention that in my comment on your blog. All of the box and arrow graphics you've seen scattered around my blog and site were done with Inspiration. It works way more than "good enough" for me.
posted by Frank - Permanent Link -
Tuesday, January 13, 2004
Agile Estimating and Planning (More Critical Chain from Outside the TOC Community) -- If you're planning to attend SD West 2004 (Software Development Conference and Expo in Santa Clara, March 15-19), you might want to check out a presentation by Mike Cohn. According to the session description:
Planning is important even for projects using agile processes such as XP, Scrum, or Feature-Driven Development. Unfortunately, we've all seen so many worthless plans that we'd like to throw them away altogether. The good news is that it is possible to create a project plan that looks forward six to nine months that can be accurate and useful.
In this class we will look at why traditional plans fail but why planning is still necessary even on agile projects. We will look at various approaches to estimating including unit-less points and ideal time. The class will describe four techniques for deriving estimates as well as when and how to re-estimate. We will look at how to use Critical Chain techniques to create a plan that dramatically improves the project's chances of on-time completion. Also discussed will be using velocity to track progress against the plan.
This class will be equally suited for managers, programmers, testers, or anyone involved in estimating or planning a project.
I wish I could be there. Between this presentation and the recent new edition of Death March, Critical Chain-based project management is getting a lot of attention from new sources.
Justifying Process Change/Improvement -- Over in one of the discussion groups in Gantthead, the following question was posed...
"I am working with a well known...company and I have been charged justifying why they should change their current development process. Right now, there is very little documentation and/or metrics. All of the usual problems exist. I know what the obvious benefits are to enhancing their process, but does anyone have anything more detailed?"
"All of the usual problems exist."
What is the total bottom line impact of these "usual problems" and of dealing/living with them?
What is the ballpark cost of delays, rework, delays, CYA activity, delays, managing to conflicting measures, delays, going too far down dead ends too slowly, and delays?
You don't need a lot of "documentation and/or metrics" to do a good enough analysis of the situation. Simply sit with the key stakeholders individually and discuss the "usual problem" that they would put at the top of their hit list -- people are happy to "bitch and moan" about such things, and a lot of info can be gleaned from such discussions. After all, they know the "costs" associated with their pet peeves...all the painful things they have to do as a result of its existence.
Once you've collected the big "undesirable effects" of the current system, they need to become the targets of the new system. That way, everyone involved will have "a dog in the fight" and will see benefit from supporting it. As important as any big number total value is in getting peoples attention, the individual problems solved for the stakeholders will be even more so for assuring buy-in, support, and collaboration. (And just because you "know the obvious benefits" doesn't help them see the benefit in their terms.)
The TOC Thinking Processes provide an approach to such analyses. I've facilitated enough of them to have really come to appreciate the benefits of building buy-in along with the solution itself. Without the former, the latter has little chance.
posted by Frank - Permanent Link -
On the Virtues of Inaccuracy --
"A little inaccuracy sometimes saves tons of explanation." - Saki (1870 - 1916), "The Square Egg", 1924
Death March - 2nd Edition (Promotes Critical Chain) -- A while ago, I pointed to a "work-in-progress" page for Ed Yourdon's second edition of his classic book, Death March. It got my attention particularly due to his appreciation of Critical Chain Scheduling in Chapter 7. Ed's site no longer has the "work-in-progress" chapter downloads. That's probably because it was published in December and is available at Amazon.com.
Darn -- I Can't Enter This Contest! -- From Peoplesoft, a contest in conjunction with Eli Goldratt...
"Manufacturing today is complex. In order to succeed, manufacturers need to find the inherent simplicity amongst all the complexity. Twenty years ago Dr. Eli Goldratt released his highly acclaimed, bestselling business novel, The Goal. The Goal has been the catalyst for many dramatic business transformations, but despite its tremendous influence, there are still organizations who have not truly embraced Goldratt's approach to business.
Peoplesoft challenges you to adopt the principles embraced in The Goal to solve a virtual manufacturing scenario contained in an online simulator. Entering this challenge gives you the opportunity to WIN your choice of either a Toyota Tacoma or Celica. This online manufacturing simulator, developed by Eli Schragenheim and Dr. Goldratt himself, can be downloaded onto your computer beginning January 1, 2004.
The winner will be the contestant who makes the most money for the simulated manufacturing company between January 1, 2004 and April 30, 2004. Deadline for entries is April 30, 2004 at 11:59 pm EST. The winner will be announced at PeopleSoft’s Leadership Summit in May 2004."
He also asserted that elation follows the smile, not the opposite. The blood flow changes caused by contracting the facial muscles in the smile alter cerebral blood flow and cause an emotional change. He extends this reasoning to account for all kinds of other bizarre facial habits associated with emotions -- wrinkled forheads, rubbing one's eyes, hand on forehead, pulling earlobes, licking lips, etc.
And if you need any help getting started with a smile, try this (don't forget to erase) or this.
Or maybe this...
A young executive was leaving the office at 6pm when he found the Chief Executive Officer standing in front of a shredder with a piece of paper in hand.
"Listen," said the CEO, "this is very important, and my secretary has left. Can you make this thing work?"
"Certainly," said the young executive. He turned the machine on, inserted the paper, and pressed the start button.
"Excellent, excellent!" said the CEO as his paper disappeared inside the machine. "I just need one copy."
New Blogroll Entries -- I was cleaning out some older, inactive, or radically changed links from my blogroll (that list of folks I either subscribe to or at least frequently read, found over in the right hand column, below the "best of" list and the "bookshelf"), when I noticed a couple major oversights. Newly added to the blogroll, but familiar via links to their work, are Dave Pollard and Jim McGee. Check them out. They have more to say than just the things for which I point to them in this venue.
posted by Frank - Permanent Link -
Thursday, January 08, 2004
Best Sellers Q403 -- The following is a list of Amazon items purchased by the community of my weblog and site readers during the last quarter of 2003. While most have been discussed in these pages or listed in my "bookshelf," there are a few new ones as well that might be of interest (which I've noted).
Thanks for supporting my blogging efforts through the use of my Amazon links for your purchases. I'm using the minimal "kickbacks" to add to my reading...which should, in time, add to yours.
posted by Frank - Permanent Link -
Promises and Prescriptions - The Article -- If you happen to subscribe to STQE, a magazine/journal about software, testing, and quality, you might have noticed that with the January/February 2004 issue, they have changed their name to Better Software. And if you peruse that issue's table of contents, you'll find an article on project management entitled Promises and Prescriptions. That same table of contents pulls a quote from the article...
"It's easy to fall into multi-tasking because it sounds like it will make things go faster. It won't. It will only keep people busy -- and unavailable."
Good stuff. I wonder who the author is...
Gee, that name looks familiar. Could it be...?
Yes it could. Thanks to Technical Editor Esther Derby, I've made it on to another set of glossy pages (My first was with an article that introduced Critical Chain to the pages of PMI's PM Network mag. For those of you who don't get Better Software, I plan to put this new one out here on the weblog in serial form. Watch for the first installment in February. (After all, I really should give the "paying customers" first dibs on it.)
(I was going to delay this announcement until closer to February, but Johanna Rothman spilled the beans this morning.)
Cleaning Out the To-Do List -- Back when I was Director of Industrial Engineering at Nabisco's Planters-Lifesavers Division, one of my duties was to deal with the wide range of stuff that my boss (the VP of Operations) kept throwing in my direction to research, review, or report back to him on. Recognizing that he was about as curious and inquisitive and attention challenged as myself, I quickly realized that not everything he passed along to me was really top priority. Rather than go back to him and ask "What don't you want me to do?," I often found myself using my judgment to simply prune my to-do list without action. I rationalized this with the theory that if really was important, he would bring it up again. I never really got burned by doing this, so I guess my judgment was good enough.
Over the past few months, my to-blog list of interesting web-bits has started to get out of hand. So I've applied my judgment and pared it down to a handful that I want to explore more deeply and comment on in depth. This has left a remainder of good points, interesting ideas, and just things that made me go "hmmmm" that, rather than let sit fallow, I'll just toss out here for your consumption in a start-of-the-year cleaning of my weblog backlog...
Now that I've done a fairly decent job of wiping the slate clean, I've got no excuses to procrastinate with some meaty postings, except maybe unless someone hires me for a gig.
posted by Frank - Permanent Link -
"...when I predict project success, I don't assume people, process, or management is the one key to success. I look to make sure the project hasn't already shot itself with inadequately-trained people, bad management, or bad process."
Presentation of Metrics -- In a comment to a recent post, Hal mentions Joe Ely's post on metrics. Worth a peek for the consideration of simplified metrics. Rolling averages are good things, often applied to analysis of trends, which are often far more meaningful than snapshots.
Related to such analyses of trends is what is known as a "fever chart" in Critical Chain and Buffer-managed projects...
...tracking the relationship of buffer remaining to anticipated time remaining on the project. The slanted thresholds between green, yellow, and red statuses reflect that as the project approaches completion, less buffer is needed to protect against uncertainty.
Recognizing the clear value of trend watching, snapshots can occasionally come in handy when comparing the states of different entities; for example, the relative health of projects in an effort to determine whether one deserves special management attention.
This variation of the fever chart nicely summarizes current completion progress and buffer state for a number of projects in varying conditions. Those that have crossed thresholds in this reporting period are indicated by two dots and an arrow. This provides clear, uncluttered focus that allows the quick assessment of a range of projects.
posted by Frank - Permanent Link -
Monday, January 05, 2004
Project Portfolio Management - Call for Comments -- Along with a number of other TOC (Theory of Constraints) practitioners, I'm getting involved in what could be a "blank sheet of paper" development effort for a process to select and prioritize projects in an organization's portfolio of efforts. (If the "blank sheet of paper" approach was good enough for Eli Goldratt to come up with Critical Chain Scheduling and Buffer Management, it's good enough for us. I'd like to solicit input from the readers of this weblog regarding their experience with this subject.
Typical of most such TOC analyses, I'd like to start not with ideas for solutions, but with problems and issues that are chronically faced in developing and managing project portfolios -- the "undesirable effects" of the way that portfolios are managed today. Please use the comment or contact link below to give me your take on the most troublesome aspect of project portfolio management that you would wave a magic wand at if such a wand existed.
What difficulty with project portfolio management is the one you would most like a solution to address?
"If you decide that software customization is required, you've got to realize that, the dilemma discussed in Laurent Bossavit's weblog post is very real. There are two types of programmers in this world; those that believe that customers don't know what they want and those that believe customers do know what they want. But even worse, depending on their mood and most recent experiences, the same programmer will switch from one view to the other...snip...My take on all of this is that it's your (the customer's) responsibility to know what you want."
One thing that seems to be implied in these discussions, but deserves explicit mention, is that, in projects, there is often too strong a distinction drawn between "customers" and "providers/performers/suppliers/etc." Yes, those are their roles regarding their relationship to the output -- the product -- of the project, but what is too often missed is that customers are also project team members -- resources/performers as responsible for a successful (or unsuccessful) outcome as are the technical "builders."
What this requires is an organizational understanding of the above assertion. What this requires are executives and managers that understand the necessity to effectively support/staff important projects (and any project worth doing should be considered important) with whomever is needed for their success.
Any project that does not intimately plan the use of "customers as resources" is doomed to the dilemma of not knowing whether customers know what they want.
posted by Frank - Permanent Link -
"There's an old saying in business: What gets measured is what gets done. What's happening today is the flip side of that. Measurement has become a tyranny that makes sure that nothing gets done.
"I've developed what I like to call the Otis Redding Theory of Measurement, which is named for his song '(Sittin' on) The Dock of the Bay.' In that song, Redding sings, 'I can't do what 10 people tell me to do, so I guess I'll remain the same.' That line sounds as if it could be about companies' misconceptions about measurement.
"Companies have managed to convince themselves that, since what gets measured is what gets done, the more they measure, the more stuff will get done. Last summer, I met a woman who works for a large oil company, and she told me that the company has 105 measures for which she is responsible. So I asked her, 'How many of those 105 measures do you pay attention to?' Her answer? 'None.' Because in the end, she's measuring so many things that she doesn't pay attention to any of them -- 105 equals zero."
Too many measures are not only distracting, but are also the root of debilitating dilemmas. Which measure is more important? How do I make this measure look good without making that one look bad? Measures are either operationally useful, providing guidance on the best use of your time and attention today, or are mere indicators of past performance, and even worse, past performance of local components of the organizational system. There are very few useful measures that fall into the latter category, because only the constraining component relates directly to organizational performance.
On Customer Involvement -- Be careful what you ask for. You just might get it. After all, the role of marketing is not to merely pass along what customers want, but to interpret it into what they need, and then communicate that need to them in a way that they will also want it.
posted by Frank - Permanent Link -
Quoting Business Week Online: "Six months ago, I could find high-level programmers in India willing work for $15 an hour, vs. the $100-plus an hour I was paying Americans for the same work. In only six months, that rate has climbed to $25 an hour in India, while my domestic rates have dropped to around $35-$50. On the last project I bid out, two proposals from India came in higher than domestic contractors. Admittedly, I'm in a very small sector of the larger market, and it's too soon to tell even here whether the trend will last, but I've heard similar reports from other businesses (see BW Online, 12/2/03, 'U.S. Programmers at Overseas Salaries')."
Everything eventually finds its level. And given the outsized gains of us in the US over the last century or so, compared to much of the rest of the world, and considering such disparity as the source of much of what troubles us these days, I'm not so sure this is a bad thing. It's a big pie, and it can be a growing one. Our overall piece will continue to grow, but maybe just not proportionately to those who have been getting by on slivers.
posted by Frank - Permanent Link -
"The most important thing I learned in 15 years could well be the realization that solving someone's problem with code involves listening to that person."
This goes for problem solving without code as well. And as Laurent later talks about when he mentions "joint responsibility" in such an effort, I'd define listening as a two-way proposition.
posted by Frank - Permanent Link -
"Innovation is thinking outside of the box. Growth is accomplished by adapting to an ever larger set of boxes"
Innovation is looking at and addressing the constraints that either keep you in a box, or keep you from growing it.
These constraints are typically perpetuated by conflicts, which are perpetuated by erroneous assumptions or paradigms, which can be addressed using the TOC Thinking Process known as the "Evaporating Cloud." Also known as a conflict cloud or a conflict resolution diagram, this is a logical tool whose purpose is to identify the elements of a conflict or dilemma t facilitate the development of non-compromise, win-win solutions. The process relies on surfacing underlying assumptions which, though initially accepted as valid, may not be so. The invalidation and or replacement of these assumptions "evaporates" the conflict.
Although useful on its own, this technique is also integrated into a Current Reality Tree, because seemingly insurmountable problems identified in the CRT are often due to an underlying conflict or dilemma -- like being stuck between a rock and a hard place. When used in this way, the Evaporating Cloud results in a breakthrough idea which can be tested for its utility and fleshed out into a complete solution.
[Later...] I guess when you don't actually watch the revels on TV, you miss things like Orange Alert Hats (in the background here, too). Hopefully we won't need them to say F-U to those who would try to throw a damper on next year's party.