Developing and controlling the schedule
Key points
■ Planning the schedule-management (time-management) approach
■ Defining project activities
■ Estimating techniques for calculating activity durations
■ Estimating accuracy and confidence levels
■ Building in the resource reality to the estimates
■ Understanding activity dependencies
■ Building in lead and lag time
■ Creating network (activity-on-node) diagrams
■ Developing the schedule timeline
■ Working with the critical path
■ Controlling the schedule reality
In practice
In the absence of templates and software, some project timelines (schedules) are intuitively planned and managed in someone’s head. While perhaps making it easy to find, this ‘technique’ does little to embed thorough understanding, ownership, commitment and capability, not to mention planned performance.
An idea isn’t a schedule any more than a proposal is. Nor is an extensive (and impressive) activity list in Word or Excel a schedule. Schedules are drawn up over time, and not just in columns and rows. Often just a simple bar chart, they are created to convey intent, drive delivery, measure performance and assess completion—over time, against budget, as scoped and within the agreed resource parameters. Further, an effective schedule provides a clear baseline (think of a master copy) of intent against which ultimate performance, deviation and/or achievement (reality) can subsequently be measured, assessed, reported and managed.
Remember that there can be a massive difference between the intent and the reality. That is why full disclosure is called for in drafting, publishing, updating and controlling the project schedule to demonstrate and maintain project performance, accountability, transparency, communication and client satisfaction.
Chapter overview
To manage time in your project, you need to demonstrate that, at any given time, the project is being managed for timely completion (PMBOK, 2013). That means delivering the project pretty much on time—give or take a +/– variation acceptable to the stakeholders.
But time management might actually mean a whole lot more. While completion is important, you simply cannot complete what you haven’t planned—and in some cases, planned in significant detail. Time management is more than a mere schedule or bar chart; it is a process to identify all the component parts that make up the different schedules that the project will generate—baseline, current and actual—throughout the life of the project.
As with every part of project management, policies, procedures and documentation are required to support how schedules are developed, executed, managed and controlled. This involves putting together some form of a schedule management plan, followed by a number of steps suggested by PMBOK (2013), including defining activities and their sequencing; estimating activity duration and resource units; and developing and controlling the baseline and actual schedule. The schedule will need to be monitored, reported on, updated and controlled if timely completion is to be achieved in a realistic fashion.
Remember how important these iterations will be, as each iteration of the schedule should address (as a minimum) the following contingencies:
■ scope-based variations that would reflect the stakeholders’ increasing or decreasing demands on the project
■ time-based variations that might include ‘balancing’ realistic, pessimistic and most likely estimates of the time required
■ cost-based variations that might involve predicting possible increases or reductions in project funding
■ resource-based variations reflecting potential changes in resource skill sets, charge-out rates and availability.
Planning the schedule management approach
As with scope management, a concerted effort is required to put together a document that will guide and direct how the project schedule ultimately is managed throughout the project. Underpinned by internal policies, procedures and documentation, schedule (time) management is not a naturally occurring phenomenon if the number of ‘printed once’ Gantt charts often seen (and clearly out of date) is any indication.
As PMBOK (2013) points out, managing an evolving schedule requires specific actions that will clearly demonstrate that schedule planning, development, execution, management and control constitute a fully embedded process within the project—from start to finish.
Forming part of the project management plan (remember that this is more than just a simple timeline or sketch), this plan may include reference to any of the following:
■ the rationale for managing the schedule
■ any perceived obstacles or constraints impacting
■ stakeholders responsible for the different processes and documentation
■ appropriate control thresholds triggering an intervention
■ timing and format of schedule reports (against the plan)
■ processes required to update the schedule
■ advising stakeholders of the different risk, cost, quality and scope decisions with implications for the schedule
■ project management software for developing the schedule
■ preferred tools to be used (e.g. work breakdown structure [WBS], milestones, Gantt chart)
■ estimating techniques
■ change-control procedures
■ meeting formats and dates
■ rules for calculating percentage complete
■ definitions of actual performance measurement—for example, earned value (EV), treatment for variations, extension of time (EOT).
We already know that the scope will change, and with it the project schedule. As the schedule changes (e.g. behind schedule or ahead of schedule), both the project manager and team (along with other stakeholders) need to know in advance how to respond. Does every variation to the timeline warrant an immediate response? Is EV the only performance measure to use? How does culture influence project reporting? What level of accuracy do stakeholders want? This provides some idea of the value this formal or informal schedule management plan (protocol) can deliver.
Defining the project activities
As seen in Chapter 4, the activities required by the project’s scope and reflected in the WBS are also needed to develop the schedule baseline.
Recall that the WBS is more like an activity list of what work has to be performed throughout the project. Classified under stages, phases or work packages (or other appropriate classifications), these activities will drive the schedule’s compilation, sequencing and amendments throughout the project. When recorded in sufficient detail, all the relevant stakeholders will have a precise idea of exactly what work is required. Clearly, these and other attributes will vary project by project, along with the level of detail required by the stakeholders. However, the following attributes or supporting information should be considered (PMBOK, 2013):
■ meaningful description (consider the verb–noun format)
■ unique identifier—for example, activity code, WBS number
■ activity duration
■ all logical relationships—for example, predecessor and successor
■ provision for lead and/or lag time
■ resource requirements
■ underlying assumptions
■ relevant constraints
■ reference standards
■ imposed dates
■ required resources
■ geographic location
■ the project calendar.
Milestones will also play a part in this activity listing. Milestones are significant events, or a moment in time, within the schedule. They have no duration and, more often than not, they have few if any resources or costs directly attributable to them. Moreover, they are extremely useful for flagging key events (project authorised), signalling the conclusion of a series of related tasks (flooring finalised) or serving as either merge (multiple paths merging into one) or burst (single path breaking into multiple paths) points along the schedule.
With the activities (and milestones) identified, the next step is to begin the process of estimating the activity duration or work period required to complete the activity. ‘Estimate’ is a key word here—it is different from an absolute or definitive duration.
Estimating activity duration can be difficult, particularly if you have little knowledge of the activity, prior experience and/or estimating techniques. To many, a process of progressive elaboration works best where you have access to more accurate and detailed designs, technical specifications or quality requirements. As these inputs change over time, the estimate can, in turn, be revised progressively with increased accuracy.
It is worth noting that estimation outcomes may subsequently create legally binding contractual obligations between the principal, client or buyer and the contractor (supplier) once the project is underway. The same can be said for cost estimates, which are covered in Chapter 6.
A number of accepted estimation techniques are available, including:
■ pre-determined: the estimate is announced by senior management (often in isolation from the other variables/constraints)
■ expert judgement: relying on expertise from individuals or groups with specialised knowledge (or training)
■ analogous: accessing historical data from a similar activity that serves as a frame of reference
■ group decision-making: an interactive approach involving team members brainstorming emerging and iterative estimates with increased accuracy and commitment
■ unit rates: commercial rates where the discrete unit of work can be accurately defined
■ published commercial data: subscription services providing access to current unit costs, production rates and other rates for labour, materials and equipment
■ parametric estimates: statistically combining historical information and other project variables (per square metre, per litre, per hour, etc.)
■ vendor bid analysis: relying on the market through expression of interest (EOI), request for tender (RFT) and other market invitations
■ reserve analysis: a contingency reserve to account for schedule uncertainty and risk (‘known unknowns’)
■ three-point estimate (wide band Delphi): a weighted average requiring optimistic (best case), pessimistic (worst case) and most likely (probable case) estimates that define an approximate range for the expected duration. Two formulae are available for this calculation:
□ tE = (tO + tM + tP) / 3 (triangular distribution)
□ tE = (tO + 4tM + tP) / 6 (beta distribution).
Depending on the stage of the project life-cycle you are in, the accuracy behind the estimates might be very low (e.g. ±70 per cent), particularly if the team has limited experience of this type of project. In these cases, the accuracy level for the estimate might be very low. To elaborate on this point, consider the example in Table 5.1.
Table 5.1 Refining the estimate accuracy throughout the life-cycle
Concept | Plan | Execute | Close | |
---|---|---|---|---|
Estimate | 1 day | 1 day | 1 day | 1 day |
Confidence | 50% | 25% | 10% | 5% |
Best case | 0.5 day | 0.75 day | 0.9 day | 0.95 day |
Worst case | 1.5 days | 1.25 days | 1.1 days | 1.05 days |
Clearly, given the high variability in the duration range in the concept stage from 1.5 days down to 0.5 days, the project manager and team might spend more time revising this estimate or acknowledge that further revisions will be required in the planning stage to increase the accuracy and confidence of the required estimate. Too many greenfield projects start with duration estimates that are marginally confident at best, although for some reasons these get ‘locked in’ with little room to move as the project reality kicks in. Figure 5.1 illustrates this concept of progressive accuracy.
Regardless of the estimation technique used, it is important to remember that estimation is not an exact science (despite some senior management and clients assuming otherwise). Given the constant influence of uncertainty and risk throughout the project, consider the following ‘guidelines’ whenever you are asked to provide an estimate for the activity duration (and similarly with costs). When estimating accuracy, do the following:
Figure 5.1 Estimating accuracy
■ Record your confidence level (+/-where appropriate).
■ Record how the calculation was determined.
■ Record the broad, provisional or absolute nature.
■ Record all underlying assumptions.
■ Record all impacting constraints.
■ Record any contingency amounts.
■ Record an optimistic, pessimistic and likely range.
■ Record all source data.
■ Record details of all stakeholders involved.
In the early iterations of these estimates, try to resist the temptation (or demand) to get your estimates to perfectly match those from the proposal (where indicative, provisional or initial estimates were made). After all, you now have the activity detail, the subject-matter experts (SMEs) and the time (one would hope) to more accurately estimate the duration required. It is far better to have two different project windows in this stage, leaving you room to negotiate further rather than trying to fit all the work into someone else’s unrealistic and out-of-date expectations. This is not to say that the estimates will not finally have to match those already determined for you by others—the point is that you should expect more confidence (and negotiating power), given that the duration estimates have been driven more by the technical nature of the work required and less by potentially extraneous, artificial constraints set by others (for reasons known only to them).
Try to resist allowing the resources who will likely end up doing the work cloud your initial estimates. Focus on the work required, not resource availability, proficiency, charge-out rates, required supervision or the training they require. Yes, these things will become important, but they are not the primary concerns right now. The activity has to be performed in whatever duration the estimates indicate it will be—in other words, the technical nature of the activity is the driver right now. This includes how long you will need to do this work, not who can do it or how that may impact the estimate. That decision (termed the resource reality) comes later.
Critical reflection 5.1
How long is a piece of string? Who knows? How long will it take to give the client what they want? Who knows?
■ Given that a big part of estimation involves looking into the future, in the present moment and based on what happened in the past, how do you possibly convey any true measure of accuracy in your activity and/or schedule estimates?
■ This book makes much of a sense of shared responsibility in project management. How is this relevant to time estimating?
■ Over and above what the book provides, what other avenues do you have to improve the accuracy of your estimates?
■ What are some of the benefits (apart from the obvious) that improved estimation will deliver to the project?
Identifying the resource capability
Having recorded the technical nature of the work and estimated the required duration for performing that activity to some associated measurable standard or quality criterion, the activity now needs to be resourced (and not just by people). Consider the examples of the range of potential project physical, system and human resources in Table 5.2 (Cole, 2010).
Table 5.2 Project physical, system and human resources
Resource | Description |
---|---|
People | Internal or external people with technical skills to perform the activity, associated support, engineers, consultants, designers, trades, administration, etc. |
Material | Consumables, supplies, cabling, concrete, paper, etc. |
Funding | Contingency funding that may be required. |
Facilities | Buildings, infrastructure, offices, meeting rooms, transportation, etc. |
Equipment | Computer, software, printers, etc. |
Space | Workspace may need to be increased or remodelled. |
Time | People’s dual responsibilities (projects and operations) will need to be managed. |
Training | Additional development may be required. |
Technology | Smartphones, remote access, etc. |
Knowledge | Familiarity with building codes, construction techniques, assembling steps, pricing models, etc. |
Organisation | Historical information, policies and procedures, etc. |
Clearly, the type, quantity, characteristics and availability of the required human resources will end up impacting the accuracy of both the activity duration and activity costs, as the project’s success or failure may well ultimately depend on the resources’ technical capability, availability, commitment, motivation, responsibility and involvement, as well as how well they work together.
So what other information needs to be captured in making an assessment of the required resource capability? Consider the following wide-ranging suggestions that could easily be recorded in a resource matrix (Microsoft Project calls it a ‘resource sheet’):
■ resource name: individual name or generic label (e.g. plumbers)
■ resource type: labour, material, etc.
■ resource group: the group to whom the resource belongs
■ resource location: the physical (geographical) location of the resource
■ resource capability: skills, expertise, prior experience, etc.
■ resource quantity: how many/how much will be required?
■ resource availability: the actual ‘free’ time they have to allocate to the project activity (as distinct from their operational workload)
■ resource calendar: what dates are excluded throughout the project (Easter, Christmas or other nominated dates)?
■ resource rate: what are their normal hourly rate, overtime or other fixed/variable costs?
■ resource report: to whom does the resource currently report in an operational capacity?
■ resource development: will any additional training be required?
■ resource evaluation: performance evaluations from past projects.
Bear in mind that some of this information will not be accurate, current or, for that matter, publicly available, given its sensitive nature. Irrespective of this, the resource reality plays a significant role in the final schedule (after activities and their durations have been estimated independently), as well as in any subsequent revisions later in the project.
With regard to the challenge of estimating the number of resources required to perform the activity, the estimation techniques cited earlier would apply, as would productivity metrics, the location of the resources, project management software and lessons learned. However, another useful technique when estimating, assigning and assessing resource impact on the schedule is to produce a resource graph (or load chart) that is overlaid on or compared with the schedule. This allows the immediate effects to be seen, and indicates the required changes that need to be actioned should resources be over-allocated or unavailable. Much like scenario analysis, the project manager and team can assess the resource-by-resource implications following their assignment throughout the project. Figure 5.2 shows how the resource loading can appear when graphed against time.
Experimenting with the sequence
Any number of (scheduling) relationships will exist between project activities. Known more commonly as a sequence, the development of the project schedule is driven by these activity-to-activity relationships in determining when activities start and finish. These (logical) relationships or dependencies identify both the predecessor activity that is performed before the dependent activity in the schedule and the successor activity performed after the preceding activity.
Figure 5.2 Resource loading chart
PMBOK (2013) identifies four different characteristics or attributes that dependencies reflect as they either enable or disable flexibility into the schedule. In other words, rather than having the schedule driven solely by actual dates (must start on, must finish on), the schedule can be constructed based on this logic. The four dependencies are:
1 mandatory: fixed (hard) dependencies driven by physical limitations, regulatory compliance, contractual obligations or technical performance due to the nature of the work being performed (e.g. pouring the slab only after the foundations have been dug)
2 discretionary: preferred (soft) dependencies driven by best practice, local knowledge, past experience or a particular application where a change in the sequence is acceptable (e.g. preparing the draft presentation before all the information has been collated)
3 internal: dependencies between activities that fall within the project team’s control (e.g. waiting for the code to be finalised before testing the software)
4 external: dependencies that fall outside the project team’s control as they relate to relationships between the project and external parties (e.g. waiting for funding approval from a government agency).
Naturally there will be instances where dependencies will be relegated to the ‘back room’, as specific dates will drive some scheduled activities. Examples would include approvals, periodic inspections, testing, reporting or meetings, with each scheduled at an agreed timeline and irrespective (in some cases) of what was scheduled to have happened prior to these dates. Obviously, the more you allow the dependencies to determine the schedule sequence, the more flexibility you will have in accommodating changes later in the life-cycle.
Very few projects enjoy the luxury of having all activities starting or finishing at the same time. In practice, many activities are interdependent and relate to other activities. While many projects will contain a number of independent activities that have no relationship with any other activities in the project (that is, they can start and/or finish without any impact on any other activities), most projects contain activities that are largely constrained by other activities.
Four activity relationship types have been identified in project management, with each of them providing additional flexibility and control over the project schedule. With duration represented graphically as a horizontal bar overlaid against a timescale, the relationship types are:
1 finish–start relationship: activities will start when other activities have finished
2 finish–finish relationship: activities will finish when other activities have finished
3 start–start relationship: activities will start when other activities have started
4 start–finish relationship: activities will finish when other activities have started.
Finish–start relationships
Relationships where an activity (Task B) cannot start until its predecessor activity (Task A) has finished are called finish–start (FS) relationships. These activities are scheduled ‘in series’. Task A must totally finish prior to Task B starting. If Task A is delayed in either starting and/or finishing, it will effectively delay Task B, which is waiting for it to finish. See Figure 5.3 for an example, where Task A could be digging footings and Task B inserting fence posts. Clearly, the project manager and team members must monitor Task A to ensure there are no (unacceptable) delays to Task B, which could ultimately filter all the way through the schedule to impact on the projected finish.
Figure 5.3 Finish–start relationship
Finish–finish relationships
Relationships where an activity (Task B) cannot finish until its predecessor activity (Task A) finishes are called finish–finish (FF) relationships. These activities are scheduled ‘in parallel’. Task A must totally finish prior to Task B finishing. Here, the emphasis is on both activities finishing; their starting times are immaterial. If Task A is delayed in finishing, it will effectively delay the finish of B which is waiting for Task A to finish. See Figure 5.4 for an example, where the completion of the fire drill evacuation (Task A) allows the safety officers to finish monitoring the drill (Task B). Clearly, the project manager and team members must monitor Task A to ensure there are no (unacceptable) delays in finishing which would translate to delaying the finish of Task B. Again, these could delay the finish of the project.
Figure 5.4 Finish–finish relationship
Start–start relationships
Relationships where an activity (Task B) cannot start until its predecessor activity (Task A) starts are called start–start (SS) relationships. These activities are scheduled in parallel. Task A must start in order for Task B to also start. Here, the emphasis is on Task A starting only (not finishing) as the trigger to starting Task B. Their finishing times are immaterial. If Task A is delayed in starting, it will effectively delay the start of Task B, which is waiting for Task A to start. See Figure 5.5 for an example, where the start of the meeting (Task A) allows the minute-taking (Task B) to start. Clearly, the project manager and team members must monitor Task A to ensure there are no (unacceptable) delays in starting, which would translate to delaying the start of Task B. Again, these could delay the finish of the project.
Figure 5.5 Start–start relationship
Start–finish relationships
Relationships where an activity (Task B) cannot finish until its predecessor activity (Task A) starts are called start–finish (SF) relationships. These activities are scheduled ‘in series’. Task A must have started in order for Task B to finish. Here, the emphasis is on A starting only (not finishing) as the trigger to finish Task B. If Task A is delayed in starting, it will effectively delay the finish of Task B, which is waiting for Task A to start. See Figure 5.6 for an example, where the start of the morning security team (Task A) enables the members of the overnight security team to finish their shift (Task B). Clearly, the project manager and team members must monitor Task A to ensure there are no (unacceptable) delays in starting, which would translate to delaying the finish of Task B. Again, these could delay the finish of the project.
Figure 5.6 Start–finish relationship
Accelerated or delayed delivery
Another area of flexibility that the schedule permits is the option of using either lead time and/or lag time. Be aware, though, that any of the four relationship types identified above can be scheduled with either lead or lag time—however odd or illogical the relationship becomes (e.g. start–start with lead). Anything is possible: it is just the tradeoff (to the schedule) that you must manage. (Note: software programs will allow you to schedule illogical task relationships, so be careful. The programs are nothing more than graphical databases, not intelligent life-forms critically assessing the efficacy of your logic.)
Lead time
This is sometimes known as acceleration or compression—both can potentially take time out of the project. With reference to the traditional finish–start relationship identified earlier, Task B could start earlier than the finish of Task A by taking advantage of lead time. Essentially, Task B would start after Task A had partially finished (that is, finished up to a point). The ‘in-series’ activities move to an ‘in-parallel’ format with the overlap representing the lead time or the time effectively taken out of the schedule. An illustration is given in Figure 5.7. Be aware that any of the activities in the relationship types cited above can be scheduled with either lead or lag time.
Figure 5.7 Lead time (intentional acceleration)
Lag time
This is sometimes known as delay or prolongation—both can potentially add time to the project. With reference to the finish–start relationship identified earlier, Task B could start later than the finish of Task A by taking advantage of lag time. Essentially, Task B would start after Task A had finished and then some. That is, the start of Task B is delayed even though it could have started right after Task A finished. In this case, the ‘in-series’ activities remain ‘as is’, with the space between the bars representing the lag time, or the time effectively added to the schedule. An illustration is provided in Figure 5.8.
Perhaps now is the time to discuss some advantages and disadvantages of the WBS—our first foray into a specific scheduling tool—see Table 5.3. Remember that the WBS is an expansion of the proposal document—in greater clarity (or granularity or decomposition). If the activities are not identified in the WBS, they will not be completed in the project.
Figure 5.8 Lag time (intentional delay)
Critical reflection 5.2
It seems that project management has been reduced to long and short horizontal task bars, diamond-shaped milestones and connecting lines suggesting that multiple relationships are possible throughout the schedule.
■ Think about the information gathered, the stakeholders engaged, the meetings held, the questions asked, the decisions taken, the time involved and the documentation produced to get you to this stage in scheduling the project.
■ Think about how impoverished and incomplete your schedule may well be if some of the above actions were not undertaken.
Table 5.3 Advantages and disadvantages of the WBS
Advantages | Disadvantages |
---|---|
It captures all activities required to complete the project. | It can be time consuming to complete, especially by people with limited experience. |
It identifies the relationships between activities. | A ‘table’ of information does not necessarily portray a schedule. |
It is easily read in the table format (‘list of things to do’). | Errors in logic can occur because information is often listed sequentially, numerically or linearly. |
It confirms a common understanding of project scope because work not in the WBS is outside the scope of the project. | The resources may not be identified at the time it is prepared. |
It provides tabular examination of the key aspects of the project schedule. | It might not record in sufficient detail the description of activities. |
It can be filled in by the relevant resources working on the project. | Some activities might be constrained by factors other than predecessors. |
The levels shown are sufficient to achieve estimating accuracy as each descending level shows an increasingly detailed description of the activities. | Bottlenecks, scheduling, resource conflicts and float cannot be identified easily. |
It shows the deliverable-oriented grouping of project elements. | The top-down approach might not be suitable for all types of projects. |
It is drawn top down. | It is hard to promote ownership, commitment and energy to the project by examining a detailed list of work required to be performed. |
It ties a project together. | It encourages using past templates for similar projects. |
It makes a complex (large) project manageable. | It may limit the attributes captured (subject to format). |
It can often be reused in other similar projects. | It is difficult to get a holistic overview of the project. |
Don’t get hung up on time just yet
Up to this point in the scheduling stage, the WBS has served us well. It has captured the activities required by the project, duration forecasts, predecessor relationships (which also generate the start/finish dates) and the preferred resource allocations (although we will revisit resource allocations in more detail in a later chapter).
However, the usefulness of the WBS at this point has now become limited. The WBS could be thought of more in terms of a list of work, or what Microsoft Project calls an ‘entry table’. What is now needed is a picture of our project and, more importantly, a picture of our project’s logic, which the WBS accurately (we hope) recorded. The tool that delivers this information is known as the network diagram (formerly known as the Program Evaluation Review Technique—PERT) and illustrates:
■ the project’s logic
■ the relationships that exist between all the required activities
■ the flow of work throughout the project
■ where the critical path lies through the project (this will be covered shortly)
■ exactly where potential bottlenecks are
■ how the project is ‘tied’ together
■ how each activity is required for the project to be finished.
Figures 5.9 and 5.10 reveal that the network diagram is a lot like a flowchart that depicts the sequence of activities needed to complete a project. When drawn, the network consists of a series of activities (sometimes referred to as nodes) and connecting lines and arrows, indicating the relationship between the activities and the direction of the project. The diagram may be referred to as a ‘logic network’, a ‘PERT chart’, or a ‘precedence diagram’, and will contain a mix of either an ‘in-series’ path or ‘parallel’ paths.
Figure 5.9 Network diagram (linear path)
Figure 5.10 Network diagram (parallel paths)
Some simple rules for drawing network diagrams
When drawing the network, a few simple rules will be beneficial—not only to ensure it is technically correct, but more importantly to ensure that you can maximise the network to improve your scheduling (and ultimately your project success). Consider the following:
■ There is no timeline drawn (this is one of the later advantages the Gantt chart has over the network diagram).
■ Time (figuratively speaking) flows from left to right through the diagram.
■ Each activity is located in order of dependency as dictated by the WBS.
■ Lines should be pencilled in to record links, ensuring that all activities are connected to the network (i.e. they are on a path).
■ The network can be drawn either ‘in series’, which is a straight line or linear network with one activity following directly on after its linked predecessor, or ‘parallel’, where there are two or more paths of linked activities through the network from start to finish.
■ The schedule direction is indicated by the connecting lines and arrows.
■ Each activity has at least one connecting line going in and out of it (the exceptions being the project commencement activity and the project-completion activity).
■ Try to avoid crossing lines where possible (they make the network harder to read and interpret).
■ Don’t forget to work backwards to check for errors of logic. Two common errors are dangling activities—activities that are not a predecessor to any other activities in the project (such an activity effectively dangles in the network without being connected to the project path or to the finish of the project), and looping or cyclic errors that make an endless loop in the network.
While not technically a rule, one final suggestion when drawing the network diagram is to consider using a whiteboard on which to draw the activities. This way you can easily erase and redraw the activities and/or the relationships. A variation on this theme is to use Post-it® note pads and write the activities details down on each piece of Post-it paper (including milestones). Then place the Post-it paper on the board and create your project’s schedule. In this way, any errors in the logic can easily and quickly be accommodated by removing the Post-it paper. This can also be extremely beneficial if the project team members are involved, as they participate in ‘creating’ the schedule and jointly make the relevant decisions as the project logic unfolds.
Let’s now see how the WBS and the network diagram mesh together. Recall that the WBS captures all the activities required to be completed by the project—activities referring to all stages, activities and/or milestones. The network diagram shows the logical and sequential scheduling of those activities. Figure 5.11 brings these tools together to show how the WBS is transformed into a network diagram.
Figure 5.11 Migrating from the WBS to the network diagram
When first drawing the network diagram, concentrate on checking your schedule logic—that is, the relationships you have established between the activities, as reflected in the predecessor column. What might look logical and manageable on the WBS can often be complicated and illogical when drawn as the network diagram. At this stage, before we introduce the concept of critical path analysis, think of the network diagram as a great way of checking whether the schedule is workable, whether all the activities to complete the scope have been captured, and whether all the activities are free from scheduling errors (dangling and looping errors).
Now, with a firm understanding of the network diagram in place, it is timely to reflect on the possible advantages and disadvantages of this tool. These are summarised in Table 5.4.
Let’s recap on what our project journey has covered so far:
■ The project was initiated by someone for a reason—a problem, an opportunity, market pressure, government requirements.
■ A scope baseline or proposal document was developed and agreed, with all (key) stakeholders signing off on the document.
■ A WBS was developed to begin the process of capturing all the activities required to deliver the scope, along with relevant attributes.
■ A network diagram was drawn to test the logic and completeness of the WBS.
One of the earliest and most popular scheduling tools is the Gantt chart. Developed by Henry Gantt in 1917, the chart is prepared by listing the work activities as discrete activities on a horizontal axis and by plotting each one against a timeline on the vertical axis (network diagrams do not have timelines, although software can add them). The activity’s duration is shown as a rectangle (or any other shape of choice) on the timescale. In this way, the chart (dependent or independent) activity bars can quickly convey the overall plan, the completed work and the status of the project. Figure 5.12 depicts a (bar) Gantt chart.
Ground rules for drawing a Gantt chart
For many, the Gantt chart is intuitive and user-friendly; for others, it represents a collection of bars that look too much like hard work. In reality, the Gantt chart is easier to put together than the network diagram, and it can be constructed by reference to the following guidelines:
Table 5.4 Advantages and disadvantages of the network diagram
Advantages | Disadvantages |
---|---|
Excellent visual to demonstrate the schedule. | Not everyone understands it. |
When drawing the network diagram, it is an interactive tool (if the team is involved). | Can become difficult to read if the project is large. |
Offers more of a conceptual (if not holistic) view of the schedule. | The connecting lines can become confusing, especially if they start to overlap. |
Increases opportunities for participative decision-making by involving the team. | Adds additional time to developing the schedule (another step) Some people bypass the network diagram and go straight to the Gantt chart. |
Uses the ‘wetware’ (brains) of the team. | The absence of a timeline can limit the analysis the network diagram delivers. |
Tests the logic and accuracy of the WBS. | The amount of information you can display (either on a Post-it or on the node in software programs) can be limited. |
Evaluates effects of changes made to the schedule’s logic. | Simplistic and graphically trivial. |
Identifies activities that create bottlenecks. | Does not convey conditional and/or alternate paths. |
Identifies activities that dangle (no other activity is dependent on them finishing). | Difficult to monitor and report performance. |
■ Record the WBS (software programs normally list this down the left-hand side of the proposed schedule), making sure you can identify and record the activities required, their duration and their predecessors.
■ Determine the appropriate timescale for the project. This is drawn across the top of the proposed chart (timeline).
■ Each activity is now drawn on the Gantt chart under the timeline as a Gantt bar drawn the length of the activity’s duration, and is reflected in line with the timescale shown.
■ Each subsequent bar is drawn on its own horizontal line, with its position on the timeline determined by its activity predecessors.
■ Leave sufficient space between each bar to allow for relationship lines to fit in between and around the relevant activities.
■ Pencil in lines to record links, ensuring that all activities are connected to the network (they are on a path).
■ Each activity should be connected to the schedule (from start to finish).
■ The schedule can be drawn either ‘in series’, which is a straight line or linear network with one activity following directly on after its linked predecessor, or in ‘parallel’, where there are two or more paths of linked activities through the network from start to finish.
■ The schedule direction flows from left to right and is indicated by the connecting lines and arrows.
■ Each activity has at least one connecting line going in and out of it.
■ Try to avoid crossing lines wherever possible (they make the Gantt chart harder to read and interpret).
■ The starting activity (perhaps a milestone would be more suitable) has at least one line coming out of it.
■ The finishing activity (perhaps a milestone would be more suitable) has at least one line going into it.
■ Work backwards to check for errors in logic. As with the network diagram, two common errors are dangling activities (an activity that impacts on another activity or the finish of the project) and looping activities (a group of activities that are dependent on each other on a recurring basis).
Figure 5.12 The Gantt chart (linear and parallel paths)
One important point to stress here (and equally relevant for the network diagram) is the practice of scheduling activities to start ‘as soon as possible’ (front-loading) as distinct from finishing ‘as late as possible’ (back-loading). With a front-loaded schedule, activities that fail to start on time may have the option of slipping back through the schedule to be rescheduled in a later time period (subject to the dependencies in place and the critical path). A back-loaded schedule may leave little if any room to accommodate delays and/or EOT in completing activities without extending the delivery date.
Related to this is the notion of scheduling activities by identifying the ‘earliest they can start’ as opposed to asking ‘What comes next?’ The difference may appear subtle, although the reality is that the former will always attempt to fast-track (front-load) the start of activities and may create multiple paths to achieve this (subject to resource and other constraints) as distinct from potentially adding time (and delay) in a linear fashion.
Here, many people ask why, if the Gantt chart shows all the required detail, you would ever use the network diagram or the WBS tools. If you are one of these people, go back and review the advantages and disadvantages of each tool for a better understanding. Each tool serves a purpose—you just need to know what it is and when to use each. Let’s now look at the advantages and disadvantages of the Gantt chart, as listed in Table 5.5.
Critical reflection 5.3
Logic diagrams, PERT charts, network diagrams, Gantt charts, timelines and other graphical displays of time-based activity may well create unrealistic, though visually appealing, representations of the project schedule.
■ Do you agree or disagree with the above statement, and why?
■ If you were asked to produce a project plan, would you simply prepare a Gantt chart or similar? (The wrong answer here would be to agree with the question.)
■ If a project plan does in fact involve far more than just a schedule, what other information should it capture? (This topic will be canvassed in great detail as you work through the book.)
Table 5.5 Advantages and disadvantages of the Gantt chart
Advantages | Disadvantages |
---|---|
Clearly illustrates the duration of each activity. | Can be difficult to read due to the amount of information displayed (baseline, current and actual data). |
Clarifies the four different types of activity relationships. | Requires the use of software to avoid excessive time spent drawing and reviewing the schedule. |
Illustrates the application of lead and lag time. | Often bears little resemblance to reality. |
Ideal for monitoring actual progress to date. | Time consuming to continually update and report. |
Easy to read from top down and from left to right. | Easily outdated, given the frequency of scope changes and revisions. |
Identifies which activities can float and by how much. | One-dimensional focus on time only. |
Identifies the critical path(s). | Directs time and effort away from ‘doing’ the project. |
Easy to allocate resources. | May be meaningless in light of information quality and timeliness. |
Easy to resolve resource over-allocations. | Possible issues with version control. |
Easy to view different iterations of the project. | Requires a formatting protocol across the project team. |
Easy to compare the current version of the schedule with an earlier version (baseline). | Difficulties with project-by-project comparisons if different formats are used. |
Easy to view the impact network analysis can have on the project. | May infer that ‘as scheduled’ is in fact the only way the project can be scheduled. |
Working with the critical path
The next challenge is to analyse the schedule and focus on the critical path method (CPM). Something in the schedule will be critical, in the scheduling sense of the word. Perhaps an example will help to explain this crucial difference. To most people, having lunch would seem to be a critical activity during the day. It would be an important activity to complete from a nutritional sense and from a balanced lifestyle sense, and would be a fantastic way to get out of the office. However, if the start time of the lunch activity can be postponed (that is, delayed) without delaying the original agreed finish time of your workday, then lunch is not a critical activity. Important—yes; crucial to your personal wellbeing—yes; but not critical to the completion of your workday as originally scheduled. In effect, if lunch could be rescheduled to any time during the day without delaying your finish time at work, it is not critical.
It is important to note that the term ‘critical activity’ can be applied to any of the following:
■ a single activity—known as a critical activity
■ multiple (independent) activities—known as critical activities
■ multiple (dependent) activity/activities—known as the critical path(s)
■ a milestone—known as a critical milestone.
To determine the critical activities, paths or milestones within the schedule, you will need to identify the components of the schedule that comply with the following elements of critical (path) analysis:
■ the longest path(s) throughout the schedule: where a path is indicated by activities joined together by predecessor relationships; collectively, the activities on this path represent the longest duration scheduled for the project’s completion
■ the path(s) or activities(s) with zero float: a path or activities cannot be started later than the scheduled start date of each activity on the path without delaying the project’s scheduled completion time
■ the activities(s) or milestone driving the end date of the project: where the end date is the scheduled finish date of the project
■ the shortest completion time of the project: where the project cannot be completed in any less time within the current schedule.
Note that all four actually say the same thing.
The critical path is found first by identifying the different activities(s), path(s) and/or milestones in the network, then by determining two pieces of information: the activity sequencing and the duration of each activity. The technical nature or identity of the activities themselves is irrelevant, as the focus is time-based analysis only. You will also need to consider that, in some projects, if activities can be completed before a specified end date, there will be no critical path, activities or milestone. Next, identify all the different ways (paths, routes, directions, etc.) of getting from the start of the project to the final activity. Add up the duration of each path (the sum of the individual activities). The longest path will be the critical path—that is, the path where scheduled activities must start and finish as scheduled (on time) for the project to finish as scheduled (on time).
The path is critical because it represents the longest path through the network, and thus identifies essential activities that must be completed on time to avoid delays in finishing the project. A delay in any one of these critical activities means a delay in the project itself. In effect, the critical path demonstrates greater ‘constraints’ and ‘control’ because those activities simply must start and finish as scheduled. Any unforeseen delay in the critical path will immediately delay other critical activities and the project. It is worth noting, however, that the critical path does not always need to flow from the start of the project to the end—it could be the last activities in the schedule or it could be the final milestone, or it could begin at any point in the schedule, depending on how much float-time there is for activities to be delayed or extended without impacting the completion date, and where this float occurs.
In a linear schedule, the activities will always be critical, as each consecutive activity effectively adds time to the schedule so that this collective time drives the schedule. Each activity takes time and adds time, which in effect becomes critical. Note that when conducting this critical path analysis, you need to analyse the schedule as ‘given’—that is, do not revise the durations, do not rework the schedule, do not downgrade the scope by deleting activities. Work with what you have. After your analysis, all the above suggestions might be required; however, they are determined after your analysis. Figure 5.13 represents the critical path in a network diagram, while Figure 5.14 shows the critical path through a Gantt chart.
However, your project may well have multiple critical paths, in which case each of the paths would add up to the same duration. In these cases, a delay in either of the critical paths would extend the project. In the case where you needed to shorten the project’s completion time, both critical paths would have to be shortened by the same amount. As Nicholas and Steyn (2008) warn, having multiple critical paths can dilute management focus because there are actually others things going on in the project that are critically important too—though the definition of ‘critical’ would change in these cases.
Figure 5.13 Critical path (network diagram)
Figure 5.14 Critical path (Gantt chart)
Critical reflection 5.4
Something will always be critical in your project, even if it is the very last thing you do.
■ Has the above information on the critical path changed your understanding of what you thought was critical in your project? If so, why?
■ How will you balance the technical nature of the required work (technicians will believe their work is critical) and the agreed time for the project? In other words, can you ignore one and favour the other?
■ In cases where the timeline keeps getting extended, why bother with critical path analysis? (Think carefully about this response.)
The critical path or the critical chain?
During planning and execution, critical path analysis will indicate whether the schedule is achievable, whether the objectives are realistic and whether any changes are needed in balancing activities and resource decisions. Later, during the ‘rollout’, the critical path will indicate areas of concern in the schedule—where things are going wrong and where action can be taken so that overall project objectives can be realised. In fact, any of the following advantages in Table 5.6 would be full justification for ensuring that the critical path is closely monitored, while the disadvantages should suggest some measured caution.
But what about instances of simply having no more resources to assign in any given period? Will this impact the critical path? As PMBOK (2013) suggests, the resource-constrained critical path is known as the critical chain, and takes into account the effects of resource allocation, resource optimisation, resource levelling and activity duration uncertainty on the critical path. Derived from the theory of constraints (TOC), the critical chain has a resource focus, whereas the critical path has a time focus. Through the use of buffers and buffer management, the critical chain targets resource availability and seeks to improve productivity where possible. By factoring in individual performance (not to mention Parkinson’s law where the work expands to fill the time available), the critical chain takes the contingency out of the activities and creates buffers in the schedule to accommodate likely overruns—which effectively gives the project team tighter deadlines to comply with (Velopi: adapted from online resources). Two buffer types are commonly used:
Table 5.6 Advantages and disadvantages of critical path analysis
Advantages | Disadvantages |
---|---|
It contains those activities that must be closely managed. | Can be time consuming to calculate manually. |
It is the path with no delays possible. | Suggests other non-critical paths can be ignored. |
The path requires accurate estimation. | Not an easy concept to convey. |
The critical path requires regular performance reporting. | Confusion occurs between critical in the dictionary sense and critical in the scheduling sense. |
It is crucial that timely corrective action is taken. | Does not automatically guarantee agreement between estimates and/or management. |
It may trigger and direct the necessary contingency actions. | Can place emphasis on particular activities only, not on all project activities. |
The path requires tight variation analysis and controls. | Difficult to locate in complex network diagrams. |
Calculates the project completion time. | Reduces scheduling analysis to just timeline-based decisions. |
Focuses attention on the activities that will delay the project if those activities themselves are delayed. | Becomes largely irrelevant if all project paths are equally critical. |
Confirms critical activities path. | The project’s completion can be governed unduly by the critical path. |
Helps prioritise resource allocation should resources be over-allocated across multiple activities. | |
Confirms where the float exists. | |
1 project buffer: this is placed at the end of the project plan and protects the project finish date from slippage along the critical chain
2 feeding buffer: added to all the non-critical chains to increase the length of these paths to equal the critical paths.
When using the critical path method, mistakes, omissions and rework problems will often delay the schedule, as the focus remains on the project completion date. Consequently, early completions are seldom published and rarely benefit the project (unless end dates are brought forward). By making the planned contingency explicit, the project team is encouraged to get straightforward activities completed quickly and to flag any delays in order to access the nominated buffers. Thus, the critical chain is a more aggressive, if not accurate, schedule than the critical path. The clear advantage for the project manager is that the use of contingency is visible and tracked, and its use justified (Velopi: adapted from online resources).
However, do not be fooled into thinking that the critical path or critical chain are the only things that matter to the schedule’s completion ‘on time’. Clearly, every activity must be completed for the project to be completed—be they critical or resource constrained. So, while it is the critical activities that will delay the project, no activity can be ignored if the project is to be properly managed (time and resource decisions) through to successful completion. Figure 5.15 reflects the sequential steps involved in applying the theory of constraints to your project.
Figure 5.15 Critical chain method
At best, the project schedule is a graphical display of pure intent. Perhaps it is a little harsh to call a project schedule ‘a work of fiction’; however, what made sense in the office on the computer with project planning software may not be evident in the execution environment of the project. A plan is just that: a plan—nothing more and nothing less.
However, given that a plan exists, actual performance, progress and completion against that plan can be measured and reported. In other words, time, cost and scope variations can be tracked, reported, managed, updated and/or controlled as required. Remember that any number of things will change the schedule baseline, and these deviations will need to be recognised as either minor or major, with associated preventive or corrective actions being put in place to minimise the risk of these changes (PMBOK, 2013).
To effectively control the project schedule, the following actions should be considered:
■ publishing the agreed schedule
■ updating changes to the schedule as they occur
■ determining the current reporting date of the project
■ assessing the current status of the project against the published plan to identify progress (completed, actual duration), status (current, physical percentage complete) and forecast (outstanding, remaining duration) performance
■ rescheduling remaining activities
■ recirculating the agreed schedule revision
■ conducting retrospective reviews and walkthroughs to record lessons learned.
Figure 5.16 displays three versions of the same project—the baseline, the current schedule and the actual performance to date—to demonstrate the practice of schedule control.
With regard to the various tools you could use for controlling the schedule, trend analysis will map performance to look for improvement or deterioration in the project performance; and earned value analysis (EVA) will look at both cost and schedule variances to reflect the planned, earned and actual value delivered by the project, either cumulatively or at a single point in time. Experimenting with lead and lag time may also identify options, as would modelling techniques for crashing the project for the least incremental cost (PMBOK, 2013).
Figure 5.16 Tracking actual performance against the baseline and current schedule
Perhaps the real key to schedule control is the timeliness of the information reported, along with the detail and justification contained. As an example, simply reporting that the project is 40 per cent complete on any given date is meaningless if there is no project schedule for this to be reported against (and the status date). Depending on exactly what you are measuring and what part of the timeline you include, 40 per cent could indicate: just work complete to date; that the project is behind schedule; that the project is ahead of schedule; or that the project is on schedule. You really have no way of knowing, nor should you always rely on the honesty and integrity of those doing the reporting. They have their own agenda, reporting requirements and protocols that either enhance or mitigate their performance, which may well be at odds with what the project needs and despite what is expressly required in the contract.
Critical reflection 5.5
Baseline schedules, current schedules and actual performance all sound like a lot of scheduling chatter. However as with other topics, distinctions are important—particularly when measuring ‘performance’ against ‘promise’.
■ Given that the project scope will likely change at some stage throughout the project, what is the point of capturing schedule baselines?
■ Would scheduling as you go (planning it as you deliver) be a better approach, and why? (The short answer would be no, it wouldn’t.)
■ Given that schedules will often be comprised of long and short bars (and some tabular data in columns), how can you visually represent your current schedule and actual performance in your timelines or on Gantt charts (in addition to your baseline schedule)?
■ How up to date do you think all three schedules (baseline, current and actual) should be throughout your project, and why? (It sounds like a lot of work on someone’s part but perhaps there are key benefits.)
5.1 What is the value behind having a schedule management plan?
5.2 What information does WBS capture and how does this help scheduling?
5.3 Activity duration and resource estimates are often not precise calculations. What techniques are available and how would you defend your choice of technique?
5.4 What is the difference between the critical path and critical chain methods?
5.5 Explain why project schedules have to be developed, tracked, reported and controlled throughout the project?
Three months in, the superintendent (Mike Miller) for Blackwood Coal had an inkling the company’s $100 million coal plant project was behind schedule. It was an inkling that would soon bear fruit as the project laboured under poor scheduling, poor work performance and poor management.
With the tender awarded in November 2016 and a scheduled start onsite of February 2017, all parties had agreed to the practical completion (PC) date of February 2018. Even when Blackwood Coal brought forward the start date to December 2016, the contractor (DWI Mineral & Mining) accepted the accelerated start date, not to mention the $18 million advance they requested to cover pre-start and mobilisation expenses. The PC date was also revised to December 2017. While DWI appeared only too happy to start earlier and get some much needed cash flow, Mike could see little evidence, if any, of his investment in terms of the contracted performance three months later (25 per cent into the schedule with 18 per cent of the budget spent). And Mike’s concerns were not allayed as he stared at the high level, baseline Gantt chart the contractor had issued back at contract award (which was effectively now three months out of date).
The problem was compounded by DWI only issuing schedule updates for the next two-week look-ahead (without the critical path), which left Mike wondering what he wasn’t being told, why and what was happening to the PC. He realised he had reservations about how the ‘work’, as per the design and construct (D&C) contract was being delivered technically and managed professionally. Having engaged a reputable contractor, he had assumed, at least on some level that, as the company’s representative, he would be involved in the ongoing monitoring, reporting, adjusting and controlling of the schedule (in addition to administering the variation protocol). While acknowledging the rights and obligations of DWI under the bespoke D&C contract, Mike continued scouring through the contract and his file notes from the pre-award negotiations, trying to find any meaningful, practical reference to defining his role and involvement in proactively ‘managing’ the schedule. A qualified engineer, Mike had always known that the clauses pertaining to the ‘work’ were very brief and open-ended—particularly those relating to performance reporting.
With DWI struggling to meet key dates and finding no solace in his desk audit of all the documents, Mike called his team into his office to try to put together a blueprint that would ensure PC was met without being seen to be helping the contractor.
With DWI struggling to meet key dates and finding no solace in his desk audit of all the documents, Mike called his team into his office to try and put together a blueprint that would ensure PC was met without being seen to be helping the contractor. After three hours, the team came up with the following suggestions:
■ A common project management software platform for improved schedule diagnostics.
■ Specifying the level of detail used for WBS.
■ All logical relationships visible in Gantt charts.
■ Critical path and PC in all Gantt charts and reports.
■ Identification of who owns the schedule float (client or contractor).
■ Identification of time-based control thresholds that would trigger reporting and intervention.
■ Comparison of actual performance against baseline performance.
■ Assessing project progress, status and forecast information.
■ Inclusion of PC on all Gantt charts and reports.
■ Updated schedules reviewed prior to meetings.
As Mike reviewed these great ideas, he remained committed to building the relationship with the DWI project manager in seeking to influence the ‘usefulness’ of the information Blackwood received.
Questions
1 How would a schedule management plan have helped Mike’s project from day one?
2 Does Mike have the right to dictate to DWI the level of decomposition in presenting reports to Blackwood?
3 Should Mike adopt the suggestion that critical path and PC be in all Gantt charts and reports, and why?
4 What is the value of updating the Gantt chart and re-circulating this to all stakeholders?
5 Would assessing progress, status and forecast data have helped Mike ‘co-manage’ the schedule more proactively?