Not only are there many people who do not need to use a complex schedule, but not everything is always best suited to be managed in a schedule; specifically contractual dates, deliverables, dependencies, and in some cases, milestones. There are options to abstract these above the schedule, providing a simpler user interface which is more likely to be accurate and accessible by different people. In those cases where a schedule is actually needed, not everyone is a detailed scheduling expert. Some just need a list of deliverables to tick off. Some need a more graphical view. And everyone needs something that is simple.
Related:
- VIEW RECORDING: Task Management & Project Schedule
What’s the problem?
A schedule can sometimes be too detailed and too complicated. They are often a bottom-up approach focussing on the details. In a project there are usually key dates important to the whole organisation; such as when procurement is completed, when contractual dates are to be met, when practical completion is due, or when a public release is planned. Within the bounds of these dates the project team will break down the work and complete a series of detailed tasks. These detailed tasks may move but overall, the key date does not.
What if a team doesn’t have a schedule? If they are working to a high level, perhaps on a simple project, they may only need to know what to deliver and when, not how. Or if they are carrying out operational work, they just need a list of deliverables.
Therefore, we can see that different levels or stakeholders of the organisation need to focus on different types of dates, existing in a hierarchy of layers. When all a PMO has is a traditional schedule there is no tool to help stick to the big picture, often resulting in the project team losing sight of what is important and getting lost in the details.
Important Fact: Schedules are not the only representation of a project, therefore building your approach around a schedule may mean you miss out on what is really important.
The problem with only using a schedule is:
- While a schedule allows you to list a task, plan a date, and track progress, it treats all dates the same way. But are all dates equal?
- In a two-dimensional schedule, how do we make the most important dates stand out?
- To gain the power of the scheduling tool you need to keep it up to date. But in reality, your work and people may be moving around all the time, choosing their own way to get through the work by re-sequencing the tasks and looking for support within the team. The team gets it done, but you can’t exactly plan how and you can’t track it unless you spend all day in the schedule. When we consider adaptive methods, you want to encourage the team to work the way they want, yet you don’t want a tool that hinders you in this.
In addition, many people do not use a schedule or do not use it well. They start off with great intentions and dreams of increasing the maturity of their planning, tracking and reporting; but something goes wrong and over time they pull away from the schedule, and with it the overall project and portfolio management system that was once set in place.
Why do we really need to consider dates?
This seems obvious:
- We need to know when something should be done;
- We need to be able to detect if it isn’t going to be done;
- We need to have a way to escalate if it isn’t going to be done.
But is this relevant for every single item we are tracking?
If we need to break the project down into detailed tasks, do we need to track every task? Do we have the time? Have you ever actually done it well and continued to do so?
Do we need to break the project down into detail in the first place? What if we are using an agile method, and the team has another tool with the detail they need in it?
Shouldn’t we rather focus on the boundaries, those big picture dates that are a representation of many detailed tasks, and the holistic view on the project? The dates that have no option but to be hit, otherwise the project team can not recover.
Important Fact: Adaptive Project Management is an emerging approach encouraging teams to change how they deliver so that it works for them, as long as they stay within their key dates and deliverables.
For example, should we just focus on the date an overall deliverable is due, and leave the detail of how that deliverable is created to the project team? Let them track their own detailed tasks if they want to, but the program manager makes sure that the overall deliverable is reported on within the program.
What dates should a project track?
To create boundaries that a project should not go beyond, we can consider the following hierarchy of dates.
The big picture: key dates
The most important boundaries on the project are those big picture, key contract dates. The concept of key dates allows us to define the dates that:
- Are abstracted above the project;
- Need to be easily visible and escalated;
- Serve the purpose of dates to track and to manage progress of contract items.
The dates don’t have to relate to contracts as such, but can be used to track and escalate any agreement with the project and the outside world, such as when a regulatory date is due.
Key dates keep you within your organisational bounds and provide you a way to escalate those critical issues that you cannot control within the project.
Flexibility to deliver my way with Deliverables
Within the bounds of contractual key dates, the project has to physically deliver something. Deliverables are used to define what will be delivered and when. This may be sufficient for those projects who know how to produce the deliverables without the need for more detailed tasks.
Deliverables are simply the results of the project or the processes in the project. Meaning a deliverable can be something as big as the objective of the project itself or the reporting that is part of the larger project. How the project creates the deliverable is up to the project team, the rest of the organisation just has to know what and when.
Important Fact: Deliverables are being used by teams who don’t want a schedule or have a schedule in another tool such as Jira, but need to report on what they are producing on a project management level.
Deliverables allow you to provide a layer of abstraction above the schedule, and a way to describe your project to the rest of the organisation. They may be as far as you need to go into detail.
Execute the way I want with any task tool
You may need to break the work down further into individual tasks. The tasks are different from the deliverables in that the tasks are how you carry out the work, not what you produce. Tasks could be related to a deliverable or a key date, but often they are not directly so. The tasks allow for a breakdown of the work but also the freedom to move the work around, assign it to other people, and break it down further if needed. As this can quite often be dynamic as the work progresses, you need the tasks to be able to change without changing the deliverables and key dates’ letting the team operate within the boundaries, yet in their own way.
In the past, a schedule was often used to manage tasks. This required everyone to use the same scheduling tool. They were often complex to use, leading to them not being updated or sometimes not used at all. This led to incomplete reporting and is why we need abstracted layers in the Deliverables and Key Dates to report against.
What is important is that you have visibility of all tasks and their status, regardless of which tool the team is using to manage those tasks.
This is why Altus provides a separation between the project management layer and the task layer. This allows each team to work in the way that makes sense for their maturity, style and type of work; whilst providing them with industry standard project management and reporting.
To provide you with a well rounded starting point, Altus includes the Altus Task Tool. This is a built in tool that you can use to create tasks, plan sprints or manage an agile board.
You can use this task tool, or you can link in your own. This means that the team can track tasks their own way, while you can maintain the deliverables or key dates independently. We are often asked if the tasks link to deliverables or key dates. They can. However, often it is actually better to keep them independent as this allows your task layer more freedom as there is less data to maintain.
By using Key Dates, Deliverables and Tasks in any task tool you can see that you are able to provide each layer of the organisation with their own approach. You can ensure that consistent reporting and monitoring is available, while giving your teams the freedom to work the way they want.
By Ryan Darby
With over 18 years in PPM and Work Management Ryan has developed into a well-rounded professional who can always be approached and asked for advice. With experience in over 100 PPM implementations and Ryan’s excellent people skills, he is always able to provide quality advice and direction. Ryan is an industry standard expert on all levels of PMI, PMO and Scaled Agile.
