"The key to project planning is to embrace the obvious fact that people don't know, what they don't know." </p>
Requirements and deadlines are the methodical drum beats engineers march to. This holds all the way from bridge building, to systems architecture to large network topology design. The more well defined the problem, the more predictable the performance. The machine like efficiency with which grand systematic projects are executed is both beautiful and awful.
"Inflexible project management is best reserved for generating mediocre fast food."
All but the most trivial dynamic systems are unpredictable over an extended period of time. There's nothing that grates my nerves as much as an absolutely rigid plan with an inflexible schedule, carefully orchestrated to execute a "known" solution. Why are people doing that job? Thinking, feeling, creative beings aren't well matched to repetitive mindless tasks1. For that job you want robots coordinating other robots. And in all but the poorest areas it's not cost effective to have people performing tasks that machines are capable of doing.
Drowning in Waterfalls
It's unfathomable that project managers continue to rely on fixed overlapping intervals for complex scheduling. Waterfall planning requires all dependent components be complete before follow on integration steps. Each element delay pushes back the entire project delivery. There are a range of popular alternatives to milestone planning, but they share common flawed assumptions. Beyond catchy names and micro milestones, I haven't witnessed an advantage to replacing one orthodox rules based system with another.
Fluid Schedules and Iterative Model Driven Development
"Take all your expertise and stuff it... for the moment"
Experts are blinded by barriers assembled brick by brick through years of practice. We are all creatures of habit and favor the tools and solutions we know best over unfamiliar alternatives. And yet the environment is changing around us as fast as we can adapt (or faster).
If the system your team is designing and planning for has even the slightest bit of novelty, then iterative model driven development is a viable option to test initial designs and to better plan and understand development schedules.
The basis for MDD (model driven development) is rooted in stub and complete system tests which validate subtle changes in functional behavior.
The core idea is to fabricate the simplest possible system and element representation which mimics the desired behavior of a system design. You can think of this as model 0, or more specifically zero order system and element models. Immediate knowledge is gained about assumed bottlenecks and system level characteristics. This information feeds back into planning and design, which leads to refined models for the system and elements. Time can be allocated towards incremental improvement of individual element models, or the system backbone.2
Model enhancements are more predictable, yet less constrained. Incremental development of higher fidelity models allows the overall system to be tolerant of element delays.
- When I refer to repetitive tasks, I mean no disrespect to master craftsmen and artisans. Their work is far outside the bounds of mindless, I'd instead describe their work as mindful.
- The system backbone is loosely constrained to be on the same order of complexity as an element. The balance between system backbone and elements is analogous to the roles of controllers and models in application design.