Chapter 4: Underlying Concepts of Microsoft Project

In the vast and complex world of science, a lot of value is placed on the elegant simplicity of scientific equations. Everybody has heard of Einstein's simple but profound equation. In the world of Microsoft Project, there exists a similar, simple formula. This simple formula is the bedrock upon which Project performs a multitude of calculations involving tasks, resources, assignments, calendars, tracking, and so on. But Microsoft did not invent this formula; it has been known to Project Managers from a very long time. You will recognize this formula, and begin to understand how Project really works, in this chapter.

Then, we will explore calendars in Project. If you can compare "managing a project" to "conducting an orchestra", you will find a great deal of similarities. It is the role of the conductor (project manager) to synchronize skilled musicians (team members) to create beautiful music (achieve project objectives). You can take this analogy a long way further. In this context, the calendar is like the metronome of your project. The Project Calendar keeps track of time ticking constantly, and every single aspect of your complex schedule should comply and synchronize with this constant ticking. Every component of Project is connected directly or indirectly to the calendar. Successful project execution requires an understanding of the Project Calendar to build effective and realistic schedules.

In this chapter, we're going to cover the following main topics:

All along the way, you are invited to practice what you learn, right at the place where you're learning it, hands-on. There are also some additional practice assignments at the end of this chapter that will help you understand everything better.

Demystifying the Basic Work Formula

Most Project users expect it to act like a spreadsheet and are often surprised to find that Project appears to have a mind of its own. This is because Project operates within an elegant framework of rules, algorithms, and solid project management techniques. The key to understanding this framework is a simple formula, which we will call the Basic Work Formula. Starting from complete basics, let's now proceed to understand this formula and see how it drives complex scheduling behavior.

There are three key parameters associated with every task to be executed in a schedule:

These three parameters are related by the Basic Work Formula of Microsoft Project:

Using simple algebra, it can also be written as follows:

Alternatively, it can be written as follows:

All three forms are equivalent, mathematically. If you know the total effort (work) required to execute a task, and the units of resources that will be assigned to the task, then you can compute the duration of work time consumed by that task. Furthermore, using simple algebra, you will be able to deduce any unknown parameter if the other two parameters are known.

Let's now break down the meaning of this formula through a few simple examples. Please observe the following screenshot:

Figure 4.1 – Microsoft Project – Basic work Formula illustration

As highlighted in box 3, we have a task that is 7 days in duration. This is shown on the corresponding taskbar in the Gantt chart. I have also opened the Task Information dialog box to show you the Resources tab (which houses the Units field).

There are some important observations to be made:

Table 4.1 – Project's duration shortcuts

Practice mental math and calculating multiples of basic work hours at different magnitudes. Understand the project metrics of your business domain. What is considered a small/medium/large project in your expertise area? Also, there are some basic numbers you can use to make quick approximations. These are invaluable in quick calculations and verbal negotiations, and help you easily size up tasks and projects:

Table 4.2 – Quick approximations for calculations

Now, let's really cement our understanding of the Basic work Formula by considering some simple examples. Let's say our testing team must execute 80 automated test cases for the company's software. One engineer can execute one test case in 1 hour. How long does the whole task take?

From the preceding problem statement, we know the following:

work = 80 person-hours (because one test case can be executed in 1 hour)

Units = 1 (because we have one test engineer working 100% on this project)

We can now compute this by applying the Basic work Formula:

duration = 80 person-hours / 1 Unit (this is the Basic Work Formula)

duration = 2 work weeks (which is 80 person-hours).

Now, just to make this more interesting, let's say a duration of 2 work weeks is not acceptable to you, and you want to reduce this time further. You decide to speed things up by adding one more test engineer to the task.

Now, we have the following:

work = 80 person-hours (this has not changed)

Units = 2 (because we now have two test engineers working 100% on this project)

We can now compute this again:

duration = 80 person-hours / 2 Units (this is the Basic Work Formula)

Therefore, duration = 1 work week (which is 40 person-hours).

By doubling the number of resources, we have halved the duration.

This isn't exactly rocket science but let's continue with yet another example.

