Planning is Thinking ... But Don't Think About it Too Much

 

By Giampaolo Marucci, PMBOK^® Guide-Seventh Edition Development Team member

Planning is a common activity in everything we do. We could say that we plan because we think, or we think so we plan. Planning is thinking on what we have to do in the future (near or far) to get to an objective or to achieve a goal.

One of the core activities and functions in project delivery is planning, which is a Performance Domain in the new PMBOK^® Guide. (See earlier blog post by Cynthia Dionisio on what are Performance Domains.) In project management, planning produces a common understanding of why we need to get to some objective and what to do next to get it. Common understanding is achieved by sharing of the information with all the stakeholders especially the delivery team. Planning activities can have output artifacts like “plans”—but not necessarily.

Plans can be:

• at a high level like a Master Plan or Roadmap;

• at a low level with much detail and fully predictive;

• partially completed like a Release Plan; or

• detailed only on some parts like an Iteration Plan, Sprint Backlog, or a Phase Plan.

We can also “plan to plan” like in Rolling Wave Planning. In any case we need to pay attention to the balance of effort we spend in planning with the threat of market erosion because of delays in having spent too much time in planning.

Planning is closely related to the project delivery approach and tailored for the project to realize the product, service, or result with benefits for the community of people who will use the end result. Planning activities are always in parallel with control activities. A plan is effective only if it is frequently/continuously verified by control actions to understand whether or not the plan remains aligned with the expected benefits the project is expected to realize.

At the start of a project we select a project delivery approach and we tailor it for the needs of the project based also on:

• volatility of requirements,
• level of knowledge of the base technologies and physical resources needed,
• number of people involved, and
• uncertainty of the context (i.e., market conditions or emergent risks—what we don’t know so we cannot predict).

Then we need to apply an appropriate planning strategy/approach.

If requirements are estimated to be nonvolatile, base technologies are well known, and the number of people is not many, then a full, advance predictive planning strategy could be applied. The adaptation of the “Plan,” artifacts, and re-planning activities during the project occur on the basis of the change control process defined for the project.

On the other hand, requirements can be volatile and base technology not well known, so we might use a project delivery life cycle with frequent feedback from stakeholders. For this kind of project, we need frequent adaptation of plans during development and many re-planning actions.

Also, projects that are closely aligned with “operations” functions, like continuous delivery of value, can apply Lean Kanban practices commonly used in IT or R&D projects. These types of projects need planning activities that adapt the plans continuously on the basis of feedback from experimentation. Adaptation here is so frequent that we could talk also about reactivity. But reacting to an event requires a short and prompt re-planning action immediately after the trigger event is recognized.

Objects to plan inside a project include cost allocation, time scheduling, physical resources, delivery, and many others. The way in which the planning takes place varies depending on the life cycle approach taken, but planning remains a key activity throughout the project. Planning could be led by a project manager, a Product Owner, or the whole project team. Self-organized and cross-functional delivery teams might plan from a backlog of prioritized items.

Planning, and generally speaking project management, is the application of knowledge, and it is important for the entire team to share in the planning regardless of who leads or the form the planning takes.  In any kind of project, planning activities are always required. Planning is a fundamental skill inside any project and has enormous impact on the delivery of intended outcomes. That’s why I consider it to be a performance domain for all projects.

Finally, planning is a passion, a knowledge we need to love if we want to apply it well, and a skill we need to improve continuously...Think about it.