Microsoft Project Seems Synonymous with Project Management, But is It Really the Best Place to Start?

We have all seen it, and have likely been there at one point or another. A Project Manager is assigned a new project and instantly follows his impulse to crack open his laptop, start MS-Project and begin the planning process. In doing so, he immediately, without hesitation, dives headfirst into his project and begins to waste time in the name of advancing it. Realizing his own shortcomings while experiencing major difficulty developing “the plan”, he tries to include those more knowledgeable than himself in the process, which unknown to him, only serves to double, triple or quadruple the amount of time (effort) wasted. His laptop is open, his two to four key people are around the board room table with the MS-Project “plan” up on the Proxima screen so that everyone can be on the same page.

Producing an MS-Project Project Plan may seem like an appropriate goal to rapidly bridge between concept and execution, however I can assure you that in months to come as this project plan incurs several re-writes and the painful impact of a myriad of issues, the Project Manager in the scenario above, will likely develop a different opinion and wonder why his planning team didn’t develop the plan correctly the first time.

Within the scenario, I described a situation where the Project Manager became drugged by the technology, preventing him from doing three major things. First, as he began his planning process, he forgot (or did not realize) that there is an actual process to planning. He just opened up the laptop, and began typing stream of thought of what he thought the plan should be.

Second, he confused the activity process of Project Planning with its intended result called a Project Schedule. In many circles the Project Schedule is inappropriately called the Project Plan, also known as Project Management Plan (PMP) which is a narrative based document developed to guide project operations. Two entirely different things as you start the planning process with one and end with the other. Talk about doing things in a backward manner! Such commonly bad usage of these terms by those who do not know the differences between a PMP and a schedule, often creates confusion.

The activity “guidelines” within the graphic below are defined by the Project Management Institute (PMI), Project Management Body of Knowledge (PMBOK). As you can see, Develop Project Management Plan is the first activity that should be completed followed by 19 other activities before we are prepared with enough information to produce a project schedule, where MS-Project can be used.

PMI Project Scheduling Process

Aside from calling the Project Schedule the wrong thing, he also forgot that his desired result is not only to develop a Project Schedule, but to develop one that is realistic and achievable. Within the scenario, the manager was having difficulty building the plan because the plan definition was not defined and therefore, he was building it in a vacuum. This means that by doing most, if not all of the activities that occur before Schedule Development in the graphic above, we would stage our schedule (and therefore the project) for success, armed with enough information to develop the schedule correctly the first time.

Of all the things that the Project Manager did wrong, he did one thing correctly, albeit for the wrong reasons. He eventually included his team in on the planning effort realizing his own shortcomings. The purpose of a project manager is to lead the team through an optimum path through the project, clearing away the jungle vines and debris so that work can be done. Though Project Managers often analyze the information available to make project critical decisions, they are not unusually intelligent people that know all and see all. To other people this point is usually understood, although it may not be understood by the Project Manager themselves. To prevent the planning process and project schedule from being developed in a vacuum, the project manager, must communicate with his team and and capture the result within a number of planning artifacts. Typically, the project definition artifacts that result from these activities are too much work for one person, requiring a team to help fully define and plan the project.