The Ultimate Guide to Controlling the Project Schedule

Schedule controlling is, together with cost controlling, at the core of successful project management. Having a project delivered on time and within budget are the two main concern of any project manager, and that’s not for less: these are the two most sensitive areas for investors and clients.

In our previous article, we presented several techniques, varying from basic to complex, to control the budget of your project and implement corrective measures when necessary. We left out the discussion related to schedule monitoring because we wanted to target our efforts at how to properly manage your project budget. Now, however, our focus will be on the schedule side. This article will present several techniques that you can use to control and monitor your project schedule, and we will extend the example from the previous article to include schedule concerns, variance, and performance.

1. Collecting the necessary information to properly control and monitor the project schedule

There are a few documents you want to have with you in order to have enough information to properly monitor the schedule of your project. First of all, the schedule baseline contains the initial schedule estimates for each task. This is the base document for you to benchmark actual schedule performance. In addition to that, the schedule management plan describes the processes to monitor and, if there are any corrections to be made, properly update the schedule of your project.

Last but not least, you want to have a detailed account of the work performed for each task. It’s not possible to monitor and control the schedule of your project if you have missing information about the execution of tasks, or if the information is not precise and objective. Therefore, you should start by defining clear processes and performance metrics so that the project team is clear on how to properly report their work. This way, generating work performance reports will become more straightforward, and the reports will provide more relevant data for your analyses.

2. Extending our example: The House&Co construction process

In the article about cost control and monitoring, we have introduced a considerably elaborate example of a luxury house construction company to help us understand the many different techniques related to cost estimation.

In summary, the WBS of House&Co construction process is composed of three major project phases, each one broken down into several tasks:

1. Customer debriefing and house concept: include tasks such as meeting with the customer, developing the house concept, and sketching the exterior design.
2. Blueprint design: includes tasks such as creating a prototype of the rooms distribution, discussing the blueprint with the customer, and calculating construction costs.
3. House construction: includes tasks such as preparing the terrain for the construction of the house, incorporating hydraulic and electric elements, and finalizing the house interior.

While presenting a simplistic approach to how to conduct a construction project, the WBS (check Table 01 below) shows us some important concepts that need our attention. Firstly, there are several sequence constraints: it’s not possible, for example, to start building the house without having a final blueprint of its structure and raw material requirements. Secondly, we notice that some of the tasks can be carried in parallel: developing the house concept and sketching the house exterior, or incorporating the hydraulic and electric elements of the construction. These two characteristics are important when controlling the schedule and performing tasks such as resource leveling and what-if scenario analysis.

2.1 Project data: Sequence constraints, cost and schedule estimations, and critical path

Now that we quickly revised the overall structure of the construction project’s Work Breakdown Structure, we can extend the example’s budget data by including several other numbers, estimations, and schedule concerns. The table below adds three critical dimensions to the project data:

1. Task requirements: it shows how each task depends on its predecessors to be executed. The task requirements establish the sequence constraints of the project.
2. Effort and duration: the concepts of effort and duration are, respectively, the total time spent to finish a task and the total duration of the task in terms of 8-hour working days. To make the two concepts clearer, think about effort as the total number of hours you need to finish the task, and the duration is the number of days you need (or have) to complete it, considering each day as an 8-hour interval. We include the labels Budgeted # of Hours and Budgeted # of Days to clarify the numbers. For our example, we will assume that the number of days is given by the stakeholders (this is normally the case, since the deadlines are normally established by the client), and that the number of hours required to finish each task is estimated by your team. Take a look at tasks 1.1 and 1.2. For the first task, the required effort can be fit in a day of work, so it’s enough to delegate the task to one of your team members. Task 1.2, however, has an estimate of 72 hours of word and only three days to be executed, which means that your team will have to execute a total of 24 hours of work per day. This cannot be done by a single employee; in fact, here you will need at least 3 people working full-time on the task. Having both estimates (the number of hours and the number of days) is essential to perform thorough calculations when it comes to the allocation of team members.
3. Color coding: the red tasks represent the project critical path, and the green tasks show those that can have a small delay when being executed (or that can have their start postponed). For a complete explanation of how to calculate the critical path, as well as to calculate the float of each task and the schedule of the entire project, check our ultimate guide to building the project schedule.

Here is the complete table, now with three extra columns: task requirements, budgeted number of hours and budgeted number of days.

