In my work I often encounter stakeholders’ reluctance to plan. I have the impression that fear of being held accountable for deadlines comes into play. It’s easier to refrain from making declarations about dates.
But is no plan better than even a poor plan? And what does a “poor plan” really mean? Should we insist on terms we are unsure of on the assumption that they might mislead someone? While this may seem controversial, in my opinion – yes.
Plan as a forecast
The plan is a risk-weighted forecast. We can make our plans more realistic, increase their precision and credibility using expert knowledge, references to other projects, using methods such as the Montecarlo analysis, but ultimately … this is not the only task of these plans. Creating a plan is a process anyway – a pre-designed plan is not a final product. Therefore, it should be assumed that our plan will change, and this is the case (of course, after saving the “base” and meeting the change management requirements). By delaying (or refraining from) planning, we deprive the organization of the opportunity to improve the way to reach our goals.
Plan — scope verification
When planning, we rely on a defined scope. We often start with the so-called WBS — Work Breakdown Structure (or Product — PBS). Although it happens in practice that we combine these steps and the WBS is omitted (by the way, in a tool such as MS Project, the task name column is often called “WBS”). The very act of detailing tasks (starting with “work packages”, which should be the lowest level of the Work Breakdown Structure) and defining dependencies forces us to double-check, if we missed something in the scope.
Plan as a reference point
A plan is more like a blueprint than a map. Thanks to plans, the involved participants can assess when their support will be indicatively needed, understand the dependencies between groups of tasks and the sequence of events.
An inaccurate map could mislead the traveler. However, if only the project manager and the team put a minimum of effort into preparing their project schedule, it should be updated on an ongoing basis, and such a plan will still turn out to be more useful than not having it at all.
The specificity of the plan assumes its adjustments in the course of work (progressive elaboration). The key is to save a version of the plan at agreed moments in the project (baseline). As a result we obtain a basis for assessing what and to what extent has been changed.
The plan as an analytical tool
When we work with our schedule, going down to the level of detailed tasks, we not only verify the completeness of the scope, but also the stakeholders involved in the analysis and estimates can submit their comments.
In addition, when talking about the duration of individual activities in the plan, we verify our assumptions and often consider risks – for example, when participants emphasize the discrepancy between the expected and pessimistic estimates for individual tasks. During my trainings, I often say that when planning, we should have a risk register at hand. Often in such a register, in addition to information such as proximity of a given risk, probability, weight or owner, there is a field to enter a reference to the task to which the risk relates.
Plan as a commitment
The plan is also a commitment for the participants. I would prefer to assume that this is a conscious declaration of the participation in the work, rather than a strong obligation to deliver the result within a certain period. Waiting for declarations on the completion date is almost destructive to the ultimate goal of our projects. Of course, these are needed – it’s hard to manage projects effectively without them, but it’s worth highlighting other benefits of having a schedule in the first place.
The aspects mentioned above are not exhaustive (enough to mention reporting), but I wanted to emphasize the importance of scheduling in general, going beyond the typical thinking about plans in projects. Perhaps this will encourage reflection and a more favorable view of the imperfect schedules in our projects.
