Microsoft Project is an incredible tool for scheduling a project. But it's not necessarily where the project should begin. I've developed a set of steps I follow every time to begin a project, which allows me to know where compromises can and can't be made and also gives me a solid foundation upon which to base continual improvement of my process. In this article, I share my approach, which consists of three components -- what I call: the right work, the right people, and the right starting point.

The Right Work

Answering a few key questions before planning starts makes the project clear and helps to identify the potential conflicts the project could face. Here are the six questions I like to be able to answer (though yours may vary):

Concept Phase (which usually results in a business case):

• Do we know what problem we're trying to solve?
• Does the proposed solution solve the problem or at least a portion of it?
• Has the requestor agreed with the solution set?

Initiation Phase (which usually results in a project charter):

• Has a leader taken responsibility for the results and defined who decides what?
• Are the stakeholder impacts known?
• Is the priority of the project known?

If we can't answer these basic questions, we may not be ready to plan the project or there may be risks that make the project difficult to plan. These questions will need to be resolved at some level before scope can effectively be decomposed on the project. During the concept and initiation phases, Microsoft Project can be used to develop a high-level Gantt chart, but without good information it would tend to give a sense of accuracy that may not be appropriate for the culture or project management maturity level of the company.

The Right People

This component has two aspects: the right project manager and the right project team. When we're ready to plan a project, the project manager should be clearly authorized by the sponsor to run the project. Depending on the organization's culture, this is either a formal or informal process. Either way, it should be clear to the organization what level of authority the project manager has.

The right team is a bit different. Defining this depends on the scope of the project. The bigger the scope, the higher level of resources needed for initial planning. The key is to ensure stakeholder representation for all  groups. These individuals should be positioned  neither too high nor too low in those groups. We want resources that will be responsible for the production procedures at the table and ideally know something about the following:

• production work
• the quality of the resources
• the roles of the resources
• the existing work processes
• existing required standards
• existing leadership processes

They'll be able to help determine how much additional subject matter expertise is needed. That kind of knowledge of the business at hand as well as the organization will be a great help to the initial planning, including scope decomposition.

Once again, Microsoft Project will be of little use at this point unless we use it to build an initial roster in the resource pool. It's likely that we would use other tools for this until we get further into the project planning process.

The Right Starting Point

Now that that the right work is complete and the right people have been identified and set to work,, we can begin to decompose the scope in planning. Identifying the business outcomes clearly and creating work packages or deliverables to accomplish those outcomes is the key to defining the right starting point.

The scope can be decomposed with a number of methods. I prefer using a work breakdown structure or WBS (usually via an idea mapping tool), and building a resource allocation matrix or RACI (usually via a spreadsheet).

Once the "what" of the project (the deliverables) and the "who" of the project (the RACI chart) are known, the deliverables can be sequenced for the outcomes. Microsoft Project works well here. Yes -- finally! Here's the best time to start using the tool.

Transferring the complete deliverable decomposition from the WBS to Project allows us to follow a controlled approach to assure that scope is completely defined and nothing was missed in the translation. For some this may seem like an extra step. Experience has shown that a larger number of people can understand a pictorial view of the project better than the linear view as displayed in a Gantt chart. An idea mapping tool is much more flexible initially for communicating scope until we're ready to sequence the deliverables.

Once the deliverables are entered into Project, deliverable definition is complete, and the deliverables are clearly sequenced to the business outcomes, further decomposition of the work can begin and a baseline can be drawn to control the deliverables in scope. Here again Project can help us with an initial baseline, or we can use our RACI chart for control. At this point, we can build out the task details in accordance with our organizational standards and make the appropriate assignments in Project.

Optimal Control

Using Microsoft Project at the right time allows us to control the project more effectively and to be more efficient. Applying the tool too early can create a general belief in accuracy and precision that may not yet exist. Also, tool use too early may hinder development of the kind of baseline control needed to assure that the work aligns with the desired business outcomes. The key to good Microsoft Project use is knowing what must be present and when not to compromise in the processes we've established to manage our efforts.

Join the Discussion!

What pre-Microsoft Project process do you follow? Post your ideas in the MPUG discussion forum thread here. We'll  publish the best submissions in the MPUG newsletter!

Mark Swiderski, PMP is the President and CEO of Praxilient, a management consulting firm in Northern Wisconsin that helps clients improve strategic performance and gain better project results. Mark has 20 years of project management experience in a wide variety of industries and business functional areas. He's passionate about helping practitioners and organizations perform more efficiently. Reach Mark at (920) 257-2080 x302 or mark.swiderski@praxilient.com.