Task Description	Task req.	Budgeted Cost	Budgeted # of hours (effort)	Budgeted # of days (duration)
1. Customer debriefing and house concept
1.1 Meet with the client to collect concept requirements	-	50	8	1
1.2 Brainstorm with project team about house concepts	1.1	100	72	3
1.3 Summarize brainstorm information	1.2	50	8	1
1.4 Develop the house concept	1.3	200	120	5
1.5 Sketch the exterior design	1.3	150	48	3
1.6 Meet with the client to present the house concept	1.4,1.5	50	8	1
1.7 Update the house concept based on the customer feedback	1.6	50	32	2
2. Blueprint Design
2.1 Create a prototype of the room distribution in the house	1.7	200	48	3
2.2 Refine the prototype to include engineering and architecture concerns	2.1	150	48	2
2.3 Calculate the construction requirements, cost and schedule	2.2	150	32	2
2.4 Discuss the prototype, the costs and the schedule with customer	2.3	50	8	1
2.5 Update the prototype based on the customer feedback	2.4	100	16	2
2.6 Develop the final blueprint based on the updated prototype	2.5	200	48	3
3. House construction
3.1 Prepare the terrain for the construction	2.2	1000	400	10
3.2 Build the house foundation	2.2	1500	1200	30
3.3 Build the internal structure and house walls	3.1,3.2	900	600	15
3.4 Incorporate hydraulic elements	3.3	600	400	10
3.5 Incorporate electric elements	3.3	600	480	12
3.6 Build the house roof	3.4,3.5	800	600	15
3.7 Paint the house exterior	3.6	500	280	7
3.8 Build the interior details of the house	3.6	1200	800	20

Table 01: The expanded WBS of House&Co construction process

With this data, we can plot a chart summarizing the cost and schedule progression of the project. Here is what it would look like, with the x-axis being the duration in days and the y-axis the cumulative cost. Notice that the duration in days reflects the duration of the critical path, but that the cumulative cost includes the price of each and every task. The chart also simplifies the calculation of the costs incurred by accruing the entire amount to the end of the execution of each task (rather than distributing the cost equally to each day).

In any case, the chart is a very good approximation of a real-life estimation process (many real-life projects don’t provide such level of details), and we can use it to make many comparisons between our planned and actual data.

3. Four effective tools and processes for schedule control and monitoring

Now that we have expanded our example to include schedule data, we can use this information to discuss several important schedule controlling and monitoring techniques.

The process of monitoring the schedule of a project is, in many ways, similar to controlling its costs. We are interested in whether the tasks are being performed within the established deadlines, if there are any sensitive delays, as well as which parts of the WBS are flexible in terms of schedule so we can adjust our project to compensate for any critical delay.

3.1 Planned vs. actual schedule analysis

The planned vs. actual schedule analysis works by simply comparing the estimated forecast of each task with the actual time taken to accomplish it. If you observe the table from the example we provided, you will see that the schedule estimations are presented by the number of hours required to complete the task. While the deadlines are normally given by the final customer and they are normally a fixed date (requiring you to estimate task completion also in terms of days), it’s your job as a project manager to correctly estimate the hours needed to complete each task and to consequently calculate the amount of human and material resources you will need at each point of the project.

If we used only the days, for example, there would be considerable room for misunderstanding and confusion. How many hours should we track on a day of work? What if the team had to temporarily switch the focus to another project due to a critical issue (would we track the day or not)? How many people are actually required to complete the work within the given number of days?

When we look at Table 01, we see that most of the tasks require more hours per day than the normal 8-hour work journey. This means that you will have to assemble a team of people working simultaneously in the same task to ensure its completion within the given deadline. The size of the team will vary (for example, for task 1.1 we need one person, while for tasks 3.1 until 3.8 we need at least 5), and allocating people based on their availability is an important part of managing the project schedule.

3.2 Earned value management for controlling and monitoring your project schedule

When we talked about Earned Value Management in the cost management context, our example could explore only the cost dimension of project performance. Now that we have more information about the schedule and time estimates, we can extend our analysis to include both elements. Let’s start by revising and defining several terms and keywords related to earned value management.

Planned Value (PV): The planned value, also known as budgeted cost of work scheduled (BCWS), refers to how much we are expecting to spend in the tasks of our WBS that should be completed up to a certain date. In other words, it represents the sum of the budgets of all tasks that should be done by day X. Let’s use some data from Table 01 to clarify this concept. We estimate that, by day 5, we will have completed tasks 1.1, 1.2, and 1.3. Their respective individual planned values are 50, 100, and 50. This means that the total planned value of the project at day 5 is 200.

