3 Oct 2009

Taming MS Project

~ By Dave Nielsen

I want to get to the specifics about using this tool, but first let me explain why I'm referring to a specific brand of project management tool. Most of us in the project management profession use Microsoft's MS Project to help us plan, organise, and track our projects. This is not to say that there aren't other, equally valuable, tools in use; there are, but MS Project has the largest user base and it's the one I'm familiar with, so it's the one I'm basing this article on. The tips in this article may, or may not apply to other scheduling tools.

By the way, this is not a training course, or tutorial on how to use MS Project. I'm assuming that you have attained some degree of proficiency with the tool, enough to at least have a few bad experiences with it. There are many courses available from Microsoft and others, which will teach you the fundamentals of using the tool. Try one of those if you lack fundamental skills in its use.

MS Project is intended to be a labour saving device. It is a feature rich tool which supports a great many simple and not so simple functions that all come in handy during the course of managing a project. The problem with the tool is that, like most feature rich software tools, it gives us enough rope to hang ourselves and I have. Getting the tool to work for you requires you to use its feature set judiciously. Just because the tool allows you to define a predecessor/successor relationship between two tasks doesn't necessarily mean you should. An over indulgence in using the features MS Project has to offer can make managing the tool into a very time consuming job, taking time away from more important project management work. Some organisations have suffered through this to such a degree that they have given up trying to manage the project and the tool and have hired a project "administrator" just to manage MS Project! The simple rules that follow this are intended to help you avoid this waste, and actually make the tool work for you!

Don't try to cram too many tasks into the tool. The more tasks you track the more effort it is to make changes, and you will have to make changes. I've found that the optimal number of tasks is several hundred. My cutoff point is 600 but you may find that more or fewer tasks work better for you. Where you are managing a large and complex project it may be better to divide the work up into sub-projects. This is easier to do if you have different teams in your project with leaders or managers for each team. Divide the project into sub-projects and make each team lead or project manager responsible for their own MS Project. Roll the key deliverables and milestones up into your overall plan and update your plan only when one of these deliverables or milestones changes. Even if you don't have team leads or managers reporting to you it will actually make your job easier if you divide the work into several MS Project files and manage them individually.
Don't get carried away with your work breakdown. Break the work down until you have a set of work packages that you can use to manage the work, and then stop. Breaking the work down further, just because the package is made up of components adds no value and creates extra work. For example, let's say your project will deliver a software system. Part of the work you have to track is the creation of various software components. Each module, function, or sub-routine must be unit tested, but does tracking that unit testing help you track the work? Of course not. The module, function, or sub-routine isn't finished until it has been unit tested and de-bugged so don't attempt to track the unit testing. Once the software has been produced, unit tested, and checked into the library, you can mark the work as completed. Changes that require the software to be changed or eliminated will also change the unit testing required. When the work has been broken down into packages that have an owner and which you will require that owner to report on, stop, you've gone as far as you should go.
Use the relationship feature judiciously. This feature is most helpful when managing work on the critical path. Its key function is to propagate a change in the delivery date of a work package on the packages that succeed it. It supports the definition of one-to-one, one-to-many, many-to-one, and many-to-many relationships. You will find however that unless you're scrupulously careful in defining these relationships a change in the delivery date of a work package can have an unexpected affect on the final delivery date and you will spend hours trying to identify the relationship that led to the unexpected result. Use this feature to track "hard" dependencies only. Before defining the dependency ask yourself this question: "Will the owner of the successor work need to be notified that the predecessor work has been completed?" Think hard about using the tool to define a relationship if the answer is no. Let's take the example of a building. You define the pouring of the foundation as one work package. The concrete must cure before you can begin framing and the framers should be notified when the concrete has cured sufficiently for them to start work. You should define the concrete curing (or the pouring of the foundation with a lag for curing the concrete) as a predecessor and the start of framing as a successor. You don't need to wait until all the framing is complete to start wiring the building though. Defining the point at which electricians can start wiring may or may not be a worthwhile exercise, but using MS Project to define the relationship won't help you.
Use MS Project to assess a requested change on schedule. One of the features that make MS Project so attractive is its ability to predict the affects of a requested change on the project schedule. Don't let the file you use to produce these "what if" scenarios contaminate the actual schedule. Give your scenario file a different name and location to eliminate any confusion. You may want to store the scenario schedule as an attachment to the change request and then transpose the changes from it to your actual schedule should the change be accepted.
Update % Complete consistently. One of the questions you have to answer when planning your project is how to reflect task status. Do you only report work when work has been completed? Do you assess completeness every reporting period? Or do you do something in between these two extremes? The approach you choose will be somewhat dependant on how thoroughly you break the work down. If you get very granular, using the Boolean approach (0% or 100%) may work very well whereas, if you report at a higher level you may need to use a different approach. Whatever approach you choose, use it consistently and communicate that approach to your stakeholders. The transparency will help when you report on the status of the project. If you find you have broken work down differently for different categories, report consistently across the categories and be sure to communicate the method to your stakeholders.
Use your MS Project file to base your reports on. You spend a lot of time creating the original MS Project file and then keeping it up to date so capitalise on that work and use it to report as much information about project progress as possible. MS Project has a variety of canned reports and a facility for creating custom reports. Since you spend most of your time planning future work and marking completed tasks 100%, it will be most beneficial for reporting on project progress to schedule. The one drawback I've found with MS Project is the difficulty exporting a report to Excel, but with a bit of ingenuity, you can overcome that obstacle.
Don't try to use the tool to report on budget. Unless your organisation recognises MS Project as an appropriate tool for capturing cost information (it does support capturing this information), and mandates its use for that purpose, don't attempt to use it to report on performance to budget. If your organisation uses a time tracking tool, you should report on performance to budget using that tool and information from your accounting department. You will find that you will be spending hours reconciling the information in your MS Project file with Finance information; don't get caught up in that debate.
Post your MS Project file to a central location. Demystify your project management methods by putting the MS Project file in a central location, accessible by your project stakeholders. All your stakeholders will not have MS Project on their computers so place reports containing the schedule information your stakeholders are interested in, in the same location. Doing this will make your management more transparent and at the same time encourage you to keep your file accurate and up to date.

You should be able to keep your MS Project file up to date and accurate in about an hour each day, with the exception of the day you do your reporting. This is a rule of thumb and the hour is an average - you may spend more some days and less on others. You need to re-visit how you are using MS Project if you find yourself spending significantly more time maintaining it. Remember, MS Project should work for you, not the other way around.