Planning paradoxes (1)
A lot of project proposals and initial project plans I see around me are based on linear models, assuming that IT projects are predictable and that we can predict a single outcome. In terms of the Cynefin model, projects are assumed to be in the Known domain. Many IT projects are however in the Knowable or Complex domain. The research oriented projects I’m involved in are usually in the Complex domain.In the Knowable domain you can use tools like risk analysis, scenario planning and set-based development as alternatives for standard linear planning. In the Complex domain, agile, feedback oriented project management approaches like rolling wave planning and working iteratively are applicable.
Applying simple, linear planning can (temporarily) hide the inherent and sometimes scary uncertainty and uncontrollability of IT projects, but applying planning tools outside the domain in which they are applicable doesn’t work – the plan will turn out to be wrong. In the projects I’m involved in, I see that although our customers are generally quite happy with the steady stream of delivered features, we have to spend time and energy ‘repairing’ their unmet expectations and explaining why we didn’t meet the original plan.
There’s a paradox here. Spending time on planning decreases the uncertainty we feel about a project (like, will the project deliver all the features we need, in time?) The more time we spend on planning however, the less time remains for realizing features and the higher the probability that our fears about unmet expectations will become reality.
So, why do you plan? What value does it add for yourself, for your customers and for the organizational context?