MS Project – A Modeling Tool

Everyone thinks of MS Project as a project management tool. I have always found this a bit of a misnomer. Project scheduling tool is more apt because that is what it really does – calculates start and end dates for various tasks taking into account their dependencies and resource loading. Project management involves much more than scheduling; time management is only one aspect of project management.

Project management involves:

• schedule management
• finance management
• scope management
• change management
• risk management
• people management
• stakeholder expectation management
• and some more

And most importantly, project management involves decision-making when things start to go wrong!

Except for the first two, MS Project does not really help in any of the other aspects, does it? So let us not call it a project management tool any longer.

Then again, saying MS Project is a project scheduler seems to understate it’s power. To really understand the true nature of MS Project, you need to look at it as a modeling tool.

That’s right. Like you have UML tools for software modeling, MS Project is really a tool for project modeling.

You model a real-world project by doing really just three things:

• breaking it down into a hierarchy of smaller tasks and subtasks (WBS)
• specifying dependencies between these tasks (SF, FS, SS, FF)
• allocating resources (labor or material) to these tasks

For each of these primary modeling activities there are a series of secondary characteristics:

• Constraints on tasks (duration, optimistic duration, pessimistic duration, deadline, start no earlier than, must start on, resource driven, fixed units, fixed duration etc.)
• Lag/lead on dependencies
• Resource calendars, max units, cost, costing method, units assigned to a task etc.

To take your model closer and closer to the real world, you need to specify these characteristics more and more accurately. Hence, the closer to reality you aim, the more complex your model becomes!

Once you create your model, MS Project actually tries to put it to use immediately for you. Based on the model you have defined, MS Project

• calculates all start and end dates for each and every task based on dependencies
• if you perform resource leveling, it calculates all start and end dates for each and every task taking into consideration the resource allocation too
• costs each and every task with rollups up the WBS hierarchy
• performs Critical Path Analysis and highlight tasks on the critical path
• supports PERT by providing for best-case and worst-case durations, start dates and finish dates
• indicates over-allocation of resources (if you have not done resource leveling already)

In this sense, MS Project is a better modeling tool than most UML modeling tools – the only thing they can actually do with your UML model is create skeletal source code, which a good programmer could have churned out with half the effort! Putting it differently, while UML modeling tools are essentially documentation and communication tools, MS Project works with the model you have inputted to generate useful output for you.

Thus, if you look at MS Project as an input-output tool, the output is only as good as the input you feed into it. Many project managers do not put sufficient energy into this modeling exercise and end up disappointed with the output. Not the fault of the tool, really.

The next time you feel MS Project is not worth the effort, ask yourself the following question:

“Is your project too trivial to be worth the modeling effort?’