A third test engineer has become available to work on your project. But they can only work 50% of their time on your project. Now, your Units is 2.5 (which is the same as 250% within Project) and, of course, work is the same at 80 person-hours. What will the new duration of your task be? Take a moment to compute the answer by applying the Basic Work Formula. You should get an answer of 4 workdays (or 32 hours).

An example Project for this chapter – creating online departmental manuals

Now that you have gotten a handle on the Basic work Formula, you are ready to see it in action within Project. Let's start with our next hands-on project, so fire up your Project instance and let's go!

Let's begin with a case study. You are the CEO of a small greenspace management company. You are required to create two online operating manuals, which consist of 100 web pages each. One is a Quality Manual, while the other is a Technical Manual. Remember that the objective of this exercise is for you to observe how Project uses the Basic work Formula to manipulate duration and work automatically, based upon your inputs. So, we will keep this project super simple with only two tasks.

The following are the constraints for these tasks:

With this much information, we are now ready to start our project. The kinds of simple manipulation we will perform now are very common in real-life scenarios, so this is exactly how you will experience Project's algorithms.

Case 1 – Change of duration

Assign two different engineers to both tasks. Since 10 pages can be created in a single day, by each resource, the duration is 10 days to begin with. You already know that when you create a task, the default duration of 1 day? is auto populated. The question mark appears because Project has assumed this default value for us. As soon as you change the duration, Project's algorithms kick in. A small green informational symbol appears in the duration field of the specific task:

Figure 4.2 – Microsoft Project – Change duration informational message

When you click on the symbol, Project wants to know the reason you increased the duration. There are two reasons you can choose from:

In both cases, the duration of a task can potentially increase, and Project is not sure what option best reflects your reality. Project is asking you to clarify this in the dialog box. In our case, we modified duration because our task's work requires more time than the defaulted 1 day. Even if you just ignore this query from Project, the defaulted option (increased duration) has already been applied. If you adopt this mode of creating schedules, then it is perfectly fine to ignore this warning when you change the duration of many tasks at once, at the beginning stages of your project.

Note that, if you choose the second option, then duration will increase and work will remain the same, but Unit percentage will decrease. This means that the assigned resource will do less work on the task every day. If this gets confusing, refer to the Basic work Formula from earlier.

Case 2 – Adding additional resources

Now, we will assign an additional resource to the first task. Once again, the first option is the default and it complies with the Basic work Formula. Because we have doubled the number of resources (from one to two), our duration is halved, as shown in the following screenshot:

Figure 4.3 – Microsoft Project – work formula, additional resource

This is the expected behavior and it is defaulted by Microsoft. Observe the other two options carefully. They both allow you to retain the same duration without changes, even with an additional resource, but at the cost of either reducing the Units or increasing the work— all under the precepts of the same Basic work Formula. These other options are rarely used, typically in special situations in your real-life projects, but this task customization is available, should you choose to use it.

Case 3 – Increasing Units

There is another technique we can use to increase Units, without adding a new additional resource. We will look at this now. Double-click on Task 2 and bring up the Task Information dialog box. Select the Resources tab and increase Units to 200%. Refer to the following screenshot:

Figure 4.4 – Microsoft Project – Resource Units set to 200%

The effect of performing this change is to halve the duration, similar to what you saw in Case 2. You can observe the decreased duration in the following screenshot:

Figure 4.5 – Microsoft Project – Increased Units results in decreased duration

However, be careful here: this is an interesting and dangerous situation, as I'll explain soon.

What exactly is the meaning of increasing the resource's units to 200%? Can we use this technique everywhere to perform miraculous reductions in duration, without adding extra resources? When you increase the Units of a resource, this means that the resource is working proportionately longer work hours. In our case, we just set the resource's working hours to 200% – and no wonder the duration was halved! And no, we should not use this technique of increasing Units as a standardized practice, even by a fraction, because systemic overallocation causes burnout in people, destroys motivation, eliminates all buffers, and also causes hard-to-debug scheduling issues.

This potentially dangerous situation is highlighted to you by Project in the Indicators column for the specific task, as shown in the following screenshot:

Figure 4.6– Microsoft Project – Overallocation indicator

