Dreamfeed

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?

Recently I read two blog entries about software development processes, The “Any” process by Laurent Bossavit and About People, Tools and Processes by Mishkin Berteig.Reading these entries, I realized that processes don’t exist - they’re an illusion. A process is a (mental) model that you project on what you hear and see, to make sense of what’s happening and what people are doing.

This implies that you cannot follow a process, let alone install or prescribe a process. It’s not possbile to change or improve a process directly. Instead, you can do system interventions and observe whether these influence the processes as you perceive them; you can e.g. facilitate, introduce practices, describe procedures, remove obstacles, but you cannot influence the process directly.