I had a conversation with a seasoned project / program manager the other day, that revealed some fundamental flaws in how people deal with uncertainty, as well as how the failure to embrace constant learning short changes both the individual and the group. A few details have been changed to protect the guilty…..
In discussing how to plan for a fairly large and complex engineering development projects, I questioned why the baseline plan in his projects’ detailed schedules were often being done over and overwritten, or only went out a few months (which, inevitably, would be changed every couple of weeks). It seemed as if there was a greater emphasis on making sure performance metrics looked good, than on measuring how far off course the plan was from the reality – which would lead to some learning upon post-hoc analysis.
He stated that he wasn’t trying to manipulate metrics, he just wanted to have a plan that reflected the current reality and, since the projects changed so frequently, it was “impossible to plan for what I don’t know.”
What nonsense. Frankly, that’s complete and utter garbage.
In a schedule for a development project with a lot of uncertainty, all the task dependencies and starting / stopping dates and durations can be highly variable, and several paths in the network can die out midstream. So, as I told this Manager, leave milestones with specific dates indicating the spots where you will need technical decisions from both your team and customer before you proceed. Or, in other words, determine the points at which you will not know what to do next. Or, in other words, “Plan on not Knowing.”
He indicated he didn’t think that would work, and that it’s not really any different than a planning package in the schedule, which he was familiar with. I agreed – it is a planning-package type of approach, however, rather than existing at monthly or quarterly intervals the “I Don’t Know” milestone can take place much more frequently, if required, and doesn’t require any resource loading. It’s just identifying decision points frequently and – what’s even better – with a lot of customer involvement.
He again expressed his skepticism. I then pointed out that this approach is, essentially, the basis for agile development. He shook his head and indicated he’d never worked in an Agile environment and, therefore, didn’t believe it would work here. I declared that it works quite well in a lot of environments, and that we might do both ourselves, and the members of the project team, a great deal of good if we explored a new methodology and learned a little more about what’s out there.
He considered me a smart ass. I considered him an ignoramus. There’s probably a great deal of truth in both perspectives. Putting personalities aside, however, it was clear that there was a great emphasis on driving a decision (changing other people) than on learning (changing one’s self). That simple flaw – a flaw of personality, perhaps – was the root cause of a failure that impacted an entire project team and the company’s bottom line as well.
Like many other things, being prepared is the key. Although the norm is to pride yourself, and reward others, on their ability to react to uncertainty, seeing it coming is even better. If you know there will be a situation where you won’t know what to do – it’s best to plan for it.