It is perfectly normal to expect short periods of crunch time in everyday commercial projects. We are all aware of pulling long hours before a demo, or a weekend in the office during a big launch. During the execution of a project, you might have short periods of increased Units for your team. But it is not a good practice to hardcode overwork (or underwork) into the planning phases of a project. Project buffers are to be added later if required, in the Planning phase of your project.

This is the first instance where we have encountered significant overallocation, though there are other ways overallocations can occur. It is the single biggest bane of project managers while using Project. In this book, first, we will learn to identify and avoid them. Then, we will also examine many techniques and tools we can use to combat overallocations.

working smart with Project

There are many methods of working successfully with Project. Every practitioner will eventually evolve their own ways, and so will you. It is my humble attempt in this book to teach you how to flow with and around Project's default values, assumptions, and algorithms with the least possible friction. This method happens to require your hands-on participation.

If needed, adjust your estimation techniques, Units, and standards so that they closely match the defaulted expectations of Microsoft Project. This will save you a lot of conversion and translation efforts. If, for some reason, you can't alter your own techniques, then customize Project to your expectations. This is why it is important to learn how to customize features.

If you choose to pursue neither of these options, then a lot of time will be wasted converting estimations, Units, and so on at runtime. At the same time, you will have a ton of feature customizations available for your tasks. All this increases management complexity.

Deeper scheduling

Now, we will briefly jump into a few more complex topics. You will exercise these task type features and algorithms very rarely in normal projects, but it will be good for your confidence to handle such requirements.

Exploring task types

When you observe your project's real-life tasks in closer detail, you will find that they often have either implicit or explicit restrictions placed upon them. Let's say that you're managing a team of 20 software engineers. Here, you will want maximum utilization for your complete team, which you can do by keeping all of them productively engaged with your project. This is often called Resource Balancing or Resource Leveling. On the other hand, you cannot sporadically increase your team head count either (for example, to reduce duration). You will want to fix the number of engineers who are working on a specific task. Likewise, you may also have senior experts in your team whose skills might get shared across multiple projects. So, they will be available in fractional resource units to any project. Moreover, you must carefully manage their entry and exit into your different projects. These are only some of the implicit and explicit restrictions you will face, and we haven't even started talking about budget management.

How closely you reflect these team realities/restrictions into your schedule, with the least complexity, will largely determine your efficiency with Project. The Task Information dialog box that we have been using so far allows you to finely tweak the behavior of your tasks so that they closely reflect your realities. You can open it by double-clicking on any task in the Entry table. Refer to the following screenshot:

Figure 4.7 – Microsoft Project task types

You can instruct Project to keep one of the three parameters from the Basic Work Formula, as a constant – either duration, Units, or work. Project will comply with your guidelines for that specific task unless you want to overrule it by yourself. But what does this mean? In the following sections, we'll look at when and how you will need to apply this feature to your schedules.

Understanding the concept of Fixed Units

The meaning of making Resource Units Fixed is that you have a pre-decided number of people (or machinery) working on a specific task. This is a common situation in real life and, in fact, is the default setting of Project.

You will be familiar with this situation from your working life, where you, as the manager, have been assigned a fixed number of resources, with specific skillsets, whom you can draw upon to execute a project. This is true even in the case of organizations with a Resource Pool concept.

Fixed duration

On rarer occasions, you will come across tasks that will take a fixed number of days to complete. The most common example for this condition is the Curing of Concrete task, from the world of civil construction. For example, once the roof is laid, a curing period of, say, 7-20 days is often required for the concrete to properly harden as per the requirements. Now, you might assign n resources to this task to make sure the concrete is properly maintained during this time, but adding another resource will not reduce the duration beyond the curing period.

You will also come across tasks like this in the world of Information Technology. For example, Automated Backup and Restore is a task that will take a fixed amount of time. In your own business domains, you will be sure to find tasks like these, which have an irreducible duration.

When you encounter tasks like these, make sure that they are properly configured so that they're of the Fixed duration task type.

Fixed work

The Fixed work task type is when the total amount of effort of the task is known and fixed upfront. This is, once again, very common in actual practice and often forms the bulk of your tasks in a project. Once the task's effort is known and your Resource Units are known, you will be able to compute the duration in Project.

