Before delving into whether one should or shouldn’t use a schedule, it is important to understand what it is we are referring to when we say schedule. For all intents and purposes, a schedule is a plan, an end to end timeline of all the work that needs to be completed, by whom and when, in order to deliver the project, that has specifically been constructed in a scheduling tool such as Microsoft Project or Primavera.
Sometimes a schedule is not the most effective means of coordinating and communicating
what needs to be done, by whom and when.
This paper aims to explore the requirement for the creation and maintenance of a schedule, in projects, and when perhaps, alternative means of managing your plan might be best. That is not to say we are discouraging the use of a schedule, in fact quite the opposite, we highly recommend it. There are many proven benefits as to why to use a schedule, reasons that we won’t detail here, but in summary include:
- Assisting in scope definition, providing clarity on what needs to be done.
- Encouraging detailed thinking and planning, including validating assumptions and hypotheses.
- Providing advanced warning and foresight of potential issues.
- Enhancing Risk and Issue Management.
- Facilitating Critical Path Management.
- Capturing progress and enabling the detailed analysis of said progress for action / reporting.
- Offering scenario analysis and change impact quantification.
- Aiding communication and collaboration.
However, sometimes a schedule is not the most effective means of coordinating and communicating what needs to be done, by whom and when. Nor is it the only means which has benefits. In these instances, the creation and maintenance of a schedule may seem onerous for the output which you wish to gather. Below we discuss the factors to consider when choosing alternative mechanisms, such as Microsoft Excel, Operating Rhythms, Jira or Kanban, for example, of creating your plan and measuring and communicating progress against it.
1. Repetitiveness
If the elements of your project are repetitive, no matter the frequency, for example, a Roll Out across multiple sites, then perhaps other planning and tracking mechanisms might serve you best, mechanisms which offer greater flexibility in visually displaying where each element is at in the repetition, for example, Microsoft Excel. Where required, blended models of planning can also be adopted, whereby these repetitive elements, as tracked in Excel, are also represented within a schedule as a single line bucket task.
However, if the same work is recurring, at the same time, whether that be on a weekly, fortnightly or monthly basis, then we would suggest an Operating Rhythm is more apt.
2. Simplicity
If your project is not overly complex, with very little cross-stream interactivity, for example, a Migration Runsheet, or you are running Agile with limited release trains, then you may not necessarily reap the benefits of using a schedule, nor gain the value out of the effort required to create and maintain a schedule. It is in these instances when you might well adopt alternate mechanisms, such as Microsoft Excel for your Runsheet, or Jira and / or Kanban for your Agile project.
3. Dependencies
If your project isn’t complex, but also has little to no dependencies, and you can adequately plan and track your work without a schedule, and still understand the flow on impacts of any change in the delivery of dependencies downstream, then perhaps using an alternative mechanism might be more favourable, for example a Kanban. We would recommend in these circumstances, that should there be any dependencies, no matter how few or simple, that some form of Dependency Management be undertaken, even if it is a piece of string linking dependencies on your Kanban, but preferably also adopt the use of a Dependency Register, whether in SharePoint or Excel.
4. Reporting Requirements
It is important to understand the reporting requirements that you will need to fulfil on a regular basis when deciding which mechanism to use for your plan, and whether said mechanism, is capable of easily and quickly producing such reporting. Schedule reporting tends to lend itself better to timeline-based reporting, including, for example, dependency and critical path analysis, whereas Excel or Jira tend to be best at statistical-based reporting. Ultimately, if you are unable to meet the reporting requirements, regardless of the mechanism chosen, then you will find that the time saved in creating and maintaining a detailed schedule, will instead inevitably be spent creating said reporting.
