A short course in project management
Microsoft Office Project 2007 Step by Step
By Carl Chatfield and Timothy Johnson
Carl Cha tfield is a certified Project Management Professional (PMP) with extensive knowledge of Microsoft Office Project as well as specific usability issues.
Timothy Johnson has previously worked as an Office Project support professional for several years. Tim possesses in-depth technical knowledge about the software.
Carl and Timothy are the authors of Microsoft Project 2000 Step by Step, Microsoft Project Version 2002 Step by Step and Microsoft Office Project 2003 Step by Step, all from Microsoft Press.
To learn more about other books on the 2007 Microsoft Office system, visit Microsoft Press.
In this article
In our new book, Microsoft Office Project 2007 Step by Step, we provide advice on how best to use Microsoft Office Project 2007 while following sound project management practices. This article focuses on the basics of project management, regardless of any software tools you may use to help you manage projects. While project management is a broad, complex subject, in this article we focus on the “project triangle” model. In this model, you consider projects in terms of time, cost, and scope.
Understand what defines a project
Succeeding as a project manager requires that you complete your projects on time, finish within budget, and make sure your customers are happy with what you deliver. That sounds simple enough, but how many projects have you heard of (or worked on) that were completed late, cost too much, or didn’t meet the needs of their customers?
A Guide to the Project Management Body of Knowledge (3rd edition, published by the Project Management Institute, 2004) — referred to as the PMBOK and pronounced “pimbok” — defines a project as “a temporary endeavor undertaken to create a unique product or service.” Let’s walk through this definition to clarify what a project is and is not.
First, a project is temporary. A project’s duration might be just one week or it might go on for years, but every project has an end date. You might not know that end date when the project begins, but it’s out there somewhere in the future. Projects are not the same as ongoing operations, although the two have a great deal in common. Ongoing operations, as the name suggests, go on indefinitely; you don’t establish an end date. Examples include most activities of accounting and human resources departments. People who run ongoing operations might also manage projects; for example, a manager of a human resources department for a large organization might plan a college recruiting fair. Yet, projects are distinguished from ongoing operations by an expected end date, such as the date of the recruiting fair.
Next, a project is an endeavor. Resources, such as people and equipment, need to do work. The endeavor is undertaken by a team or an organization, and therefore projects have a sense of being intentional, planned events. Successful projects do not happen spontaneously; some amount of preparation and planning happens first.
Finally, every project creates a unique product or service. This is the deliverable for the project and the reason that the project was undertaken. A refinery that produces gasoline does not produce a unique product. The whole idea, in this case, is to produce a standardized commodity; you typically don’t want to buy gas from one station that is significantly different from gas at another station. On the other hand, commercial airplanes are unique products. Although all Boeing 777 airplanes might look the same to most of us, each is, in fact, highly customized for the needs of its purchaser.
By now, you may realize that much of the work that goes on in the world is project work. If you schedule, track, or manage any of this work, then congratulations are in order: you are already doing some project management work!
Project management has been a recognized profession since about the 1950s, but project management work in some form has been occurring for as long as people have been doing complex work. When the Great Pyramids at Giza in Egypt were built, somebody somewhere was tracking resources, schedules, and specifications in some fashion.
The project triangle: view projects in terms of time, cost, and scope
You can visualize project work in many ways, but our favorite method is what is sometimes called the project triangle or triangle of triple constraints.
This theme has many variations, but the basic concept is that every project has some element of a time constraint, has some type of budget, and requires some amount of work to complete. (In other words, it has a defined scope.) The term constraint has a specific meaning in Project 2007, but here we’re using the more general meaning of a limiting factor. Let’s consider these constraints one at a time.
Have you ever worked on a project that had a deadline? (Maybe we should ask whether you’ve ever worked on a project that did not have a deadline.) Limited time is the one constraint of any project with which we are all probably most familiar. If you’re working on a project right now, ask your team members to name the date of the project deadline. They might not know the project budget or the scope of work in great detail, but chances are they all know the project deadline.
The following are examples of time constraints:
You are building a house and must finish the roof before the rainy season arrives.
You are assembling a large display booth for a trade show that starts in two months.
You are developing a new inventory-tracking system that must be tested and running by the start of the next fiscal year.
Since we were children, we have been trained to understand time. We carry wristwatches, paper and electronic organizers, and other tools to help us manage time. For many projects that create a product or event, time is the most important constraint to manage.
You might think of cost simply in monetary terms, but project cost has a broader meaning: costs include all of the resources required to carry out the project. Costs include the people and equipment that do the work, the materials they use, and all of the other events and issues that require money or someone’s attention in a project.
The following are examples of cost constraints:
You have signed a fixed-price contract to deliver an inventory-tracking software system to a client. If your costs exceed the agreed-upon price, your customer might be sympathetic but probably won’t be willing to renegotiate the contract.
The president of your organization has directed you to carry out a customer research project using only the staff and equipment in your department.
You have received a $5,000 grant to create a public art installation. You have no other funds.
For virtually all projects, cost is ultimately a limiting constraint; few projects could go over budget without eventually requiring corrective action.
You should consider two aspects of scope: product scope and project scope. Every successful project produces a unique product: a tangible item or service. Customers usually have some expectations about the features and functions of products they consider purchasing. Product scope describes the intended quality, features, and functions of the product — often in minute detail. Documents that outline this information are sometimes called product specifications. A service or event usually has some expected features as well. We all have expectations about what we’ll do or see at a party, concert, or sporting event.
Project scope, on the other hand, describes the work required to deliver a product or service with the intended product scope. Project scope is usually measured in tasks and phases.
The following are examples of scope constraints:
Your organization won a contract to develop an automotive product that has exact requirements — for example, physical dimensions measured to 0.01 mm. This is a product scope constraint that will influence project scope plans.
You are constructing a building on a lot that has a height restriction of 50 feet.
You can use only internal services to develop part of your product, and those services follow a product development methodology that is different from what you had planned.
Product scope and project scope are closely related. The project manager who manages project scope well must also understand product scope or must know how to communicate with those who do.
Time, cost, and scope: manage project constraints
Project management gets most interesting when you must balance the time, cost, and scope constraints of your projects. The project triangle illustrates the process of balancing constraints because the three sides of the triangle are connected, and changing one side of a triangle affects at least one other side.
The following are examples of constraint balance:
If the duration (time) of your project schedule decreases, you might need to increase budget (cost) because you must hire more resources to do the same work in less time. If you cannot increase the budget, you might need to reduce the scope because the resources you have cannot complete all of the planned work in less time.
If you must decrease a project’s duration, make sure that overall project quality is not unintentionally lowered. For example, testing and quality control often occur last in a software development project; if project duration is decreased late in the project, those tasks might be the ones to suffer with cutbacks. You must weigh the benefits of decreasing the project duration against the potential downside of a deliverable with poorer quality.
If the budget (cost) of your project decreases, you might need more time because you cannot pay for as many resources or for resources of the same efficiency. If you cannot increase the time, you might need to reduce project scope because fewer resources cannot complete all of the planned work in the time remaining.
If you must decrease a project’s budget, you could look at the grades of material resources for which you had budgeted. For example, did you plan to shoot a film in 35 mm when cheaper digital video would do? A lower-grade material is not necessarily a lower-quality material. As long as the grade of material is appropriate for its intended use, it might still be of high quality. As another example, fast food and gourmet are two grades of restaurant food, but you may find high-quality and low-quality examples of each.
You should also look at the costs of the human and equipment resources you have planned to use. Can you hire less experienced people for less money to carry out simpler tasks? Reducing project costs can lead to a poorer-quality deliverable, however. As a project manager, you must consider (or, more likely, communicate to the decision makers) the benefits versus the risks of reducing costs.
If your project scope increases, you might need more time or resources (cost) to complete the additional work. When project scope increases after the project has started, it’s called scope creep. Changing project scope midway through a project is not necessarily a bad thing; for example, the environment in which your project deliverable will operate may have changed or become clearer since beginning the project. Changing project scope is a bad thing only if the project manager doesn’t recognize and plan for the new requirements — that is, when other constraints (cost, time) are not correspondingly examined and, if necessary, adjusted.
Time, cost, and scope are the three essential elements of any project. To succeed as a project manager, you should know quite a bit about how all three of these constraints apply to your projects.
Here is our final word about the project triangle model. Like all simple models of complex subjects, this model is a useful learning tool but not always a reflection of the real world. If real projects always performed as the project triangle suggests they should, you might see projects delivered late but at planned cost or with expected scope. Or, projects might be completed on time and with expected scope but at higher cost. In other words, you’d expect to see at least one element of the project triangle come in as planned. But the sad truth is that many projects, even with rigorous project management oversight, are delivered late, over budget, and with far less than expected scope of functionality. You’ve probably participated in a few such projects yourself. As you well know, project management is just plain difficult. Success in project management requires a rare mix of skills and knowledge about schedule practices and tools, as well as skill in the domain or industry in which a project is executed.
Manage your projects with Project 2007
The best project management tool in the world can never replace your good judgment. However, the right tool can and should help you accomplish the following:
Track all of the information you gather about the work, duration, and resource requirements for your project.
Visualize your project plan in standard, well-defined formats.
Schedule tasks and resources consistently and effectively.
Exchange project information with stakeholders over networks and the Internet using standard file formats.
Communicate with resources and other stakeholders while leaving ultimate control in the hands of the project manager.
Armed with the information about project management contained in this article and the rich functionality of Project 2007 discussed in our book, you are off to a great start with Project 2007.