Related Entries

Labelling in Outlook 2003 ala Gmail
Time tracking tools
Outlook 2003 + Flags = todo list
Scrum for Self : V2
ADD and antipatterns

« Corn on unix
» MSP2000 - User Interface

Essential theory

Some terms and definitions to consider before using Microsoft Project.

We need to understand few terms and definitions before we start using MSP. Instead of detailing these terms from a purely theoretic point of view, I have kept in mind how it affects your use of MSP.

Most of the definitions are based on how I understand it, while I use MSP. Again, if you are trying to get PMP certification or needs to gain solid theoretical knowledge of Project Management terms, this is not the place to get that information.


A set of possibly dependent tasks using finite resources that produce results within a defined timeframe.

Let us not worry too much about this definition. To make things simpler, I consider anything that can be planned to produce a defined outcome as a project. Anyway, the key factors are below.

Using this definition, we can’t qualify on-going maintenance as a project; unless it has a definite end-date. One way to get around this is by assuming that a definite team is going to be working on maintenance tasks till a particular date. After that date, start a new project.


Division of the work that needs to be completed to accomplish project goals. There are different kinds of tasks, like below.

Critical Task

A task that falls in the critical path. Meaning, the project duration will get affected if a critical task’s duration is changed.

Milestone Task

Tasks you use to track or report progress. In MSP, all tasks with zero duration are considered milestone tasks. Think of milestones as interim goals.

Summary Task

Tasks that contain subtasks.


Children tasks that are contained under Summary tasks.

Recurring Task

Tasks that occur periodically.

Task Types

MSP allows you to define three types of tasks.

  1. Fixed Units
  2. Fixed Work
  3. Fixed Duration

Using the equation 'Work = Duration * Units' (see below), MSP calculates the variable parameters appropriately.

From the programming example above where adding more coders won’t make it go any faster, it follows that such tasks ought to be really Fixed Work tasks.


People, equipment, materials or services that incur cost and/or usage and are needed to complete the tasks.

If you manage people in projects, I believe you should manage their schedules too. Please note that I am not advocating micro-management. Rather, defining the expectations and boundaries so that your resources don't need to constantly worry about when are they supposed to work on different things.

Scheduling work for people is difficult. Though MSP takes care of the calculations for you, there are many parameters like resource calendar, task priority, links between tasks etc. that affects scheduling.

One way to look at not scheduling work for people is by claiming you are benevolent enough to give people flexibility to do their job. Another way to look at is that people are being benevolent enough by absorbing scheduling responsibility from you. Which way you want to look at it is upto you. Just keep in mind that people are a bit more sensitive than other resources like equipment or materials.


There are different types of calendars. You can have a calendar for a project. Resources will most certainly have their own calendars. In MSP, tasks also can have their own calendars.

To simplify, a calendar is a collection of days and hours on which the project needs to be carried out; or resources are available; or tasks needs to be done.

For our purpose, we will be concentrating mostly on resource calendars.

Project Triangle


Combination of time, money and scope that influence the outcome of the project.

These are usually depicted as three sides of a triangle, as shown above. If you don’t have enough time, you will need to pump more money to attain the same scope. Well, that is the theory!

Quality is usually considered as the area of this triangle.


A project manager I really respect once said "Next to Power Point, printed copies of different charts are probably the most ego-boosting artifacts for project managers; yet horribly boring for developers." Charts are useful, but most programmers I know favour the outlined list of tasks instead.

Gantt Chart

Tasks are shown as bars across a time scale. Relationships are shown using arrows.

Network Diagram

Shows the flow of charts. It is useful to find the critical path. However, MSP automatically finds the critical path for you, so I don’t find this very useful.

Duration & Work

This is perhaps the most confusing aspect for new project planners. Duration is the elapsed clock time in the calendar between the start time and the finish time of a task (or project). Work is the actual hours you worked on the task/project. If you don’t work on weekends, the duration for a task might be 8 days, though the work is only 35 hours.

Work = Duration * Units

Remember this equation. If it takes one person (Unit) one day (Duration) to dig a well, the actual work performed is for one day. If you have two people (two Units), and you keep the dimensions of the well same, by this equation, you should be able to cut the Duration by half.

Given the choice between Duration, Work and Units, MSP will choose to change Duration. If the Duration is fixed --eg: meetings--, it will change Work, before it changes Units.

W = D * U


Let us assume that it takes ProgrammerA four hours to code S/he comes in at 10:00 am every day and takes a lunch break from 12:00 noon to 1:00pm. While programming, s/he is 100% committed to the task at hand.

Q: Assuming s/he is asked to start this task right in the morning, what is the work, duration and units here?

Work is four hours. Unit is one (one programmer, committing 100% of the time). Duration is from 10:00 am plus four hours of work, with one hour break in between. So, s/he should finish this by 3pm, thereby making the duration, five hours.

Q: If the manager asks ProgrammerB, who is equally skilled and has same schedule to work on this task, will it be done faster?

According to theory, it will get done in half the time, because, now there are two units. So, the duration becomes two 4(work)/2(units). Which means, they should get the program coded by 12:00 noon.

Q: But programming is not like digging a well! Isn’t something wrong here?

Absolutely! Usually, for a programming task like writing one program, if you put more people into one task, it will not get done any faster. However, MSP follows this equation and will decide --if you don't change the defaults-- that the task is going to get done faster.

Q: So, what is the solution?

The easy solution to this is to make sure you assign less than 100% for each of the multiple programmers. In this example, you assign ProgrammerA and ProgrammerB to work on this task only for 50%.

Q: But, if this is an eXtreme Programming session, I don’t want programmers to be half indulged in the task. This solution does not look like a proper one.

From the programming example above, where adding more coders won’t make it go any faster, it follows that such tasks should rather be Fixed Work tasks. By default MSP sets tasks as Fixed Unit tasks. We will come to these details later.

Personally, I find the easy solution to be easier to manage.

This series

  1. Notes on Microsoft Project 2000
  2. Essential theory
  3. MSP2000 - User Interface