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.
Monday, March 17, 2003
• Project Determinism -- An interesting thought from an announcement of a lecture by Daniel Dennett...
"A widespread bad habit of thought is supposing that whatever is determined is inevitable."
I know it comes from a different source, Dennett being a philosopher known for his on the workings of mind and consciousness, but it seems like one thing that an "agile" thinker might say that I agree with.
The non-deterministic nature of projects that is, I believe, at the root of the agile movement is also at the root of Critical Chain-based project management. While many agilistas prefer not to make promises beyond a week or two, as noted in a comment to a recent post, those of us in the "chain gang," recognizing the need to make bigger, longer-term promises to support business needs, prefer not to worry about date-specific intermediate promises.
The basic "requirements" of those needs can be and are known, and actually remain quite stable through the life of a project. The "means" of achieving them may be open to uncertainty, but once that distinction is understood, and is addressed in the overarching structure of dependencies and interdependencies and in the use of buffered schedules that can absorb non-trivial variation from "plan," the concern associated with "churning requirements" can be minimized.
When both traditional PMers and agilistas see a traditional project plan, they see concrete dates and milestones, each one to be met in turn. One tries to enforce it, the other recognizes the futility. A Critical Chain plan is not dates and milestones, but dependencies and deliverables leading to a final outcome that will occur in a range of possible calendar time, and manged not to exceed the outer boundary of that promised range.
. . . Later . . .
. . . More, upon reading Promises and Predictions, in which Laurent Bossavit (I found Incipient's name...right at the top of his blog), rises to the bait of my provocative proposition regarding "agile" and project management. Laurent writes...
"Part of the problem, perhaps, is that often we are lumping "promises and predictions" together, and Frank's phrase is of interest to me precisely because it calls attention to the fact that they are different aspects of project planning. We cannot predict in detail the future states of a complex system (if we could, it wouldn't be a "complex system" in the sense that attracts scientific attention). So at least in some of the ways we understand the term, "prediction" is of limited value on software projects."
In order to maintain some semblence of managing promises, which is the role of project management, prediction at the system level is necessary to assess the health of the project (it's promises). That system is made up (like, for example, a pool of health insurance policy holders) of components that are tougher to predict in an individual pinpoint fashion, but can be judged sufficiently so that there is some level of confidence in their aggregate result. To make promises, all you need is a way of aggregating the local uncertainties into a reasonably certain global whole. To manage (and dare I say, control?) execution of the effort, short-term detailed predictions, developed when appropriate, of local completions can be used to develop a current view of the health of the promise, modifying priorities if necessary.
I have to dig a bit more into some of the specifics, but in the XP flavor of agile methodologies, I understand there to be something known as a "release plan," which I have to assume contains the overarching direction and "big picture" of the real effort -- the cumulative effect/deliverable of the individual pieces of "working code" that together serve to provide some real, non-trivial, meaningful, bottom-line business result. This release plan is the real project, and as such, is the domain of the project manager, while developers and their techincal managers focus on performing tasks, and on appropriate use of their time within tasks. (I do have to give a nod to the agile folks for insisting on task (although not necessarily project) dedication of resources in what we in the critical chain gang refer to as "single-tasking," as a model for effective resource utilization. Again, we're more in line than with common practice of traditional PM.)
"Frank suggests a strong argument in this direction by pointing out that the things we most often try to predict are not directly relevant to what is at stake: "Software tasks, appropriately managed via agile processes and organizations, almost never deliver the actual end result of the effort. They deliver supportive components of business processes or products that require coordination with non-software components."Most of the time, these non-software components are human components, in fact, and decidedly nonlinear and difficult to "predict" in the sense of anticipating future states in any detail."
Interesting, I thought software folks looked upon things like roll-out and implementation of business processes, training of users, preparation of marketing materials and events, installation into customer sites, etc., as the trivially simple things that could be left to traditional PM approaches.
I guess, as in all things, it's a matter of perspective.
posted by Frank - Permanent Link -