| > If we instead focused on continually steering toward desired, valuable functionality (things people genuinely want or will pay for), more software projects would appear like successes. Yes! All overbudget, late to complete, successes of course. I jest a bit. I think the term "deadline" is completely inappropriate for most projects. I prefer, "target series", for any significant project. Each word communicates something very important. The first target should be set via (1) known knowns/unknowns, (2) some wisdom about unknown unknowns, and (3) mindful optimism. The last should almost always ensure the project misses its first target. Which sounds backwards, until accounting for the considerable creative impact, and absolute time savings, that a time constraint creates. And how much a team can improve its productivity over time, by continually targeting informed optimistic targets. Improving a teams rate of return has compounding value, for everyone. But this is a self-imposed, let's see how well we can beat ourselves, time constraint. Never an, OMG I might lose my job / standing / reputation / customer credibility time constraint. If the first target is missed, or as soon as it is clear it is wildly unachievable, a second target is set the same way, with the new information. Each target in a series should require less padding. If more padding is added it is a sign to step back and consider what is not being understood. Over time, a team should develop a pretty good pattern of completion at target 2 or 3, or something like that. In a way that becomes fairly predictable. It doesn't really matter what the number is, just that the team develops a rhythm that actually does provide some predictability based on current knowledge, even if it isn't in absolute time terms. This is the best path for optimizing both rate of progress, fast recognition of problems with progress, and realistic levels of project arc predictability. In my experience anyway. |