..what are we gonna do with it?
All has been set for your project. Objectives and goals are clear, deliverables and tasks clearly transposed onto the plan, all stakeholders identified, project roles and responsibilities assigned, scope, budget, timeline and risks are clear to all. You may have already held the kick-off meeting (probably virtually..). You have also the schedule ready, which is a document that details the project timeline, the activities with the organizational resources required to complete each task. You may even have a Gantt chart, the bar chart that illustrates the schedule. So … how are you going to best manage the schedule during the lifecycle of the project?
In this article I am am going to share my experience with schedule management, organised below in six recommendations. This experience has been acquired over the years, sometimes acquired painfully (the hard way…), as a team coordinator, team manager, scheduler and project planner in complex projects. Please note that the points below are not necessarily in order of suggested priority. As usual, I will be happy to receive constructive comments and feedback.
1. Keep the schedule handy
The project schedule (or the project plan) is a live thing. Project schedules that are kept unchanged as the work progresses are now a rarity (actually, have they ever existed?). In this blog we have already spoken about the challenges associated with planning at the time of complexity. As quoted by Greg Lawton in his interview to our blog:
“….we must appreciate that single predictions of system-wide performance, such as fixed costs or end-dates for complex projects, are misrepresentations of reality. Models that assume linear effects, such as the ‘Critical Path’ method (and derivative methods, like PERT), when applied to complex networks/projects, provide incomplete representations of reality. In large, interconnected and highly dynamic networks (where emergent properties significantly influence performance), the models that assume linear effects do not produce accurate results.”
Greg Lawton
My advice: Keep the schedule handy, review it regularly and brush up you planning skills. There is a need for a continuous re-assessment of conditions and circumstances. You may not be strictly (or knowingly!) using an Agile approach, but you will feel that a great level of agility is required.
2. Communicate & report
The purpose of the project schedule is to communicate critical information to the team. The information can be, for example, about work (late, current or future) or performance (timeliness, budget). Establishing solid communications channels and expectations for project schedule information is crucial. The schedule will have developed since its inception and got a greater granularity and sophistication. The terminology could have changed, the structure of the plan evolved to incorporate project partners’ workstreams and additional operational milestones. It is important that all stakeholders are kept informed, with the changes explained.
My advice: Know well your planning software and use the most appropriate reporting tools to get briefings that can 1) be shared with all interested parties (project resources, suppliers, contractors, management and project sponsors) and 2) that effectively and purposely inform the recipients. Ensure project manager, project planner and the team are working very closely. You can produce tailored reports such as: resource sheets, ‘duty rosters’ for the week, monthly or quarterly, milestones reports, task/resource burndown, financial summaries etc. Having also reports that tie to strategical dashboards will help in reporting to management, auditors and project sponsors.
3. Baseline, baseline, baseline
In project planning a ‘baseline‘ is a fixed, reference point at a particular moment in time during the course of a project when the planner or the project leader takes a snapshot of the situation, in terms of schedule, cost, scope. Schedule, cost and scope can be looked at separately or altogether. The reasons for a plan to change are various (remember, it is not a straightforward linear process..). For example, project risks might evolve or new threats arise, challenging the contingencies originally allowed in the schedule. Suppliers and contractors might get into difficulties or project sponsors require scope changes.
It is important to keep track of the baselines. These baselines help with the performance assessment (of the project team or the contractors). They will help in consolidating the learnings once that the project is completed. And last, but not least, they will help in managing the stakeholders expectations. The project sponsors will be very interested in knowing in great detail why the project is delayed and what are the consequences ……
My advice: Save multiple baselines (where the software allows..), keep records tidy and organised, making sure you keep the supporting narrative with sufficient level of detail that can allow easy reconstruction in a far future. If needed, save multiple copies of the project plan and keep them safe. This is particularly important for those long and complex projects as members of staff come and go and memory fades away.
4. Align it with dashboards
Your organisation will have a number of “performance dashboards” in place. The dashboard will be fed with information from the operational teams, extracting information from the project systems and related environments to illustrate project course, performance and impact. Some dashboards will be intended for the team, other for middle or top management or for the external stakeholders (note – I am going to cover the topic of dashboards in a future article on this blog).
My advice: Ensure your schedule are built in such way that “key performance indicators” (KPIs) can be easily extracted, on demand. I am not suggesting to have real-time indicators, but have two or three project indicators agreed with the team and management. Think in terms of leading indicators, those that are predictive (that measure something that leads to the project goals) and influenceable (that team can have an influence upon). Also consider “key risk indicators” (KRIs). As said earlier in this article, know well your software and its potential.
5. Manage changes
The different project management standards may have their own processes for managing changes during the course of a project. Whatever process is followed, the project planner will have to ensure that the revised project plans are aligned to the approved changes. Review of changes and baselines will help in evaluating past performances and review the project after its completion and (why not?) learn from mistakes.
My advice: Keep a short and clear narrative to support and explain the changes. Make sure that baselines or copies of the plans are tidily kept and cross-link these baselines to events/issues logged onto an “event tracker”.
6. Plan, check .. repeat
It is sometimes said that the project plan is for a project what the topographical map is for a hiker. The hiker has to assess frequently the progress on the map, also being vigilant over the surroundings, the terrain, the weather so to make the necessary corrections. Similarly, you need to periodically review the plan, to ensure that it is still aligned with the assumptions, with the project environment and the agreed work breakdown structure.
My advice: Check frequently if the assumptions (on dependencies, constraints, float) set at the beginning of the project are still valid. Assess the risk environment and review the inputs from partners, suppliers and contributors. As mentioned above, it is unlikely that your project will run linearly. Watch for the KPIs/KRIs in your project and act where necessary. Then repeat….The project schedule is a live thing.
I hope that this overview was of interest and my advice has some relevance. As always, please get in touch for comments and feedback.
Marco Bottacini, Senior Portfolio Manager, GALVmed
The views and opinions expressed in this blog are those of the author and do not necessarily reflect the views and opinion of GALVmed.
Project Management Discussion Group 