Understanding Project Management

It’s estimated that half of our work life is spent on routine, repetitive tasks: processing time cards, filling out sales orders, picking up passengers, and delivering parcels. The other half of our work life is spent working on projects of various shapes and sizes—from simple single-day tasks to complex long-term assignments.

Here are some types of projects you might encounter in a typical business or organization. Understanding how to manage projects such as these is key to your business success.

• Moving your company’s offices to a new location

• Developing a new software application

• Creating a policy manual

• Remodeling a room in your home or business

• Developing an intranet

• Preparing for accreditation or certification

• Revamping a training program

• Starting a new business

• Auditing your organization’s software or accounting systems

What Is a Project?

As defined by the Project Management Institute, a project is “a temporary endeavor undertaken to achieve a particular aim.” More precisely, a project is a job that has a beginning and an end (time), a specified outcome (scope) at a stated level of quality (performance), and a budget (costs). The deliberate attempt to control these parameters is called project management.

Note 

The Project Management Institute (www.pmi.org) is the leading professional association devoted to the field of project management.

The four project parameters—time, scope, performance, and costs—are related; controlling one parameter affects the other parameters, and the project outcome. The relationship between the parameters is often expressed as a formula: [C=f(P,T,S)], which indicates that a project’s cost (C) is a function of a project’s performance (P), time (T), and scope (S). One definition of project management is expressed as "the efficient use of resources to complete a project as designed, on time, at the desired level of performance and within budget."

Note 

The Project Management Institute uses the following definition of project management: “The application of knowledge, skills, tools, and techniques to a broad range of activities in order to meet the requirements of the particular project.”

The project parameters are also called constraints. At any point in time, you can control only three of the four parameters; when one of the project parameters changes, at least one other parameter must change in response. Imagine, for example, that you’re adding a deck to your home. The planned deck is an incredibly tasteful 200-square-foot redwood add-on with built-in benches and a small yet attractive planter. A few months ago, your contractor said that she could build the deck for a total cost of $2,500 with three weeks’ notice. There’s only one problem: The deck needs to be completed in the next ten days. You already sent out the invitations for your inaugural deck barbeque, but you neglected to contact the contractor. The project time has changed, and so performance, scope, and/or costs must also change.

To meet your demands, the contractor’s options are limited, as follows:

• Performance: “We have an additional crew that hasn’t built a deck before, but they’ve got some extra time on their hands, so we can assign them to help.”

• Scope: “We can’t build the benches in time, and the deck won’t be stained or treated.”

• Costs: “We can build the deck as planned, but it will cost an extra $750. I’ll have to pay overtime and rush ship the redwood.”

It’s usually easy to keep track of changes to a project’s time criteria. The project manager (in our example, the contractor) is typically notified that work must be completed sooner, or could finish later. Changes in scope, on the other hand, can sneak into a project as its managers, customers, and team members request seemingly minor enhancements. Scope creep—unplanned changes in project scope—is understandable. The project manager and team members want to create a product that people use. Fulfilling requests for minor changes is relatively easy and will certainly please the requestor. The cumulative effect of these small changes, though, can significantly extend the project timeline and costs. Experienced project managers have a formal process for reviewing and approving changes to the project. The process is communicated to everyone involved with the project to stave off scope creep.

Understanding the Project Cycle

The project cycle broadly describes the stages that a project typically goes through from beginning to completion. There are as many descriptions of the project cycle as there are project management experts. Here are the stages of a six-stage project cycle that are used in a number of disciplines:

• Problem identification

• Definition

• Project design

• Development

• Implementation

• Evaluation

Whether a project cycle has six, four, or ten stages, the sequence is the same. Each stage has different activities that may require particular skills. Some projects are short-lived, lasting for a matter of months. Other projects span years; team members leave, and new members are added, but the scope and budget for the project remain unchanged.

Problem Identification

In the problem identification stage, also referred to as the concept stage or needs stage, the project is just a thought. Someone realizes there is a problem in search of a solution, or sees an opportunity that the organization can take advantage of. For example, the Customer Service department reports that half of their calls about software X are user questions about installation. The urge, of course, is to immediately search for a solution. One solution is to rewrite the installation section of the user guide, but is it the best solution or even an appropriate solution? To answer this question, you need to have a better understanding of the problem.

Definition

In the definition stage, a person or group accurately describes the problem (or, in more positive terms, the challenge or opportunity) that the project is attempting to solve. In our Customer Service example, there are a number of possible problem definitions:

• The Customer Service department gets too many calls about installation.

• The installation program is too difficult for customers to use.

• The installation program doesn’t work well on all computers.

• The instructions for the installation routine are incorrect or hard to follow.

• Customers often purchase the wrong software for their computer because the software packages aren’t labeled clearly.

Each of these problems has one or more solutions, but the solutions are different.

The problem definition stage is often neglected, which helps explain why some projects fail. When you define the problem, you determine the solutions that the project team will examine and eventually choose to implement. An often-heard complaint during the project definition stage is, “We all know what the problem is, so why are we wasting time talking about it? Let’s get to work!” But if you’re focused on rewriting the installation program, you won’t spend a lot of time looking at the product packaging. The challenge of the definition stage is to take the time to thoroughly describe the problem, beginning with the na’ve question: What is the problem we’re trying to solve?

