Here, with project time management, we refer to managing the project schedule in implementation and closure phase and focus on controlling the project schedule. In general, an integral part of project controlling in project implementation phase is making sure that the actual work follows the planned project schedule. We make sure that we identify changes of the time schedule and additional time necessary as early as possible and quote them in form of a change request for extension of time (EOT). These change requests shall be fair for all involved parties. For preparation of a suitable change process during project planning, please refer to sub-section Contract Management.
In most cases, scope creep - additional, un-planned work – leads to time delays and additional cost (cf. sub-section Project Scope Management). If not covered by a corresponding change order based on our change process, we shall avoid any scope creep. Otherwise, we end up in a claim situation: we implement the change anyway, take and file all available project records of that case, and try to settle compensation for it in terms of extension of time (EOT) and additional cost later.
Sometimes, we encounter problems keeping the planned time schedule due to mistakes or errors. We misinterpret or misunderstand certain requirements or specifications and do not estimate and plan enough resources and / or duration for a work package; while implementing the plan, mistakes and errors happen, we need to correct them and have to repeat parts of the work. In either case, we need more time than originally planned. In other cases, things are easier than expected, and we need less time than planned.
As a practical tool of project time management in terms of controlling the logical sequence on work package level, we find the network diagram. It is a simple, but powerful tool that helps to indicate - not yet solve any problems with - the current project status in terms of logical sequence of work packages.
A double strike indicates that the work package is finished, i.e. its results are accomplished (WP1.1, WP2.1.1, WP3.1).
A single strike indicates that work on that work package has been started (WP1.2, WP2.1.2, WP2.2.1, WP3.1, WP3.2).
No strike indicates that work on this work package has not yet begun (WP2.1.3, WP2.2.2).
In that example, it seems strange that work packages WP2.1.2 and WP2.2.1 could be started without having WP2.2.2 finished. In a real life situation, we would investigate how that was possible.
As a practical tool of project time management in terms of controlling the project schedule on work package level, we find the Gantt chart. It is a simple, but powerful tool that helps to indicate - not yet solve any problems with - the current project status in terms of time schedule.
For each work package, a red bar indicates the status of work progress; checked work packages are finished. In our example, WP2.1.1 is finished but needed more time than planned, while WP2.2.1 got finished ahead of time.
Both, using network diagram and Gantt chart, are convenient methods of time tracking. The first emphasizes logical inter-dependencies, the latter focuses on actual time used, compared with time planned, for each work package. Pre-condition is the availability of project time sheets (you find a template in sub-section Free Project Management Tools). Contemporary time sheets are an essential part of the project records – not only for project time management but also for all claim-relevant events and problems. So, we have to make sure that all those who contribute to our project keep records about time spent, work done, and results achieved, for each individual work package.
On project level, we use milestone trend analysis (MTA) to indicate the project status in terms of time schedule (in sub-section Project Management Dashboard we explain how MTA works).
In a case like in the picture above,
► milestone "Sys. Design" was achieved one month late,
► milestone "Hw complete" is indicated to have one month delay,
► milestone "Sw complete" is indicated to have two weeks delay,
► and milestone "Sys. complete" should be achieved on time.
For each milestone, we have a number of work packages leading up to it. Thus, if a milestone is indicated to be late then we need to analyze all work packages which contribute to that milestone. In a larger project that consists of hundreds or thousands of work packages, it is mandatory to summarize groups of work packages, and represent their status via milestone trends. Should one milestone indicate any delay, we "only" need to investigate the work packages behind that milestone.
Analysis of work packages behind delayed milestones focuses on two aspects.
Scope: what happened, what went different than expected, what can we do to correct errors or mistakes, what consequences does this have on other work packages or parts of the project, what are our lessons learned? Please compare sub-section Project Scope Management.
Schedule: what are the consequences on the time line of this and other work packages or other parts of the project, what can we do to make up for any occurred delays, what are our lessons learned for project scheduling? These leading questions support project time management and help us to deal with problems of time delays.
Combined with MTA, earned value analysis (EVA) is another convenient tool to support project time management. To show the project status in terms of time schedule, we determine how much work is done (or results achieved), and express it in terms of its Dollar value. This we call earned value (EV). Then we compare EV with the amount of work that should be done already (results that should be achieved already) which is planned value (PV). We can calculate
Schedule Variance: SV = EV – PV,
Schedule Performance Index: SPI = EV / PV.
SV = 0 or SPI = 1 at a certain point of time indicate that earned and planned value are in-line. We are on schedule.
SV < 0 or SPI < 1 at a certain point of time indicate that earned value is less than it should be. We are behind schedule.
SV > 0 or SPI > 1 at a certain point of time indicate that earned value is more than it should be. We are ahead of schedule.
Both, MTA and EVA, only serve as indicators of time delays. In order to cure problems we have to go down to the work packages and apply problem solving techniques.
Project time management requires a combination of different tools since one alone usually shows only part of the status: