Stefan Maxwell.

Project planning is more than just a schedule

Cover Image for Project planning is more than just a schedule
Stefan Maxwell

Consider this statement:

Projects are executed to a schedule to deliver products to an agreed standard of quality within a constrained envelope of funding. Projects are delivered through resources in teams with the required capabilities within a specific working environment. Projects can consider a number of options and may need to prioritise to establish the essential functions of the products to be delivered.

This statement is deliberately constructed to highlight a number of perspectives or lenses within the project planning process. Each of these and more will be covered over this series of articles to define these perspectives and provide some key questions you could consider during your planning exercises.

So put simply, project planning is more than just a schedule.

Introducing the Project Planning Lenses

The concept of a "lens" or a perspective is not a new one, being prevalent within management and business circles and in particular within academia. These Project Planning Lenses and those that follow are a work in progress of mine to provide project delivery professionals with a toolset to use when carrying out planning activities. It is extremely difficult to consider all aspects of planning at once so the intention of this set of lenses is to provide you with a pick list of perspectives to adopt during a particular planning session, where you can use a different set with each iteration to build up all aspects of your planning over time.

Planning is a holistic activity and as such needs to be broken down in some way to make it achievable.

These lenses are also intended as a capability-building set to introduce those new to project delivery and planning in a temporary organisation context — where projects and programmes reside — what to consider when putting together a plan.

The Lens of Scheduling

Something I ask very early on when working with a new project manager is for them to show me their plan. More often than not they pull out an immaculate MS Project schedule and glibly state, "here's my plan"! At this point, I draw their attention to the fact that a schedule is merely a single part of the planning process and in isolation is just a story of tasks listed in order.

The purpose of this lens is very much to reinforce this point, that scheduling is but a single lens of project planning and not the totality. It is important to understand all the tasks required to deliver on your defined scope and therefore this is of course a critical lens to apply in all project planning activities.

Key Questions

  • What are the tasks I need to carry out in order to achieve the desired outcomes?
  • Are there some tasks I am unable to either start or complete due to a dependency on another task?
  • Do I need to execute tasks in parallel or can I adjust timing to ease the pressure upon my resources?

The Lens of HOTO (Hand Over, Take Over)

Dependencies are obviously very important to manage on your project but one thing I have come to experience is that sometimes overlap is essential to properly manage dependencies.

Take the example of transitioning between 2 different supply routes for a particular set of services. You could have a drop-dead date upon which your new supplier takes up all responsibilities for delivering on the scope of services, however, depending upon the criticality of those services and your risk appetite, you may want to ensure you have a fallback option.

This is an example of making a successful transition to a new relationship, where an element of overlap may be desirable. You may think it difficult to manage but the alternative may not be palatable either — you have nobody there to service your requirements. The concept of HOTO, or Hand Over Take Over, demarcates specific periods of handover and takeover.

During the handover period, you look to build capability with the receiving party for a particular dependency whereas, during the takeover period, the receiving party of the dependency takes the lead on delivering the next stage of your project or operations. This lens can be applied to a number of scenarios within your project and above I have talked about transitioning between relationships, however, the same principles could be applied when handing over tasks between members of your project team or moving a product from design into the build stage — ensuring that your production line really understands the design before commencing on their phase of the project. It is important to consider the specific criteria that would provide you with sufficient assurance that the receiving party of a dependency is capable to deliver upon the next phase of your project as this signals the beginning of the takeover period.

Key Questions

  • Which tasks in my schedule require a handover between resources?
  • Is there a need for a capability-building period for the recipient of a dependency within my project?
  • What are the conditions that allow the recipient of a dependency to take over?

The Lens of Stakeholder Engagement

It is quite likely that your project has more than one type of stakeholder involved at any one time— perhaps suppliers, customers, or project team members — each of whom will be experiencing different feelings and have different expectations through the stages of the project.

You should look to gain an understanding of how each of your stakeholders feels about the project and understand the points during the project they would want to be engaged and, importantly, in what way you should engage them. At times your stakeholders may not be supportive of your project and you will want to consider how you can bridge the gap between how they feel about the project and how you want them to feel. This may mean that during a stage of the project you execute an action plan to align them— intensive stakeholder engagement workshops, 1-2-1 meetings and so on.

This can be particularly true of projects that involve an element of business change or transformation as it is unlikely that all of your stakeholders will be completely on board throughout the project. This may involve some tough decisions along the way and you may want to consider who among your stakeholders could help you to persuade and influence those that do not support the objectives of the project. This is in your role not just as a project leader but also as a project promoter.

Key Questions

  • What do I want my stakeholders to be feeling? Why?
  • What will stakeholders be feeling through the stages of the project? Why?
  • How can I bridge the gap between stakeholders’ feelings and the feelings I would like them to have?

The Lens of Ritual

It is important to consider that with all the planning complete, the scope agreed upon, all of your stakeholders onboard and suppliers engaged — you are still not done. Most important of all, once you believe your project is underway, is what the mechanisms will be that you use to drive forward the project on a day-to-day basis, ensuring you are monitoring and adjusting where required. This is something I term the "rituals" of the project and relates to those things that we can sometimes take for granted such as project checkpoints, drains-up reviews, and 1-2-1 meetings with project team members— you need to consider how specifically you intend to drive the project forward.

Key Questions

  • What mechanisms will drive the project forward?
  • Does the project team have a unifying goal to drive toward?
  • Can I break down goals to make them more achievable?

The Case for Project Planning Lenses

So hopefully by this point, I have sold you on the concept that planning is a holistic activity, which requires adopting a number of perspectives to achieve a plan that can be executed with confidence.

This article will be the first in a series where I introduce lenses that can be used to assist in the planning process to make your plans, not just your schedules, more robust.


More Stories

Cover Image for Risky business: it's all a little uncertain

Risky business: it's all a little uncertain

Risk isn't what you might think it is, and maybe that's ok because I believe you should stop talking about risk and start talking about uncertainty.

Stefan Maxwell
Cover Image for Your project is costing you more than you think

Your project is costing you more than you think

Thoughts on cost: what it is and why it isn't just about money.

Stefan Maxwell