When the problem definition is complete, check it out with people outside the project team. This is a good time to talk to the person or department who initially identified the problem. When a problem involves customers, some organizations survey customers to help gauge the accuracy of the definition.

Note 

In the past decade, the trend in project management has been to study and define the problem and its solution from the customer’s point of view. For example: “Customers should be able to easily install and use the correct version of software X.”

When the definition is accurate, the team can begin identifying potential solutions. Brainstorming possible strategies that address the problem is a good way to begin. Each strategy then needs to be quickly assessed to estimate the time and resources involved.

As you’ll see in later chapters, you can use Microsoft Project 2002 to assess strategies. You’ll eliminate some strategies in this analysis because they’re cost-prohibitive, require resources your organization can’t hire or contract, or would take too long to complete. For the remaining strategies, you’ll complete a risk assessment. Ask what can go wrong and how your team could respond if the worst happened. Use the risk assessment to eliminate high-risk strategies and identify dicey aspects of acceptable strategies; then choose the best strategy with a level of risk that’s acceptable in your organization. Make one more check of whether the selected strategy will solve the problem you defined, and begin designing a project to implement the strategy.

Project Design

In the design stage, it’s finally time to put the pedal to the metal and complete a number of tasks, such as:

• Define the project’s objectives

• Finalize the project scope

• Identify project activities

• Break each activity into logical components

• Assign resources

• Create estimates for time and costs

This is the “go/no go” point of the project. The outcome of the design stage is a project budget and timeline. If costs are prohibitive, the timeline can’t be met, or the outcome is not desirable, a decision may be made to scrap the project. On the other hand, if a realistic solution can be attained in a cost-effective and timely manner, the project may very well get the “go ahead.”

Design serves two purposes: It provides a clear vision for the members of the project team, and it helps fend off scope creep as the project progresses. Project design is critical because the parameters you set or accept during design determine what victory—the successful completion of the project—will look like. Project objectives should be well-defined products or services, often called deliverables, with completion dates.

Death Marches

In some organizations, the design stage includes pressure to trim the timeline or budget in ways that potentially compromise the project. In the book Death March: Managing “Mission Impossible” Projects, software project manager Edward Yourdon defines a death march as a project in which at least one of the four parameters exceeds the norm by at least 50%. Perhaps a two-year project is optimistically scheduled for completion in 12 months or less, the staff or budget for a project is cut in half, or the features and performance requirements are twice what can reasonably be completed during the life of the project.

When one of the parameters is off by 50% or more, the likelihood of project failure is at least 50%. As the project deadline approaches, members of the project team do triage by lowering performance standards, abandoning project objectives, or spending more money to complete the project within at least one of the specified parameters—activities—that should have occurred in the design stage.

Near the end of the design stage, circulate a project proposal that describes the project in detail so that project team members and managers are all aware of the project’s scope, costs, performance standards, and timelines. You can print some of the reports you need for the project proposal from within Project 2002. Other parts of the document may be created in Word, PowerPoint, Excel, or other applications.

You should also have the project’s customers and other stakeholders sign a letter of agreement or project charter that indicates their approval for the project design, budget, and timeline. In most organizations, this is done for internal customers (the department or people the project is being done for) as well as external clients. Use the final budget and timeline information to update your project information in Project 2002 before moving into the next stage of the project.

Development

In the development stage, you expend resources according to the project plan to complete the activities specified in the project design. If the project outcome is a new product, the manufacturing unit tools up and the product begins rolling off the assembly line. In the software industry, interface specialists begin designing the interface and then programmers start writing code. In publishing, authors write, editors edit, and page layout technicians lay out pages. In an organization that creates new curricula, trainers design and write the curricular modules.

Quality assurance and communication skills are vital to measuring performance and communicating the status of the project tasks in the development stage. As tasks are partially or wholly completed or revised, you update your project file in Microsoft Project. Project 2002 helps you manage development by providing accurate comparisons of actual performance and resource use against the project plan, budget, and timeline.

Implementation

Implementation involves field testing and measurement. Products are used by focus groups, software is sent to beta testers, and new courses are tested on a limited basis. Based on feedback, products might be modified or re-engineered, and services or service delivery might be redesigned.

Note 

There is a tendency to rip through the implementation stage with great speed, particularly if the project involves a product. Especially in the computer industry, the conventional wisdom is that it’s better to release an adequate software version or microcomputer processor on time than to release a drastically improved version of the same product six months late.

Evaluation

In the final stage of a project, members of the project team review the project. Using project reports plus the team members’ own personal experiences with the project, decisions can be made about what worked well, and areas for improvement can be identified. Even when a project has been extra-ordinarily successful, conducting a good evaluation can be difficult—the project is over, you already held the victory party, and team members have been assigned to their next projects. Do it anyway. Solid, thoughtful project evaluations can provide a foundation for the organization’s success in future projects.

Note 

If you want more information on project management strategies and practices, we recommend The Project Manager’s Desk Reference, by James P. Lewis (McGraw Hill, 1999, ISBN 0-07-13-4750-X) and Project Management for the 21st Century, by Bennet P. Lientz and Kathryn P. Rea (Academic Pr., 1998, ISBN 0-12-449966-X). For insight on project management in high-tech industries, see Edward Yourdon’s Death March (Prentice Hall, 1999, ISBN 0-13-748310-4), mentioned earlier in this chapter.