If this type of task is very common, then why is Fixed Units the default type used by Project? One plausible reason for this is that during the estimation process, using a Fixed Units-based calculation enables you to directly proceed to duration computation next – the field that Project expects by default.

Are your tasks effort-driven or not?

At this point, in the Task Information dialog box, you might have noticed the Effort driven checkbox. An effort-driven task means that if you increase the resources for a task, you can expect a proportional decrease in the duration. Most tasks that you will encounter will be effort-driven in nature and that is the reason, by default, this option will be selected to begin with. Every task that we've discussed so far are all effort-driven tasks. An example of an effort-driven task is as follows: if it takes 10 days to build a wall with one person, then the same task will take 5 days with one resources. That is, if we add more effort, we drive the duration of the task. In short, this is what we call effort-driven.

Now, let's look at a non-effort driven task. Consider a 1-day training session, as a task, that you must conduct. Whether two people attend your training or 20 people do, you can expect it will remain a 1-day training session (of course, you might need a bigger venue). Such tasks are not impacted by the number of resources and are statistically rare occurrences in projects. These tasks are non-effort driven.

Later in this book, we will look at a more detailed example of a recurring and non-effort driven task.

The impact of using task types

At this point, you might be wondering if you must inspect and modify the task types for every task in your schedule. The answer is no. Instead, you must only identify and modify the exceptions. Even if the size of your project is very large, you will typically set exceptional tasks only once during the initial stages of your project. The reason for this ease is that Microsoft Project has carefully curated, as far as possible, real-life usage into its default values and default behavior. You will understand the significance of this fact in the next section.

Underlying algorithms – How project scheduling works

The big question now is, how do the three task types affect the Basic work Formula? We will examine this aspect now. This algorithmic behavior is captured concisely in the following table, for your reference. Note that this table is specifically for making modifications to existing assignments:

Table 4.3 – Project's scheduling behavior

Is it necessary to memorize this table for everyday usage of Project? The answer is no. If you stick with the defaulted Fixed Units and the common form of Basic work Formula, you will be completely conversant with Project scheduling behavior. However, you might occasionally need to cross-check this table when you are modifying assignments for an exceptional task. With that, we have finished our discussion of advanced scheduling features. Now, we will take a look at Project Calendars.

Understanding Project Calendars

By now, you have comprehensively examined the three dimensions of scheduling – work, duration, and Units. But which is the implicit fourth dimension that is hidden within all of these? This fourth dimension is Time. In this section, we will learn how to handle time through the Calendar feature of Project.

For the sake of simplicity, so far, we have started all our practice projects by directly entering the tasks into the Entry table. This is fine for practice projects, but not for your real-life commercial projects. In the latter case, you should always start by setting a start date for your project.

The proper usage of Project requires that you configure your Calendar. In the sections to follow, we will learn how easy it is to match the calendar to the working time conditions of your organization. Although this will be simple for you, Project, in turn, translates your configurations into internal rules for its algorithms.

When using the calendar that you configure, Project will determine whether work can be scheduled or not for a day, resource, or task. Calendar affects literally every aspect of your schedule. We'll see how this happens and works in the following sections.

Setting the Project Start Date

You can set the start date for your project from the Project Information dialog box. The button is aptly located on the Project tab. Refer to the following screenshot:

Figure 4.8 – Project Information

The Project Information dialog box is chockful of date-related UI controls, as shown in the following screenshot:

Figure 4.9 – Microsoft Project – setting Project Start Date

It is not very easy to use until you understand the following simple sequence:

Figure 4.10 – The Calendar option in the Project Information dialog box

We will do a deep dive into calendars in the sections that follow, where we will revisit this option.

However, there is a pitfall to setting this date.

Don't use Project Finish Date scheduling in a casual manner if you don't have a grasp of all its implications. This reverse direction of scheduling is useful only on rare occasions, typically when you want to calculate the span of a project. This technique is used only during the initiation and planning stages of the project (just for design and calculation) and never in actual project execution. There are two reasons why it is not used. First, it greatly hampers your ability to interpret the schedule on a day-to-day basis. Second, it affects Project's scheduling and resource algorithms, and you will often be hard pressed to interpret the automatic changes on your schedule. Specifically, it affects the algorithmic constraints designed within Project's scheduling algorithms. For example, when you use normal scheduling from a start date, Project uses a default constraint called As Soon As Possible (ASAP). But when you reverse this scheduling, the default constraint type changes to As Late As Possible (ALAP). We will learn more about date constraints in Chapter 8, Mastering Link Dependency and Constraints.