Earned Value (EV): The earned value, also known as budgeted cost of work performed (BCWP), is the budgeted cost of tasks that are already completed up to a certain date. Imagine that, on day 5, we were able to complete only tasks 1.1 and 1.2. This means that we didn’t realize any of the value of task 1.3. Our earned value, therefore, is only 150 (the sum of the planned values of both tasks 1.1 and 1.2).

Schedule variance: Schedule variance (SV) is a measure of schedule performance on a project. It is equal to the earned value (EV) minus the planned value (PV). Because it uses budgeted costs to calculate schedule performance, it provides a better measure of whether work is being done or not than simply counting time. Just tracking days and hours is not enough to measure productivity (your team might just be procrastinating and wasting time rather than getting something done). Instead, it’s better to measure how much value was earned at a certain point in time and compare it to your original estimates. This is why the EVM schedule variance is a useful metric in that it can indicate a project falling behind its baseline schedule. The equation for calculating the Schedule Variance is given by:

SV = EV − PV

• If we accomplish more work than the estimated, our earned value will be greater than our planned value, leading to a positive schedule variance.
• If we accomplish less work than the estimated, our earned value will be lower than our planned value, leading to a negative schedule variance.

Schedule variance percent: Schedule variance percent (SV%) is obtained by dividing the Schedule Variance (SV) by the original Planned Value (PV). A positive schedule variance (EV > PV) will lead to a positive schedule variance percent. A negative schedule variance percent (EV < PV), on the other hand, means that we have produced less value than our original estimates. The equation for calculating the Schedule Variance Percent is given by:

SV% = SV/PV = (EV − PV)/PV

Schedule performance index: Schedule performance index (SPI) is used to benchmark the actual progress of a project against the planned schedule. The SPI is given by:

SPI = EV/PV

If the SPI equals 1.0, we can conclude that, up to the point in time when the SPI is calculated, the actual progress of the project, measured through its earned value, equals the expected progress of the project (the planned value). If, however, the SPI is lower than 1.0, it means we are behind schedule (this can be also confirmed by deriving the SV and SV% values, which will be negative in this case). The SPI can be used together with the cost performance index to measure the overall project performance in terms of both schedule and cost.

Chart 02 illustrates how EV, PV, and the performance indexes presented above relate to each other. At point 1, the Earned Value of the project (the budgeted cost of the tasks that are already completed at the date of calculation) is higher than the Planned Value. This means that both SV and SV% will be positive, and the SPI will be greater than 1.0. At point 2, however, the Earned Value is lower than the planned value, leading to negative SV and SV%, and to an SPI lower than 1.0.

We can add a third element to this chart, the actual cost of work performed. Take a look at the updated graph below. A third line was added to represent the actual costs of the work already performed. This integrates the concept of cost control into the same context as schedule control. Both the cost and the schedule variance are now visible and can be used to analyze the project performance.

3.2.1 - Calculating schedule and cost performance for Home&Co

Now that we understand the basic idea behind using Earned Value Management to calculate both schedule and cost performance, let’s update the numbers from our example and use them to calculate the overall project performance.

In our previous article, we didn’t care about when the tasks were completed; instead, we focused on how much we spent to complete them. Here, however, we are also considering the time dimension, so let’s bring the old numbers back and extend them with information about the budgeted number of hours and days, as well as some actual data on these metrics.

Task #	Budgeted Cost	Actual Cost	Budgeted # of hours	Budgeted # of days	Start day	End day	Actual hours
1.1	50	100	8	1	1	1	8
1.2	100	80	72	3	2	5	80
1.3	50	80	8	1	6	6	8
1.4	200	260	120	5	7	12	144
1.5	150	100	48	3	8	10	52
Total	550	620	256	10	1	12	292

Table 02: Planned vs Actual task schedule for Tasks 1.1-1.5 of House&Co WBS

To fully understand the table above, it’s important to notice that tasks 1.4 and 1.5 can be executed simultaneously. Since task 1.5 had some schedule flexibility, we decided to start it at the latest possible start date without harming the overall project schedule. To help visualize the comparison between the planned and the actual schedule, Chart 04 presents a Gantt Diagram. The gray rectangles depict the planned work, while the green and red rectangles represent, respectively, work that is completed on time and work that is delayed. The black thick line under task 1.5 represents the float of that task.

