On Product Development and More...

A client recently asked me to provide Microsoft Project training to their organization.

Great, I thought. This is an opportunity to not only present some best practices for using Microsoft Project, but also to introduce some project management best practices into the organization.

Immediately, I turned to one of my favorite Microsoft Project books, "Dynamic Scheduling With Microsoft Office Project 2003", written by Eric Uyttewaal.

The book covers the key aspects of creating schedules: Tasks, Work Breakdown Structures (aka WBS), Estimates, Dependencies, Constraints, Resources/Assignments. It also provides advise on Schedule Optimization (Critical Path, Resource Critical Path, CPM, Monte Carlo Simulation) and Schedule Management.

What I like about Uyttewaal’s book, is how he ties together project management, as a discipline, with managing projects using a tool (in this case, Microsoft Project 2003).

He explains how to use MS Project in the context of one of the best known project management models, the Project Management Body of Knowledge (or PMBOK®), which is the standard put forward by the Project Management Institute (or PMI). Of the 5 process groups described in the PMBOK (Initiating, Planning, Executing, Monitoring and Controlling, Closing), it should not be a surprise that MS Project is most used during Planning and Executing.

Uyttewaal encourages the creation of dynamic schedules. He explains that a properly created is similar to an architectural drawing or model. When properly created and maintained, the model can be a very powerful tool used to conduct what-if analysis.

In addition, when the model is properly updated, it represents what is happening on the project. As such, everyone has clear visibility into where the project is and how we are doing versus a baseline. This allows us to calculate Earned Value metrics which are critical for tracking progress vis a vis time and duration.

Overall, MS Project is a good tool for helping organizations plan and executing projects. At the same time, there is significant investment involved - someone needs to keep that schedule updated particularly during the sometimes chaotic execution phase.

Why? Because if the schedule is not updated, the model becomes static and just about useless (from a forecasting, tracking and visibility perspective). This means that you need to invest time to update what is happening (when things started, when they completed, how much actual work was involved, what remaining work exists). More importantly, things rarely proceed as planned. As such, the schedule needs to be updated to reflect tasks that run behind/ahead, tasks that start or finish late, tasks that start or finish early and tasks that change (either new tasks are introduced, existing tasks are changed or removed). And, as we update the schedule during the execution phase, we need to always make certain that people's workloads are always balanced (so that over-allocations do not exist).

The effort is non-trivial and becomes a major commitment in time.

For this reason, I have seen numerous software companies - start off using MS Project (or similar tools) and then scrap the effort once execution begins. Some stop tracking altogether. Others turn to alternative tools (like a burn down chart) to approximate project status.

Honestly, I am not 100% certain whether, after the training, my client will end up using MS Project for effectively managing their projects. Nevertheless, I am very confident that the concepts discussed during the training course will enable the team leaders to become better at project management and be in a better position to more effectively manage their portion of the project.

Note: If you are interested in learning how to use Microsoft Project to manage your software development projects, please contact me.