Project Management

Quick Tip: The top five things to know before using Microsoft Project

Get the most out of Project with these tips.


Microsoft Project is very likely the only project management software you will ever support. Because Project looks and feels so much like the other Office products, new users think that they should just be able to open it up and poof—they are managing projects. The reality is that Project is not like other Office applications. Below is a short list of things that new users should know before they start managing plans with Project 98 or 2000.

Tip #1: Project users should have some background in Project Management theory
Supporting Project 98 or Project 2000 will be much easier if your users have some understanding of the basics of Project Management (PM). More than any other Microsoft Office family product, Project assumes a level of understanding in a subject area. Word, Excel, and PowerPoint are all very generalized in their scope and targets. Nearly anyone can open up Word and understand the basics of how to start typing. The majority of users out there understand words, sentences, and paragraphs. Word makes sense to these users because of this understanding.

Project exists in a much more narrow world. For Project to “make sense,” a user should understand at least the basic elements of Project Management. A foundation in PM will enable you to much more easily grasp what Project is doing than if you had no background at all. If you are supporting Project users, often the solution to the problem is recommending a training course. There is some initial cost associated, but in the long run it will prevent future calls and will save the company time and money.

Tip #2: Know the difference between work and duration
I cannot stress this point enough. Work and duration are related and, in Project, even tied together in a hard-and-fast equation (to be covered below), but they are not interchangeable. It is common for newcomers to Project to make this assumption when building their first plan.
  • Work is the number of person-hours required to complete a task. For example, if you have a task that will require 40 hours of work to complete, you might have one person working five eight-hour days, or 10 four-hour days, or you could have two people working five four-hour days each. In each of these three cases, the total work for the task is still 40 hours.
  • Duration (if expressed in days) is the number of working days that fall between the start date and the finish date. You can also think of the duration as the number of working days required to complete the work.

In the examples above, we had a task that required 40 hours of work. The first example suggested that one person working five eight-hour days could complete our task. Assuming these days fell in a row, the duration of this task would be five days—given the defaults in Project of eight hours of working time per working day. If a resource works eight hours a day for five days, then the work is 40 hours. The same task would have a duration of two-and-a-half days, if we had two resources working at the rate of eight hours per day each. It would take two-and-a-half days for two resources working eight hours a day to complete 40 hours of work.

Do not make the mistake of assuming work and duration are the same.

Tip #3: Create an outline using summary tasks
Try to organize your plan into stages or phases. This rule of thumb is especially helpful if your project contains large numbers of tasks. In such projects, it can be difficult to find the task or data you are looking for in a sea of tasks. You can use summary tasks to break your project into more manageable "chunks." These chunks can then be used to monitor how individual portions of your project are performing.

Though your plan might have several hundred tasks, you typically discover that these tasks can be placed into logical groups. A software project might have its tasks grouped into Design, Code, Test, Recode, and Release, while a construction project might be broken down by the type of work, such as electrical, plumbing, and so on. There is no right or wrong way to group your tasks, so use the method that makes the most sense to you.

One of the other benefits of using summary tasks to categorize your plan is that task information is "rolled up” to these summary tasks. The sample outline in Figure A shows how a development project might be broken down.

Figure A
Notice how the data in the columns is rolled up.


Notice how the fields at the summary levels (Design, Code, Code Server Module, Code Client Module, and Test) are the rollup of the values for the tasks below them. Using these summary values, it is now easy to see what part of the process is using the most hours.

Making use of summary tasks will make your plan more readable and more manageable. By rolling up task data, summary tasks allow for better reporting. A report showing just summary tasks can be an effective way to give status of your project to management. Such a report, because it uses summary tasks to rollup the data, shields management from all the detail and provides them with just the high-level information.

Tip #4: Use links instead of manually setting start and finish dates
Often newcomers to Project Management are tempted to manually enter start and finish dates for all their tasks.

The user thinks to himself, “I know Task One will start on 5/15 and finish on 5/20, and Task Two can’t start until One is done, so that means that Task Two will start on 5/21.”

Users mean well here, but they are limiting themselves in two ways. First, if a task should not start until another finishes, the user should not try to manage this manually. They need to let the software help determine when Task Two should start by using links. Links provide users with a way to define relationships between tasks. In the above example, the user should have created a link between Task One and Task Two. A link would enforce the relationship that Two cannot start until One is completed. Links automate the thought process the user was attempting above. Think of how hard it would be if the start date for Task One changed. In the first scenario above, the user would have to manually change the start of Task Two to adjust for the change in Task One.

Secondly, manually entering dates in Project will place constraints on the task. A constraint is a rule that limits how Project can move tasks to adjust for changes in the planned values of the tasks in your project. For example, if a user manually enters a finish date for a task, Project will automatically place a “Finish no earlier than” constraint on the task. Such a constraint will make Project hold that finish date even if the logic of the links says that the task could finish earlier. If a project manager was not paying close attention, such a thing could actually make the project longer than necessary!

Define the logic of your plan and let that logic control the dates of your tasks. Do not enter task dates directly or set constraints on tasks unless the task should be tied to that date for some specific reason. The fewer constraints in your plan, the easier it is for Project to schedule your project.

Tip #5: Keep your plan realistic
In the planning stages of a project, new users of Project should constantly ask themselves this question: “Is my plan realistic?” While this notion might sound obvious, it is a common problem for new project users who build great-looking plans that are literally unreal. One of the most common ways that plans break with reality is in the misuse of predecessor-successor links, which are the logical links between tasks. Those links are really rules that govern project flow, such as the common-sense rule that one task cannot start until another task has finished. These "finish-to-start" links are the most commonly used tools in Project, but those links can be misused.

The problem is that many people often use those links unnecessarily. Let me explain. Most people try to enter their tasks into Project in chronological order. The inclination is then to use finish-to-start links to enforce this order. Sometimes this approach works, but all too often it backfires.

As the project manager, you should constantly check the logic in the plan to verify that it models reality. You should look at every link and ask yourself if the link is valid. Does that task really have to finish before this task can start? Can those two tasks be worked at the same time? Does one task deliver a product that another task requires? Can the test phase be started before the code is complete?

Common sense is the best guide when building your plan. Think about the relationships between your tasks in the real world. Then make sure that you build your plan to look like the real world. The tools are there in Project to help you build a great plan but they must be used with good old common sense.

Brian Kennemer is a Microsoft Project MVP and Program Manager for Pacific Edge Software. Brian has been using and supporting Project for five years. He writes and speaks for a number of organizations on Project and its use. He has dedicated himself to making sure that users understand the power of MS Project and Project Management in general to change their businesses for the better. Brian lives near Seattle with his wife, Alicia, and his kids, Riley, Jesse, and Alivia.

To comment on this tip, please post a comment below or follow this link to write to Brian.

Editor's Picks

Free Newsletters, In your Inbox