An important aspect of schedule control and monitoring is the prior definition of the dates when the schedule will be revised. With cost control, looking at the actual and estimated costs of a task at its completion was somewhat acceptable; here, however, you can’t wait until the task is finished to check whether you are on schedule. Instead, you should measure your progress on a continuous basis.

For our example, let’s assume we will check on the schedule of each task every two days. In addition to that, we will make an assumption that the Earned Value is spread linearly over the budgeted days of each task. For example, for task 1.2, at the end of each day, we should have an increase of 33.33% in the Earned Value of this specific task. This linear distribution might not always be the case, as the execution of the project tasks depends on several external factors. If, for example, there is a required formal approval that needs to be obtained before moving on with a specific task, you might want to reduce the expected Earned Value of the day during which the team is waiting for the approval. Say, for example, that task 1.4 requires an approval that takes 6 hours to be obtained. As a result, the team doesn’t have much time left during the first day to get some real work done. As a consequence, you estimate that 5% of the Earned Value of that task will be realized on day one, while the other days will each bring a 23.75% increase in the Earned Value.

For the sake of simplicity, we will assume a linear distribution for all tasks. Have a look at Table 03 (below). We have calculated our PV on each second day of the 5-task period, and we have detailed the earned value obtained from each task individually up to the date. The last column, actual EV, shows how much value we actually earned by the end of each 2-day period. Here is the detailed reasoning behind how the table was built:

• We have assumed a linear distribution of the Planned Value over the length of a task’s execution. This means:
  • Task 1 should realize 50 of its value per day (it has a PV of 50 and is expected to be executed during one day).
  • Task 2 should realize 33.33 of its value per day (it has a planned value of 100 and it requires 3 days to be implemented).
  • Task 3 should also realize 50 of its value per day (same scenario as Task 1).
  • Task 4 is expected to realize 40 of its value per day (it has a PV of 200 and an execution time span of 5 days).
  • Task 5 is expected to realize 50 of its value per day (its PV equals 150 and it requires three days to be implemented).
• Having this in mind, and considering the time constraints presented by the Gantt Chart above (Chart 04), we can estimate how much value should have been realized every two days. For that, we just need to add the expected realized value of each task that will be executed during these two days.
  • We expect to have realized a value of 83.33 by day 2: this is a value of 50 from task 1 and a value of 33.33, equivalent to one day of task 2.
  • By day 4, we expect a value of 150 (we should have completed tasks 1 and 2).
  • By day 6, the total planned value if 240 (the previous PV plus the PV of task 3 and the equivalent of one day of task 4).
  • By day 8, we expect a value of 370 (the previous PV plus two days of task 4 and one day of task 5).
  • By day 10, we expected to have completed all the tasks and achieved the total PV of 550.

Unfortunately, not everything went as we expected. If we look at the Gantt Chart, Tasks 2 and 4 were delayed, causing a total delay of 2 days. In Table 03, we bring the information about how much value was realized for each task over the two-day period considered. Here are some notes so the table can be fully understood:

• Since Tasks 2 and 4 were delayed, their daily value realization was decreased, becoming 25 and 33.33 for each task respectively.
• The Earned Value of day 2 was calculated by simply adding how much value was realized from both tasks 1 and 2. The process is fairly simple, and it just requires an attentive examination of the Gantt Chart that depicts the actual progress of each task.
• The same reasoning was applied to the following days:
  • Days 5 and 6 add one fourth of value from Task 2 (realized on day 5) and the entire value of Task 3 (realized on day 6).
  • Days 7 and 8 add two days of value from Task 4 (days 7 and 8) and one day of value from Task 5 (day 8).
  • Days 9 and 10 add two days of value from both Tasks 4 and 5.
  • Days 11 and 12 add two days of value from Task 4.

Day	PV	Actual EV: Task 1	Actual EV: Task 2	Actual EV: Task 3	Actual EV: Task 4	Actual EV: Task 5	Actual EV
2	83.33	50	25				75
4	150		50				125
6	240		25	50			200
8	370				66.67	50	316.67
10	550				66.67	100	483.34
12	550				66.66		550

Table 03: Incremental Earned Value during schedule control at House&Co

Table 03 brings a lot of information for us. It shows that we were mostly behind schedule during the entire execution of tasks 1.1 to 1.5. The red cells in the last column show that our EV is lower than the forecasted PV. This shows that it’s important to keep an eye on both the earned value and the actual completion date of each task, otherwise we might miss important clues about the progress of the project.

Last but not least, let’s calculate the schedule variance (SV), schedule variance percent (SV%), and the schedule performance index (SPI) as defined above and check whether our schedule performance is improving as the project evolves.

Day	PV	EV	SV	SV%	SPI
2	83.33	75	-8.33	-10%	0.90
4	150	125	-25	-17%	0.83
6	240	200	-40	-17%	0.83
8	370	316.67	-53.33	-14%	0.86
10	550	483.34	-66.66	-12%	0.88
12	550	550	0	0%	1.00

Table 04: Schedule Variance, Schedule Variance Percent, and Schedule Performance Index for House&Co data

As it can be seen, the Earned Value Management technique is incredibly powerful as it gives detailed performance measurements for both cost and schedule monitoring. This section focused on the time dimension, but now it’s just a matter of putting both cost and schedule performance metrics side by side to have a complete overview of the project performance.

3.3 Resource leveling

Resource leveling is the task of distributing your team’s work capacity based on peaks of work demand that might happen during the execution of the project. As you might expect, the demand for work is not linear over the course of a project. At some points, more workers will be required than the total amount of available team members, and at others, the demand will be lower than the supply of workers. Chart 05 shows graphically the variable work demand and the constant work supply.

The essence of resource leveling is in calculating how to distribute workers and work hours in order to (1) minimize the idle time during low demand, and (2) maximize the amount of work done while minimizing the overtime costs and team members’ stress during peak periods.

We have covered in details the resource leveling process in our article about how to construct a realistic schedule for a project and in our eBook with a complete example of how to run complete cost and schedule estimations. Let’s revise the three main steps involved in implementing the resource leveling technique:

1. Start by forecasting how much resources of each type (team members, raw material, etc.) you will need throughout the project. Bring the information together in a resource spreadsheet so you can have an overview of which tasks are the most and the least demanding in terms of resources. The spreadsheet can be used together with the schedule estimation to calculate the daily resource and budget demands.
2. The second step is to Identify the peaks of usage of resources. Use the spreadsheet and the project calendar to identify which periods will have a demand for resources greater than the respective supply.
3. Thirdly, adjust the schedule by delaying tasks that are not a part of the critical path within their flexible schedule. In our example, these tasks would be 1.5, 3.1, 3.4, and 3.7. In a real-world scenario, you normally have more non-critical tasks, and there will be more room to adjust the schedule of your project. Extend (or delay) tasks within their floats to lower their demand for workers and increase the overall team availability to handle critical tasks during peak periods. In other words, you will be redistributing the tasks within your schedule and moving them from periods where there is too much work to periods where there is too little work.

3.4 What-if scenario analysis

The principle behind what-if scenario analysis is fairly simple: to compute the expected impact of uncertain (and likely) events on both the project schedule and costs. While the idea is simple, in reality, the process can become very complex due to several factors:

1. There might be multiple levels of impact depending on the event: As an example, think about a delay from your suppliers. If the delay is between 1 and 5 days, there is an increase of $500 in budgeted costs; if the delay is between 6 and 15 days, the increase is of $1200; if the delay is between 15 and 30 days, the costs increase by $3200. While this is a simplistic example, it shows the idea behind multiple possible outcomes and why they can become quite complex very quickly.
2. You also have to calculate the probability of each outcome: simply knowing the possible outcomes of event X is not enough to calculate its expected impact on the project. If you want to do some actual and meaningful calculations, you will have to know the probability of each outcome and use it to adjust the respective impacts.

To help us understand the steps involved in the process of implementing the what-if scenario analysis, let’s think about the possible impacts on task 3.1 (preparing the terrain for the construction) of a delay on getting the necessary approvals to start the construction of the house.

The most effective way of visualizing the information is to build a simple table (Table 05) with the information collected about the impact of the delay. Start by answering the question “What is the impact of event X on the project schedule and budget in case event X actually happens? How likely is each possible outcome to happen?”

Delay in days	Probability of delay of n days	Cost increase
2	0.4	100
4	0.3	250
6	0.12	370
8	0.08	500
10	0.05	750
12	0.03	1500
14	0.02	5000

Table 05: Probability and cost impact of different outcomes of facing a delay in getting the formal approval for the construction

There are a few elements to keep in mind:

