Read an Excerpt
Chapter 1: Project 2000 Basics
If you're browsing this book, you probably have more than a casual interest in projects and project management. You may have managed scores of projects, or you may be starting on your first project as a team member or project manager. Perhaps you already use Microsoft Project or its competitors, and want to know about the new features of this version of the most widely used project-management software. Whether you're launching your first or fifty-first project, Microsoft Project 2000 can improve the probability that your project will be a success. Before we examine Project 2000, however, we'll spend a few pages on a quick but pragmatic review of project fundamentals.
What Is a Project?
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. Projects account for the other half of the work done in organizations. 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). Here are a few examples of projects:
- Moving your company's offices to a new location
- Developing a new software application
- Creating a policy manual
- Remodeling a room in your home
- Developing an intranet
- Preparing for accreditation or certification
- Revamping a training program
- Starting a new business
- Auditing your organization's software or accounting systems
The four project parameters-time, scope, performance, and costs-are related. This relationship is often expressed as a formula [C=f(P,T, S)], which indicates that a project's cost is a function of a project's time, scope, and performance. One definition of project management is efficiently using resources to complete a project as designed, on time, at the desired level of performance, and within budget. These project parameters are also called constraints.
At any point in time, you can control only three of the four parameters because 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 deck with built-in benches and a small yet attractive planter. A few months ago, your contractor said that she can 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 neglected to contact the contractor. The project time changed, so performance, scope, or costs must also change. The contractor's possibilities 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 know when a project's time criteria change. The project manager (in our example, the contractor) is notified that work must be completed sooner, or could finish later. Changes in scope, on the other hand, can sneak into a project as 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 is used in a number of different disciplines:
- Problem Identification
- Project Design
Whether a product cycle has six stages, or four or ten, the sequence is the same. Each stage has different activities that may require different skills. The project team is the human resource assigned to the project. 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.
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 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 relevant portion 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.
In the definition stage, a person or group of people accurately describes the problem (or, more positively, 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 definition stage is often neglected, which helps explain why some projects fail. The definition of the problem determines the solutions that the project team will examine and eventually choose to implement. If you're focused on rewriting the installation program, you won't spend a lot of time looking at the product packaging. 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!" The challenge of the definition stage is to take the time to thoroughly describe the problem, beginning with the naive question: What is the problem we're trying to solve?
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 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.
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. Then, each strategy needs to be quickly assessed to estimate the time and resources involved. As you'll see in later chapters, you can use Microsoft Project 2000 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 risky aspects of acceptable strategies. Choose the best strategy from those with a level of risk that's acceptable in your organization, and begin designing a project to implement the strategy. Before you begin, check again to make sure that the selected strategy will solve the problem you defined.
In the design stage, it's finally time to put the pedal to the metal and complete a number of tasks. In order to do this, you must
- define the project's objectives,
- finalize the project scope,
- identify project activities,
- break each activity into logical components,
- assign resources, and
- 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, if the timeline can't be met, or if 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." 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. Design serves two purposes: It provides a clear vision for the members of the project team and helps fend off scope creep as the project progresses. The finished design includes a list of deliverables with completion dates...