Patrick Beeson

*Note: This is the second of a series of entries on project management. I'm publishing these as part of a class I'm taking towards gaining my PMI certification later this year.*

Planning is important, as most anyone involved with project management can attest. It's often the key to a successful project.

This was the topic of my second project management class at UT. And it's also one of the most important areas to prepare oneself for in taking the PMI certification exam.

Planning as a process

Planning in project management provides the basis for initiation, implementation and termination of a project. It is the second of the five processes of project management. These are:

1. Initiating: Recognizing that a project or phase should begin and committing to do so.
2. Planning: Devising and maintaining a workable scheme to accomplish the business need that the project was undertaken to address.
3. Executing: Coordinating people and other resources to carry out the plan.
4. Controlling: Ensuring that the project objectives are met by monitoring and measuring progress and taking corrective action when necessary.
5. Closing: Formalizing acceptance of the project or phase and bringing it to an orderly end.

Business needs

An important part of planning is determining the business needs. No matter what the project, there should be time for the project manager and customer to work together to ensure deliverables are met as planned.

This warranty or service period can be worked into the initial project planning. The customer should always be aware of this aspect of the product. Both parties must agree to the terms defined.

Scope management

Scope is part of a project's business needs in that it boils down to agreeing on what the project will and will not deliver. It's also where most projects can fail.

Therefore, it's vital that proper scope be constructed and agreed upon in the planning process. Once the scope is locked-in, the management of time and resources can begin.

Scope can be defined as what a project manager commits to delivering. It's never defined at the start of the project, and generally not fully defined even midway through development. A projects' requirements can be used to test scope.

A project's scope can be questioned by stakeholders however. But it's important to remember that scope creep -- when the functionality or overall breadth of the project creeps outward as it progresses -- is the leading cause of project failure. Adding what seems to be a cool piece of functionality to a project can cause delays for redevelopment and effect other pieces of the project.

When defining a project's scope, it's good to look for what and who will be impacted by a project. What other projects will be impacted? It's also wise to state the boundaries of a project so people will know what/who is included and excluded.

Some of the areas that scope can impact include:

• Departments
• Personnel
• Location and regions (such as an office)
• Business processes
• Products

Despite scope being important to "lock-in" for a project, it can change over time. Care must be given to ensuring all areas of impact are also updated. For instance, if a projects' deliverables change estimates for cost, effort and duration must be reexamined because they may no longer be valid.

Scope can also come in two types: project and product scope. Product scope is the end result of what the project will create, while project scope describes the work to create the product scope. In this way, the two types support each other.

Earlier I mentioned a requirements document. This is essentially what the customer wants for a project.

Project managers need to play journalist here by listening, querying and researching the job that needs to be done for the customer. When the two parties are in agreement, the project manager should create a scope statement:

A document that captures everything that is considered in scope and defines the relevant things that are out of scope.

The scope statement clarifies the project and requires that the stakeholders sign off on the document. It is the guide for all future project decisions.

Any change going forward is managed by a change control system, which helps shield from unnecessary changes. The process is as follows:

• Document change request
• Why is change needed?
• Ramifications of the project deliverable if change is denied

The CCS can also be sent to a change control board who can elect to accept or deny the change.

Work Breakdown Statement

The WBS is another critical part of project planning. It is the breakdown of deliverables into more digestible items. This helps the customer get a clearer picture of what will and won't be part of the project.

When creating a WBS, it's wise to use the "8/80 Rule":

The 8/80 Rule requests that the smallest deliverables in the WBS equate to no more than 80 hours of work and no fewer than 8 hours of work to create.

When this is done, a project manager needs to decide if cost and duration estimates can be developed for each deliverable. For example, if we were creating a Web site there might be the following items:

• Hosting
  • Domain
  • Server
  • Database
  • Programming language
• Design
  • Sitemap
  • Comps
  • Templates
  • Markup
• Content
  • Sections
  • Copy

And so on.

There are five major reasons for creating a WBS:

1. Cost estimating: Create accurate estimates of what the project will cost to complete
2. Cost budgeting: Allows for tracking the cost baseline
3. Resource planning: Each deliverable is revealed, which helps identify areas expertise is needed
4. Risk management estimating: Consider risk for each deliverable and analyze them
5. Activity definition: Define activities for each deliverable

Scope verification

Scope verification is:

The project manage and project customer inspecting project deliverables to ensure that all promises in a project plan exist in the completed project.

The customer and project manager can check off each item in the WBS. And when scope is complete, the project is complete.