• Probabilities are estimations: it’s not possible to know in advance the actual probability of each outcome. You’ll have to estimate them. There are, however, ways of improving the accuracy of the estimations: collect past data about similar events, use probability distributions, consult an expert on the field, etc. Most uncertain events will actually present some “logic” behind them: in our example, for instance, it wouldn’t make sense to have a higher probability for a delay of 8 days than for a delay of 2 days (except if there is some known, atypical circumstance).
• The set of outcomes should be as complete as possible: when considering the different outcomes that are likely to happen, include as many options as possible (i.e. try to forecast each and every possible outcome). Did you notice that the probability column adds to 1 in our example? This means that there is no space for any other outcome (yes, we are assuming that it’s not possible to delay the approval for more than 14 days). In real-life projects, however, forecasting each and every outcome is normally not possible; there is always some degree of uncertainty that needs to be handled. One way of handling it is to assign a small probability, as well as the cost and schedule impact, to “unforeseen outcomes”.

Now that the major aspects of estimating probabilities and outcomes are taken care of, on to actual calculation of their impact on our project.

The expected impact of an outcome is obtained by multiplying the actual impact by the probability of that outcome. Consider the case of a 2-day delay in obtaining the approval. The cost impact is 100, and the probability of this delay actually happening is 40% (or 0.4). Therefore, the expected impact of a 2-day delay on the costs of the project is 100 * 0.4 = 40.

Now that we understand how to calculate the expected impact of each outcome, we can calculate the expected impact of the entire event (which is represented by E(X)). This is obtained by simply adding together all the expected impacts of each outcome. In mathematical notation:

Where X represents the uncertain event under consideration, pi is the probability of outcome i and xi is the impact of that outcome. You’ll have to perform the calculations separately for the schedule and cost impacts. In our example, we will perform the following calculation for each of the lines (and Excel spreadsheet does the job in less than a second):

Schedule impact = (Delay in days) * (Probability of delay of n days)

Cost impact = (Cost increase) * (Probability of delay of n days)

With these numbers in hands, calculating the expected impact of the delay is simply a matter of adding the expected impact of each outcome. This is shown in the last row of Table 06.

Delay in days	Probability of delay of n days	Cost increase	Schedule impact	Cost impact
2	0.4	100	0.8	40
4	0.3	250	1.2	75
6	0.12	370	0.72	44.4
8	0.08	500	0.64	40
10	0.05	750	0.5	37.5
12	0.03	1500	0.36	45
14	0.02	5000	0.28	100
Expected Impact			4.5	381.9

Table 06: Expected impact of each outcome and of the entire event of facing a delay in obtaining the formal approval

As you can see, the expected impact of the delay in the approval is (1) 4.5 extra days in the project schedule, and (2) a cost increase of 381.9. Remember that these are expected outcomes: only when event X happens you will be able to know the actual impact on your project schedule and cost. Until then, working with the estimations is the best way of reliably updating the schedule and the budget for your project.

4. Revisiting the Work Breakdown Structure (WBS)

Before talking about the outputs of the schedule control and monitoring process, let’s return to an important point of effective schedule planning: a well-structured WBS.

When defining the tasks in your WBS, keep the following four criteria in mind:

1. Each task on the WBS must be discrete and atomic: put in other words, this means that you should avoid tasks such as “sketch the exterior design and create the house blueprint”. Instead, each lower task in the WBS should focus on one single activity.
2. The tasks must have defined start and end dates: our example provides well-defined start and end days for each task in the WBS. They are absolute numbers, but once we define the specific start date of the project, each deadline can be easily updated to reflect actual days in the calendar. If you don’t have clearly defined dates in your WBS, it’s simply not possible to distribute the required amount of work hours throughout the task execution time span. For example, task 1.2 requires 72 hours of work to be accomplished; if we don’t have clear deadlines, it’s not possible to calculate how many hours of work per day (and, consequently, how many team members) are required for the task.
3. The tasks must produce an outcome that can be objectively measured: earlier we discussed the importance of measuring performance in order to distribute the total Planned Value of a task over its planned execution days. Having an outcome that can be objectively measured is essential from the perspective of properly tracking the Earned Value progress of a task.
4. Each task should have costs assigned to it: each and every project activity will bring costs, even if just labor costs (hours paid, employee costs, etc.). As a project manager, assigning costs to each task is crucial to an effective project performance tracking (budgeted costs are linked to both cost and schedule performance indexes).

