For most short, one- to six-month projects, Microsoft Project can become a nightmare, depending on the complexity of the project, in most cases. What management tool would you recommend for these types of projects?
Microsoft Project is a very mature, comprehensive, and robust tool for managing a wide range of projects. It’s also a tool that can consume hours and hours of a project manager’s time trying to get the tool to reflect reality. I’ve seen it happen more than once where managing the MPP (Microsoft Project’s file extension and term of endearment) becomes a project in and of itself. This is clearly a situation where the use of Microsoft Project has clearly run amok.
Given that I am a former Microsoftie, I have more experience with Microsoft Project than I do with most other project management tools. What I have learned, though, is when to use Microsoft Project and what features to use.
First off, let’s start with the question “To use or not to use Microsoft Project?” My default position is to try to manage a project through simple task lists which outline what needs to be done, who needs to do it, and when it needs to be done by.
If I have generally fewer than 20 tasks, a duration less than three months, minimal dependencies between tasks, a flexible completion date, and a very small (less than five) project team, I will more than likely use a task list versus Microsoft Project. It is easier to manage, and my risk of the project slipping because of task slippage is relatively low. I’ve run plenty of successful mini-projects very effectively using this method. Excel works just dandy in this scenario.
Projects like I outlined above, though, are typically less frequent in the world of a project manager. Projects where you have a larger team with significant dependencies and a “do-or-die” end date are certainly more the norm than the exception in environments where I come from, so in those situations I am more likely to use Microsoft Project.
However, I usually limit my usage to identifying and managing to my critical path (where a one-day slip on any task means the entire project slips by one day) on the project. Managing to the critical path means clearly outlining the tasks, durations, dependencies, and resources assigned to the tasks relative to the project end date and seeing where the critical path tasks through the project lie.
I then realistically adjust the tasks, resources, dependencies, and durations to try to make my project fit within the end-date constraint. Sometimes it all works out, and the project is doable by the end date. Other times Microsoft Project will tell me that there is no way in blazes that my project could be accomplished by the end date — very handy information to have to avoid over-committing your resources (and yourself) to a project that isn’t doable.
I typically don’t use Microsoft Project for budget management or things such as earned value tracking. I’m more likely to use an Excel spreadsheet for tracking budget to actuals. I also don’t bother with earned value tracking.
So the answer to the question is “If you have a simple project with a small project team, short duration, and flexible end date, then consider a simple task list. If you see that you’ve got more complex dependencies, a longer duration, a larger project team, and a do-or-die end date, then use the scheduling and critical path management features in Microsoft Project.”
Regardless of your approach, don’t allow yourself to get an unrealistic expectation of what can be accomplished just because “the plan says so.” Make sure you review your plan with your team members and ensure that the team is bought into the work and the delivery schedule. Regardless of the planning tool you use, if you don’t have the team buy-in, your project is doomed from the start.
Got a question for Lonnie? Ask us!
About the Author
Lonnie Pacelli is an internationally recognized author and is president of Leading on the Edge International. Lonnie has had over 20 years of leadership experience as an executive, project manager, developer, tester, analyst, trainer, consultant, and business owner. During his 11 years at Accenture, he built leadership expertise consulting with many Fortune 500 companies including Motorola, Hughes Electronics, and Northrop Grumman. During his nine years at Microsoft, he continued building leadership expertise through the development of some of Microsoft’s internal systems, led their corporate procurement group, managed their corporate planning group, and led company-wide initiatives on continuous fiscal improvement and training process optimization. He has successfully implemented projects ranging from complex IT systems to process reengineering to business strategies.
See more on Lonnie at www.leadingonedge.com and www.smallbizmadesimple.com.
