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, August 04, 2003
The Meaning of "Schedule" -- This exploration of the uses and misues of the word "schedule" by Sheryl Smith from StickyMinds.com (may require free registration) is closely related to what I was going to write as a follow-up to yesterday's piece on late projects and PMOs...the one on the Forrester study that defines project failure in terms of only one factor -- lateness.
This implies lateness of something specific, something planned, something promised -- a product scope, for want of a better term. The agilistas among us are probably going into apoplexy about such a survey, as they tend to do with the hoary old Standish "chaos report" that gets trotted out every time anyone want to point a finger at project management failure in the IT context.
The idea of a fixed scope with a fixed budget and a fixed schedule and due date seems to be anathema to those of the Agile/XP persuasion. Now don't get me wrong. I like agile methods -- they address very nicely a range of issues common to environments characterized by high uncertainty. Some of my best friends are agile. And for that matter, from where I sit (in the Critical Chain PM world located somewhere between the perceived - by agilistas - rigidity of "traditional" project management and the perceived - by traditionalistas - chaos of agility) the idea of fixed scope, budget, and schedule is something that doesn't exist in my reality either. And apparently, it doesn't exist for Smith either...
"An honest, real schedule won't be gospel, and will still slip...A real schedule is hard to predict, and puts a focus on accuracy that some of us don't want to see ahead of time. In our high-stress community, sometimes we expect rewards for busyness and speed, not for accomplishment and quality. People want to believe that longer hours mean more work gets done, whether this is true or not. Managers want to believe that a pushed project finishes faster, whether this is true or not. Studies have cast doubt on both these notions, but the notions live. We're not quite ready yet to give them up."
There may be, or rather, needs to be an initial target scope, budget, and schedule to define an effort as a project and to determine whether or how much of it to pursue. Part of the scope may involve discovery along the way, some of the schedule may seem rather nebulous up front, and the delivery budget may be based on range or as a "not to exceed" target, but they constitute a specific scope, schedule, and budget nonetheless. And they need to be considered as promises until and unless there are rational reasons to do otherwise. As such, they are models of expectations, subject to necessary and appropriate change.
When I hear some of the agile persuasion saying things along the line that when something gets done "doesn't matter as long as it meets business needs" and proudly claiming that this viewpoint is more "agile" than otherwise, I get confused. One one hand, I agree that, in many cases, if the effort is worth doing, it is worth doing. But on the other hand, "business needs" include aspects of timeliness and predictability. As Deming has been known to say, "Management is prediction." Projects -- even IT projects -- don't live in an isolated world of their own, and the highly uncertain parts are being pursued with the idea of delivering something reasonably certain in a reasonably certain timeframe to support a range of business needs, from external promises to customers to the internal means to manage resource capacity and the ability to deliver other projects as well. From Smith...
"High-tech projects are criticized for being "slow"—they're never criticized for being unpredictable. Yet aren't accurate predictions what business needs most? When there is no realistic schedule, people in the trenches conspire to invent one. They have no other choice because they need to do so to plan their work. The actual users want to know what the team in the trenches knows."
And the only way for either to know -- as well as they can at any point in time -- is to compare the reality of the current situation to the model of expectations that is the overarching schedule or plan for the effort.
Sheryl's piece is a definite keeper. The only thing I have to add is that, in her "Schedule=Schedule" section, part of an "honest, real schedule" needs to include explicit acknowledgment of the uncertainty that separates the expectations along the way from the ability to make a reasonable promise regarding final completion of the effort and the ringing of the project's cash register. Things will and should slip or pick up along the way from those interim expectations due to uncertainty and variation, but these slips and pickups are most likely within a reasonable -- and unmanageable -- range of "noise" that is not worth obsessing over. As a model of those expectations that includes a factor to recognize an acceptable noise level (and when it is exceeded), the schedule is a tool for assessing the health of what matters -- the final project promise.