4.1 The two most common WBS mistakes

Now that we have briefly discussed the most important good practices when creating your WBS, let’s discuss some of the most common mistakes that should be avoided at all costs.

4.1.1 WBS tasks should not represent ongoing tasks

Ongoing tasks are those that need to be executed periodically throughout the execution of the project. They are also known as LOE (Level Of Effort) tasks. The very cost and schedule monitoring tasks, for example, are examples of tasks that need to be executed by the project manager on a regular basis but add very little value to the tangible outcome of the project. Actually, almost every project management task can be considered an LOE task.

LOE tasks last as long as the project and require a certain amount of work every week to be accomplished. In other words, the longer the project lasts, the higher the expected LOE costs.

As you might guess, simply including a “Project Management” task in your WBS is not a good idea. You can’t really assign start and end dates to it nor track its progress (thus violating best practices number 2 and 3 above). Another issue related to LOE tasks derives directly from the fact that it’s not possible to measure their progress objectively. LOE tasks are normally assumed to be on schedule and within budget until the day that they are not completed on time. If that happens, there is not much left to do to counteract the extra costs and delays that result from it.

There are a few different ways you can handle LOE tasks, and our suggestion is to create a separate cost and schedule estimation section dedicated solely to them. This way, you can relieve your WBS from LOE tasks and still integrate them into your final project cost and schedule estimations.

4.1.2 The lowest level tasks should be small and follow the 8/80 rule

The size of each work package has a big influence on how accurate your schedule and cost variance analyses are. If you have work packages that are considerably large (task 1.4 from our case is a good example of a work package with an inadequate time duration), it’s much harder to track its actual progress. When executing a task, the only objective measures you have are the start date and whether the task is completed at the end date. Anything in between is actually guesswork (the linear progress we assumed was nothing more than that: an assumption). Therefore, it’s recommendable to have small tasks at the lowest level of your WBS.

The 8/80 rule is considered the rule of thumb here: design the tasks such that they require at least 8 and a maximum of 80 hours to be completed. Less than 8 hours would become micromanaging (and we don’t want that), and more than 80 hours would make tracking the real progress too difficult.

Another rule you might want to use is to assign 50% of the PV to a task once you start to execute it, and 100% of the PV once it’s completed. This, however, works well only if your WBS is broken down into small enough tasks.

5. The outcomes of the schedule control and monitoring process

Schedule monitoring and controlling aim at providing relevant data to calculate work performance and adjust the schedule of your project when needed. There are several elements that result from the schedule controlling process, and below we detail the four most important ones.

5.1 Work Performance Measurements

Schedule variance, schedule variance percent, and schedule performance index are three crucial work performance metrics that comprise the outcome of controlling the project schedule. In addition to that, you can use performance metrics from the cost monitoring process to better understand the joint impact of each task on your project and to have better data to analyze the causes of any variations within your schedule.

5.2 Schedule Forecasts

Updated schedule forecasts are an important outcome of schedule monitoring. Using the tools mentioned above and calculating performance indicators will give you objective indexes that can be used to update the project schedule and provide more realistic deadlines. The new forecasts should then be communicated to the relevant stakeholders in order to correctly set expectations about the project execution.

5.3 Organizational Process Assets Updates

Once you know the causes behind the schedule variance, you can actively act on the relevant project processes to eliminate inefficiencies and optimize the productivity of your team members. This will lead to new or redesigned processes, and such changes should be correctly documented in your project management plan and other related documents.

5.4 Change Requests

Depending on the size of your project, changes might have to undergo a formal process of approval and implementation. The process redesign phase mentioned above should generate such change requests and submit them to the approval of the relevant stakeholders.

6. Final words

This and the previous article covered the most important areas of project monitoring and controlling. Cost and schedule are the two most fundamental dimensions of any project, and having detailed tools to correctly manage both of them is essential for any good project manager. We have extensively covered several different techniques, diving deep into their implementation mechanics and into how to use the outcomes produced by each one.

Integrating such monitoring processes into your work routine might sound daunting at first, but within a few days or weeks, you will notice that the new processes for both collecting data and conduction calculations will be an important part of your daily tasks. Naturally, you don’t need to implement each and every technique discussed in these two articles: choose among the most adequate tools for your type of project and focus on executing them well. You will notice that measuring performance will become more straightforward and that the number of insights you will collect from your data will considerably increase.