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.
Wednesday, January 21, 2004
Opening Up About Project Risk -- On the AgileProjectManagement YahooGroups discussion list (free registration required), Alistair Cockburn recently wrote that...
"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 -
|
View Frank Patrick's profile