Pro Tip

You can also set the project start to a back date. It is quite common for project managers to take charge of a project that has already started, and that's when you set a back date to the start date. No matter when you start the project, always ensure that an accurate start date is configured for your schedule.

Creating your new calendar

When you create a new blank project, it will already have made several assumptions about your standard default working times and days. This will be the universal 8 A.M. to 5 P.M., Monday through Friday, with an hour for lunch in-between. Saturday and Sunday are non-working weekends.

These default settings will not include national holidays, company holidays, resource holidays, or any other customized date and time information that might be vital for your project. So, one of the very first activities for you to complete, as a prudent user of Project, will be to configure your calendar customizations, very early in the schedule creation process.

If your organization already provides you with a Project calendar, then use it. Otherwise, you can create a new calendar, as described here:

Figure 4.15 – New calendar has been created

Now that you have created a new experimental calendar, you can modify it. We'll create new working timings on this calendar in the next section.

Customizing your new calendar

There are two main types of customizations that you can perform on a new calendar – changing the daily working time and adding holidays. In Project-speak, these holidays are exceptions to a normal working week. In the following steps, you will learn how to perform both customizations:

Now, you are all set to use this calendar for its basic settings. In the next section, we will learn how to use it for the current project.

Setting the Project Calendar

Even though you have created a new calendar, it is not linked to your current running project. Linking a calendar to the open project can be done in the Project Information dialog box, which we looked at earlier when we learned how to set the project's start date. Open it once again from the ribbon's Project tab, as shown in the following screenshot:

Figure 4.19 – Setting the project calendar

When you open the Calendar dropdown, your newly created calendar will show up. Select it and click the OK button to set the project calendar. You can now doubly-check that your calendar has been set correctly by once again opening the Change working Time dialog box. Refer to the following screenshot:

Figure 4.20 – Verifying that the project calendar has been set correctly

Your calendar name should have the designation label Project Calendar appended to the end of it. This verifies that you have set up the project calendar correctly.

With that, you have learned enough about Project calendars to cover most of the situations you will encounter in real-life projects. In the next section, we will delve even deeper into the inner workings of calendars.

How calendars really work in Project

Calendars are a major cause of discontent and issues with users of Project. This is because it is a complex feature and users do not take the time to understand it thoroughly.

Calendars are categorized into four essential types:

By default, task-level calendars are not set, and tasks follow the project calendar otherwise. This is shown in the following screenshot:

Figure 4.22 – Task-level calendar

These four calendar types are applied in the same order as we introduced them. First, the base calendar is applied, then the project calendar, followed by the resource and task calendars. Ultimately, on any given day, what, who, and when is decided by Project as it overrides all these calendar settings in the hierarchy.

As a new learner, you must restrict your usage to only the project calendar (which is mandatory for you to configure). As you progress to becoming an intermediate Project practitioner who's handling larger projects, you might also include resource calendars, but only if required. Task-level calendars are rarely used.

Tip

Calendars are a quick way to debug or triage issues with task behavior. Calendar changes not showing up in the Gantt chart.

Sometimes, when you make changes to the calendar framework, such as applying a new project calendar, your exception dates (holidays) might not be reflected on the Gantt chart. This is because the Gantt chart, by default, applies only the default Standard calendar. You can just right-click on the Gantt area and configure the Gantt chart in order to apply the calendar that you wish to be visible there.

Summary

The motive of this chapter was to dig deeper into the inner workings of Project's primary pillars – tasks, scheduling algorithms, and calendars. Throughout this chapter, we saw that it is possible to tweak and fine-tune these aspects of Project through the use of methods, interfaces, and techniques. It is important for you to understand the default values and default behavior of Project first, as they have been carefully designed to cater to the vast majority of the use cases that you will encounter.

In the next chapter, we will look at resource assignments in greater detail. First, we will cover all the basic functionalities before opening up the hood and looking closely at the machinations of the scheduling engine.

Assignment