How a workback schedule can optimize your project planning

Project planning is a difficult activity.

Everyone wants to know when a project is going to go live (or more realistically they tell you when they want the project to go live), but understanding all of the tasks that need to be completed on the way, how those tasks interact with each other, and when they all need to be completed is a mammoth and complicated challenge.

It’s this complexity that has led to an entire industry being created around the skills of project management, however, within product development there are some simple steps that you can take to support the delivery of work that don’t require the completion of project management certifications.

Starting with the workback schedule.

What is a workback schedule?

A workback schedule involves creating a timeline for a project in reverse, starting with the project completion date and working back through all the tasks you need to complete to the point where you determine a project start date.

When do you use a workback schedule?

Workback schedules are ideal support for projects where the completion date is known at the start.

For example:

• If you release your product on the 1^st of every month
• If you are delivering for a specific event that is occurring on a fixed date (e.g. Black Friday, a trade show, Christmas)

What benefits does a workback schedule provide?

Workback schedules are particularly useful for projects that contain numerous or complex elements because they allow you to:

• Identify unrealistic dates
• Create milestones
• Prioritize features
• Plan resources

Identify unrealistic dates

Let’s say that you’re aiming to deliver a new payment method for your customers and this needs to be in the product release on the 15^th of November, ahead of your Black Friday promotion starting. With the workback schedule approach you’ll need to workback from the 15^th of November and determine all the steps required to put this new payment method in place (e.g. testing, configuration, specification, contracts, commercial agreements).

If you add up the anticipated time for all those tasks and it totals eight weeks and today is October 1^st you can see that on the surface it appears unrealistic to have this project delivered in time for a November 15^th release. This can prompt early conversations on how to address this problem.

Create milestones

Project planning is all about planning activities and determining dependencies, deliverables, and delivery dates. Through the application of workback schedules you’re able to provide the different project contributors the milestones they must meet in order to meet the overall project completion.

With our new payment method example, our milestones could look something like this:

• November 15^th – Release
• November 8^th – User acceptance testing completed (finance)
• November 1^st – Payment configuration completed (finance)
• October 11^th – Commercial agreement signed (commercial)

As you’re working back from the fixed release date you’re determining the time needed before that from the preceding activity, working through all the tasks needing completion.

Prioritize features

As we’ve seen, through workback scheduling you are able to identify unrealistic dates sooner rather than later which allows for there to be conversations around whether elements of the project can be deprioritised in order to meet the immovable deadline.

Our tendency when determining project deliverables is to include as much as possible so that we can receive a greater benefit at the end of the work, however, the workback schedule provides an opportunity to ask yourself what elements of the project are essential for day one and what could be delivered at a later date.

If your workback schedule shows that you won’t meet the deadline with the current anticipated workload you’re forced to ask and answer the question: “What can be done to meet the deadline?”

Plan resources

Once you have your workback schedule in place you can allocate resources to meet the anticipated schedule.

If you need finance to test the new payment method by November 8^th, then you’ll need a finance person available prior to the milestone.

If you need a commercial agreement in place by October 11^th, then you’ll need the commercial team to have spent the prior weeks working with suppliers and legal teams on reaching a commercial agreement.

How do you create a workback schedule?

To create your own workback schedule there are a few steps to follow, each with their own set of questions to ask yourself:

• Defining your project goal
• Defining your project delivery date
• Determining a list of all the tasks required to deliver your project goal
• Identifying the dependencies for each of the tasks
• Estimating the effort and / or elapsed time for each of the tasks
• Identifying the resources required for each of the tasks
• Identifying the milestones for each task
• Adding all this information into your project schedule system / document

Defining your project goal

• What does your project want to accomplish?
• Are all stakeholders agreed on this goal?

Defining your project delivery date

• When does the project need to be delivered?
• Why is this the date that needs to be met?
• Is this date really fixed or is there flexibility?

Determining a list of all the tasks required to deliver your project goal

• What testing needs to be completed?
• What development needs to be completed?
• What systems need to be in place to facilitate this work?
• What content creation needs to be done?
• What configuration needs to be undertaken to set up the deliverables?
• What governance needs to be in place around this work?

Identifying the dependencies for each of the tasks

• Can some tasks only be started after other tasks have been completed?
• Can some tasks only be started at a particular time (e.g. in the new financial year?)

Estimating the effort and / or elapsed time for each of the tasks

• How much time needs to be spent on each task?
• Will the task require a specific period of time to complete (e.g. a 7 day period for a legal sign-off)

Identifying the resources required for each of the tasks

• Who will be responsible for each of the tasks?
• Are there systems or services that are required for the tasks (e.g. it requires access to the 3D printer)
• Are there any restrictions around these resources?

Identifying the milestones for each task

• Given the tasks, their dependencies, their estimates, and their resources, when does each task need to be completed by?

Adding all this information into your project schedule system / document

• Project planning software
• Excel spreadsheet

Workback schedule example

You can find an example of a workback schedule here:

Applying workback schedules in your current role

How you apply workback schedules in your current role will depend on the delivery approach that your organization takes.

For organizations with fixed release schedules

Workback schedules can be created based on the individual release dates that you have. For example:

• November 15^th – Release
• November 12^th – Business review and sign off
• November 8^th – QA review and sign off
• November 1^st – Development completed
• October 11^th – Release candidates confirmed

For organizations with ad hoc release schedules

Workback schedules can be created based on the individual deliverables that you are working on. For example:

• November 15^th – Release
• November 8^th – User acceptance testing completed (Finance)
• November 1^st – Payment configuration completed (Finance)
• October 11^th – Commercial agreement signed (Commercial)

Final thoughts

Regardless of your approach to delivery, workback schedules are useful tools to align stakeholders on deliverables and expectations early on in the process.

As with any project planning attempt, they are only estimates, and there are many factors that can derail the plan, however, it’s better to have a plan that can always be adjusted than to not have a plan at all.

Featured image source: IconScout