In project management, most people use Microsoft Project to help plan, organize, and track your projects. There may be other equally valuable tools in use but Microsoft Project has probably the largest user base and it’s the one most people are familiar with today. This is not a training course, or tutorial on how to use Microsoft Project. I’m assuming that you have attained some degree of proficiency with the tool, enough to maybe even had a few bad experiences with it. There are many courses available from Microsoft and others, which will help teach you the fundamentals of using this powerful tool.
Microsoft Project is intended to be a time a labor saving solution. It is rich in features that support a great many simple (and not so simple) functions that are useful during the course of managing a project. The problem with the tool is that, like most feature rich software tools, it gives us enough features to make you feel stupid. 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 Project has to offer can make managing the tool into a very time consuming job, taking time away from more important project management requirements. Some organizations 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 Project.
You can download a sample project plan from Microsoft, if you need a simple example.
The rules listed are intended to help you avoid this wasted time, and actually make the tool work for you and your team.
- Limit Task Breakdown – Break the work items down until you have a set of work packages that you can use to manage the work, and that is all you need to do. Breaking the work down further, just because the package is made up of components probably adds no value and can create 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. Does tracking that unit testing help you track the work? 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, you’ve gone as far as you should go and you can stop.
- Limit Task Count – The more tasks you attempt to track, the more work it will require to track any work completed. You will probably find the optimal number of tasks is several hundred, but it will be specific to your ability. One person might have a personal limit of 200 but you may find that more or fewer tasks work better for you. When you find you are managing a very large and complex project, it may be better to divide the work up into sub-projects to keep the task count to a manageable number. Divide the project into sub-projects and make each team lead or project manager responsible for their own Project document. Roll the key deliverables and milestones up into your overall plan and update your plan only when one of the 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 Project files and manage them individually.
- Limit Relationships – 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. Use this feature to only track “hard” dependencies. Think hard about using the tool to define a relationship if you can’t justify the work overhead. Let’s take the example of a baking a cake. You define the pouring of the batter as one work package. The batter must be cooked before you can begin icing or decorating the cake, so the decorators should be notified when the batter has been cooked and cooled sufficiently for them to start work. You should define the baking of the batter as a predecessor and the start of decorating as a successor. You don’t need to wait until all the decorating is complete to start the cleaning of the baking pans. Defining the point at which dish washers can start cleaning may or may not be a worthwhile exercise, but using Project to define the relationship won’t always help you.
- Use Forecasting Carefully – One of the features that make Project so attractive is its ability to predict the impact 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 possible 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 Status Consistently – One of the questions you have to answer when planning your project is how you will report task status. Are you going to report work when work has been completed, or will you show the status as a percentage of total work required? Will you assess completeness using weekly reports, or will report status each time a task is marked as complete? Whatever approach you choose, use it consistently and communicate that approach to your stakeholders before the project begins.
- Use Project Reports. You will spend a lot of time creating your Microsoft Project files and keeping them updated so you should capitalize on that work. Use your project files to report as much information about your project progress as possible. Project has a variety of canned reports and the ability 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 compared to the schedule. You might not find this process easy, but it is worth the effort to learn the process.
- Avoid Budget Reporting – Unless you are required to use Project as an tool for capturing cost information don’t attempt to use it to report on your project performance to project budget. You will find that you re spending a lot of time updating project status, and tracking budget data in the same project will probably add too much complexity for a beginner or intermediate user.
- Share the Project – You can put your project file in a central network location so other people involved in the project can get to the stored data as often as they require the data. Don’t allow the source of your reports or data be a mystery. All your stakeholders will not have Project on their computers so place reports containing the schedule information your stakeholders are interested in, in the same location, in a format they can access. Just make sure the security is configured properly so your data is protected from unauthorized changes or deletions.
Managing your project using Microsoft Project is a reality that you should learn to accept, alter your processes to include, and encourage your team members and project stakeholders to embrace. Once you have created your project plan, which might take several days of hard work, the daily update process should take less than an hour, depending on the size of the project. You need to re-visit how you are using Project if you find yourself spending significantly more time maintaining it or if you are struggling with one or more of the required features. You should be using Project to make your management of projects easier, not harder.
Microsoft offers some basic training information here.