By Bonnie Biafore
Book Price: $39.99 USD
£24.99 GBP
PDF Price: $27.99

Cover | Table of Contents

Table of Contents

Chapter 1: Projects: In the Beginning

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Microsoft Project is brimming with features to help you manage any kind of project, but you have to know something about project management to make those features sing. If your boss hands you a project to manage, and you ask what she means by project and manage, this chapter is for you.

This chapter explains what makes a project different from day-to-day work. You'll learn what project management is at a high level—and why it's worth the effort. Project management helps you deliver the right results on time, within budget, and without going into crisis mode. When a project falters, project management techniques also help you get it headed back in the right direction.

But before it even begins, a project has to make it through a selection process. Just like a major-league baseball player waiting for a good pitch before he swings, you'll learn what to look for in potential projects. (Even if your boss currently mandates which projects you manage, learning to prioritize and select projects may increase your influence in the future.)

The chapter concludes with one skill that no project manager can afford to ignore: gaining and maintaining the support of project stakeholders—the folks who care about the project's success. You'll learn how to identify a project's stakeholders and their expectations, and how to keep them on board so they're there when the project needs their help.

Projects come in all shapes and sizes, from setting the date and time on a digital watch to designing a timepiece so powerful that you need a PhD to operate it.

What's the common thread that unites all projects and makes them different from other kinds of work? Here's one way to define a project:

A project is a unique endeavor with clear-cut objectives, a starting point, an ending point, and, usually, a budget.

• Unique is the most important word in the definition above, because every project is different in some way. Assembling reinforcing steel on site for different buildings, built on different topography, during different weather conditions, constitute different projects. The building designs, site conditions, and weather make every construction job unique, even if the buildings are cookie-cutter copies. On the other hand, a crew that cuts and bends concrete reinforcing bars performs the same work every day, typically called

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

What's So Special About Projects?

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Projects come in all shapes and sizes, from setting the date and time on a digital watch to designing a timepiece so powerful that you need a PhD to operate it.

What's the common thread that unites all projects and makes them different from other kinds of work? Here's one way to define a project:

A project is a unique endeavor with clear-cut objectives, a starting point, an ending point, and, usually, a budget.

• Unique is the most important word in the definition above, because every project is different in some way. Assembling reinforcing steel on site for different buildings, built on different topography, during different weather conditions, constitute different projects. The building designs, site conditions, and weather make every construction job unique, even if the buildings are cookie-cutter copies. On the other hand, a crew that cuts and bends concrete reinforcing bars performs the same work every day, typically called operations, even if the dimensions of the rebars vary.
• Clear-cut objectives are necessary if you want any hope of reaching the end, staying within budget, and making customers happy. Whether you call them specific, quantifiable, or unambiguous, objectives define what the project is supposed to accomplish, so everyone knows when it's done. "Keep the cat off the kitchen counter" is work that never ends. On the other hand, an objective that you can complete, albeit with some physical risk, is "Remove the cat from the Thanksgiving turkey carcass."
• Although some projects seem interminable, a project begins at one point in time and ends when it achieves its objectives. When the construction crew wires the last rebar into place on site and the inspector approves the work, the crew's ready to move on to the next project. However, if the end always seems just out of reach, poorly defined objectives are usually to blame. You'll learn how to define objectives in .
• Budgets play a role in most projects, because very few people consider money irrelevant. In addition to achieving the project objectives within the desired timeframe, you also have to keep the price tag within an acceptable range.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

What Is Project Management?

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Project management is the art of balancing the project objectives against the con-straints of time and budget. Of course, achieving that balance requires skill, experience, and a boatload of techniques. This section gives you a glimpse of what happens from a project's infancy to its old age.

Novices sometimes think of project management as building a sequence of tasks, but those in the know recognize that project management starts before a project officially begins, and doesn't end for a while after the project's objectives are achieved. There's no one way to manage projects, but most methodologies cover the following five phases (also illustrated in ):

The Project Management Institute (PMI) is a nonprofit orga-nization with its hooks in all aspects of project management. It provides project management education and offers certifications to validate that project managers know what they're doing. PMI also supports research into new project management methods.

PMI publishes the Project Management Body of Knowledge, also known as the PMBOK Guide. This document represents the collective knowledge of a slew of experienced project managers, boiled down into an overview of project man-agement steps, why you perform them, and the results they produce. A word of warning—the PMBOK is dry, formal, and doesn't tell you exactly how to perform project management tasks. It's great as a reference, but (unlike the book you're holding now) useless as a how-to book.

• Getting started. Often called initiating, the first phase of project management is short, but important. It's your only opportunity to get the project off to a good start. In this phase, you answer questions like "Why are we doing this project?" and "Do we really want to do it?" The initial attempts to describe the purpose of a project may produce vague results like "Launch a Web site to improve customer service." But as you identify the project stakeholders (), you learn what the project is about and what the stakeholders hope to achieve. The more specifically you describe your project's objectives, the greater your chances for success.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Why Manage Projects?

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The five phases of an unmanaged project go something like wild enthusiasm, dejected disillusionment, search for the guilty, punishment of the innocent, and promotion of those not involved. An unmanaged project is like a black hole that sucks up every person, machine, and dollar—and still doesn't deliver what it's supposed to. Despite the unpleasant alternatives, many organizations fear that project management requires bureaucratic and inflexible procedures, and may even make projects take longer. On the contrary, planning projects and managing the plan provide many benefits including the following:

Companies that perform project after project usually pick a project management methodology, such as Six Sigma or Agile Development, and stick with it. That way, all their projects follow approximately the same project management process. Teams learn what works and what doesn't. Everyone learns what to do and expect.

The approach you choose depends a lot on the environ-ment in which you work. Complex environments with large projects, widely distributed teams, or multiple vendors usu-ally need a robust project management methodology with formal, well-documented procedures, standardized forms and documents, and software like Project Server to keep track of everything. Simpler, smaller projects would bog down with that kind of overhead, but run just fine with a more informal approach.

This book introduces the basic steps, which you can use as a starting point. If you want a ready-made methodology to adopt, check out the following resources:

• Project Planning, Scheduling & Control by James P. Lewis (McGraw-Hill) bucks the trend in project man-agement books by providing an easy-to-read, even amusing, description of one way to manage projects.
• A Management Framework for Project, Program, and Portfolio Integration by R. Max Wideman (Traf-ford Publishing) tries to simplify project management—and for the most part succeeds.
  TenStep, Inc. (www.tenstep.com) offers a project management approach that predictably takes 10 steps from start to finish. This approach can be adapted to projects, large and small. If you register on the Web site (for free), you can mine a mother lode of additional project management wisdom.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Picking the Right Projects

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

There's never a shortage of projects, but there's not enough time, money, and staff in the world to do them all. Before you begin managing a project, make sure it earns its place in the project portfolio. Throwing darts or pulling petals off daisies isn't the answer. You're better off knowing what's important to your organization, and picking projects that support those objectives.

Project selection criteria are just as helpful once projects are underway, because projects don't always deliver what they promise. If a project isn't meeting expectations, you can decide whether to give it time to recover or cut it loose. Similarly, if a juicy new project appears, you can compare its potential results to those of projects already in progress to see if it makes sense to swap it for a project that's partially complete.

Selection criteria can save time and effort before the selection process even starts. People thinking about proposing a project can evaluate potential results before facing the selection committee. If the results don't pass the test, there's little point in presenting the project to management.

To make good decisions, you need some kind of consistent selection process, whether you're a small business owner allocating limited resources or a committee setting up a multiproject portfolio. You can evaluate the candidates, and choose the projects with the most compelling results. When you run out of money and resources, you can put any remaining winners on the waiting list.

Some projects are no-brainers, like the ones needed to satisfy government regulations. For example, companies that want to stay in business have to conform to the accounting requirements of the Sarbanes-Oxley Act. On the other hand, you can cull projects by picking the ones that support the organization's mission and business objectives. If your company dabbles in widgetry, the goal might be getting your tools to market before the competition. In the healthcare industry, safety trumps speed, because recalling devices already implanted in people is going to hurt the patients and the company pocketbook. Any time you begin to describe a project by saying, "It would be nice…" you may as well stop right there—unless you can link the project to quantifiable business objectives as well.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Gaining Support for a Project

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Sponsorship is important during the selection process, but support becomes crucial once projects start up. Projects rarely finish without running into some kind of trouble, and you often need help digging them out. Alas, many people lend a hand only if there's something in it for them, which is why identifying the people who care about a project (the stakeholders) is so important.

Stakeholders can play a part in a project from proposal to the final closeout. During the planning phase, stakeholders help define the project and evaluate the project plan. A few lucky stakeholders cough up the money to fund the project. During the execution phase, stakeholders help resolve problems, make decisions about changes, risk strategies, and whether to fork over more money if necessary. At the end of a project, some of the stakeholders get to decree the project complete, so everyone can go on to another project.

Figure 1-4: XIRR includes a third argument called "guess," which is the first return you use in the search for the IRR. If you leave the guess argument blank, Excel uses 10%. Depending on whether the resulting NPV is positive or negative, the XIRR function tries a different value until NPV equals zero.

Commitment comes from all levels of an organization, from the executive-level project sponsor to the people who work on the project every day. Project stakeholders get their name because they have a stake in the outcome of the project. They either give something to your project, like the managers who provide the resources you use; or they want something from it, like the customer who implements the software system a project delivers.

Identifying stakeholders can be tough. Some don't realize they're stakeholders, like the development team that learns about a project when they receive the list of impossible requirements from sales. Other people pretend to be stakeholders, but aren't. For example, an engineering department gets chummy because they see your project as an inexpensive way to get their new database. If you're not careful, your project gains extraneous requirements, but of course, no additional money.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Publicizing a Project and Its Manager

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

A project that gets the OK to proceed needs publicity like movies do. You want people to know the project is starting, and why it's so important. Most important, you want the entire team to get fired up over their new assignments. The project manager needs some publicity, too. Your authority comes from your project and project sponsor, not your position in the organization, so people need to know how far your authority goes. The project charter is like a project press release—it announces the project and your responsibilities and authority as its manager.

A project charter doesn't impress anyone unless it comes from someone powerful enough to bestow you with authority, like the project sponsor or the project customer. On the other hand, don't have the biggest kahuna distribute the charter unless that person actually knows something about the project. You need authority, but credibility is important as well.

You may have to tactfully suggest that the project customer or sponsor develop and distribute the project charter. You can often get the project charter out more quickly by authoring it yourself, so the sponsor has only to sign and send it.

A project charter is pretty simple, as shows. (You can download a sample project charter, Ch01 Project_Charter.doc, from www.missingmanuals.com/cds.)

Here are typical elements of a project charter:

• Project name. A catchy name that rolls off everyone's tongue is wonderful, but a brief name that identifies the project will do.
• Purpose. The mission statement works well as the purpose, because it's a highlevel view of the reason for the project. If you haven't crafted a mission statement yet, simply summarize what the project is supposed to achieve.
• Project manager. Announce the project manager for the project. If you're writing the project charter for a sponsor to sign, don't be afraid to blow your own horn. Stakeholders need to know who you are, and why you're the person who's going to make this project a success.
• Project manager's duties. Summarize the duties of the project manager. This brief introduction to the project manager's tasks can warn people about what a project manager may expect from them—and educate people about the myste-rious activities that project managers perform.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter 2: Planning a Project

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

If you're out for a leisurely drive, you can take any road and see where it takes you. But, when you're heading to scary Aunt Edith's house for Sunday lunch, you'd bet-ter know where you're going. Drive as fast as you like; if you're on the wrong road, you're not going to get there on time. If you want to make Aunt Edith happy, you need to plan how and when you're going to get to her house.

You've probably worked at a few places where people think they don't have time to plan, as the box on explains. Managers breathe down your neck asking how much you've finished, while you're still wondering what you're supposed to do. You may have to do work over, because no one agreed on how to do it right in the first place. Critical deadlines slip by, and the pressure to finish is even greater this time.

There's a better way. Planning ahead helps you do the right things the right way the first time around. A project plan acts as the road map to your destination. The less time, money, or resources you have, the more you need to plan. Think, for example, about those time-share presentations where a company rambles on for a few hours about the benefits of "owning the dream." Then, think about the 30-second commercial selling the same dream. Squeezing the message into a brief commercial actually requires far more planning than putting together a 2-hour sales pitch.

This chapter provides a quick introduction to project planning. You'll see what goes into a project plan. You'll also learn how to create a document for stakeholders to approve before you begin executing the project, along with tips and tricks for getting the information you need.

Project planning is like other types of planning—you figure out what you're going to do before you do it. And like other types of plans, project plans are destined to change, because the projects they guide never occur exactly as the plan predicts. The inevitability of change shouldn't scare you off planning. What you learn during the process of planning helps you keep a project on course, even when changes occur.

Project planning involves two main elements:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Project Planning in a Nutshell

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Project planning is like other types of planning—you figure out what you're going to do before you do it. And like other types of plans, project plans are destined to change, because the projects they guide never occur exactly as the plan predicts. The inevitability of change shouldn't scare you off planning. What you learn during the process of planning helps you keep a project on course, even when changes occur.

Project planning involves two main elements: why you're doing the project, and how you're going to do it. You begin by identifying what the project is supposed to accomplish. Only then can you start planning how to achieve the project's goals.

Veteran project managers have official names for each part of a project plan, but any plan boils down to a series of questions. The rest of this chapter describes the components of a project plan in more detail, but here are the basics:

• Why are we going to perform this project? The answer to this question describes the point of the project. Project plans present this information in two forms. First, you identify the real problem that the project is supposed to solve, which you describe in the problem statement (). The project mission statement states the importance and purpose of the project in a short but compelling sound bite, perfect for keeping people inspired and focused.
• What are we going to achieve? By definition, a project eventually ends. You must know what the project is supposed to achieve, so you can tell when it's done. The first step is to spell out all the goals, or project objectives (). Projects usually have several goals, which can fall into different categories. A media campaign may have a business objective to increase a product's market share, a financial objective to stay within budget, and a performance objective to finish in time for the crucial summer sales season.
  The project plan document states these achievements in a few other forms, each of which plays a specific role. The project scope statement () lists what is and isn't part of the project. It delineates the boundaries of a project so stakeholders know what to expect. The scope statement also helps you rein in pressures to expand the project (

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Defining the Project

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

As Yogi Berra once said, "You've got to be very careful if you don't know where you're going, because you might not get there." Projects usually get the go-ahead for good reasons, but the motivation for a project may be barely sketched out when the project begins. Before you can work out the details of how you'll perform the project, you must identify what the project is supposed to achieve.

Dr. Joseph M. Juran's definition of a project is a problem scheduled for solution, so identifying the problem to solve is usually the first step. A project mission presents the problem in a way that makes people care. Because most problems have more than one possible solution, the project strategy outlines the solution you've picked. From there, you identify all the goals for the project, the results it will deliver, and the assumptions you've made in preparing the plan.

When you start to identify the problem to solve, your colleagues turn into hypochondriacs, overwhelmed with symptoms and making wild guesses at the underlying problem. Just like antibiotics don't help when you have a virus, the right solution to the wrong problem is still wrong. As project manager, your job is to tease out the real problem from the project sponsor, customer, and other stakeholders.

Most people offer solutions instead of describing the actual problem. For example, suppose your CEO says the problem is that the company doesn't have a TV commercial. You could start planning to make a TV commercial, but does that project have a point? To get to the problem, start asking "Why?" For example, why do we need a TV commercial? If the CEO says that sales are in the toilet or the competition is eating your lunch, a TV commercial may not be the best answer. Asking why a few more times may uncover that product quality is abominable or product features are behind the times—and no amount of TV advertising corrects those problems. On the other hand, if the CEO's ego needs stroking, a TV commercial could be the perfect, albeit expensive, solution.

In a project plan, a problem statement outlines the problem to solve. It describes briefly the problem to solve or the business objective to achieve—not symptoms or a solution. Here's an example of the right way and wrong way to state the problem.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Documenting How You'll Run the Project

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Scheduling and budgeting a project takes a lot of time and effort, but the results of that work take up little space in the project plan. You don't have to document all the planning that goes into building a schedule and budget, just the end results. This section gives you an overview of project documentation. Several other chapters in this book explain in detail how to develop the work breakdown structure, the project team, the schedule, and the budget.

Here's a quick introduction to the sections of a project plan that make up the project implementation plan, which maps out how you plan to perform the project:

• Identifying the work to do. A work breakdown structure or WBS () breaks up work into small tasks, which you then put into sequence and assign resources to when you build your schedule. The lowest-level tasks are called work packages, because they contain the work that people must perform. All the higher-level tasks merely summarize groups of lower-level tasks. focuses on building a work breakdown structure and getting it into Microsoft Project.
• Laying out the project schedule. With the WBS complete, you can estimate the effort and duration for each project task, and then put them into the sequence in which they must occur. The result is a schedule that approximates how long the project will take and when tasks should start and finish. talks about estimating task effort and duration; explains how to turn a WBS into a schedule.
  As you manage the project, the project schedule tells you how far you've come and whether the project is still on track to finish on time. In Project, you can compare your original schedule with what's actually happening () to see where you may have to make adjustments.
• Building a project team. You can estimate work hours and duration all you want, but you won't really know what the schedule looks like until you know how many resources work on tasks, and when those resources are available. Building a project team begins with identifying the skill sets you need for tasks and other resources such as equipment and materials. You can assign these generic resources to tasks to get an idea of the schedule. But, when you finally know who's working on your project, you can replace the generic resources with people's names, and finally identify when tasks start and finish. explains how to put a project team together, and add the team to your Project file; shows how you assign resources to tasks.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Laying Out Project Processes

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

As you manage a project, some activities keep running for as long as the project does. For example, you must remain vigilant to changes that people ask for, and run them through a change management process to prevent scope creep. A change management process includes steps for requesting changes, steps for deciding whether to include changes in the project, and steps for tracking the changes. Simi-larly, risk management, communication, and quality management run until the project is complete. Defining these processes must occur while you're still planning the project, or your team will mill about like sheep without a border collie. This section introduces the four processes you define and document in the project plan.

How you approach change management, risk management, and other processes depends on your project. Small projects can survive with relatively informal procedures, whereas large global projects require more rigor. Moreover, corporate culture has an effect on how team members view the processes you define.

As a project manager, you already know that most of your job is communicating with other people in some way. But everyone else working on a project communicates, too. A communication plan describes the rules for sharing information on a project, for example, whether people email status, post it on a Web site, or scratch it into banana leaves. talks about ways to communicate, but you can document the options you choose in the communication plan section of the project plan. A communication plan answers the following questions:

• Who needs to know? For instance, who should receive the list of pending change requests?
• What do they need to know? The change control board may receive the full documentation of change requests, whereas a team leader receives only the associated work tasks, and when the work is due.
• When do they need to know it? Do status reports come out every week, every other week, or once a month; and do they come out on Friday or a different weekday?
• How should they receive it? The methods for distributing information depends on what your organization has available, as well as how people like to communicate. Some organizations place more weight on paper documents, while others prefer the convenience of email or collaboration Web sites.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter 3: Taking Microsoft Project for a Test Drive

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Learning how to manage projects while learning to use Project at the same time is too much for most mortals. So this chapter lets you take Project out for a test drive, with no trip planning whatsoever. If this were a real project, you'd start by defining project objectives, listing assumptions, choosing strategies, identifying risks, building project teams, carving out budgets, and so on, as described in the first two chapters.

Using a fictitious project called the "It's About Time Graduation Party" for the 40-year-old college graduate in your family, this chapter takes you through Project's main features and gives you the satisfaction of creating a working schedule.

Building a project schedule might seem as intimidating and interminable as constructing the Great Wall of China. But if you build your schedule stone by stone (or task by task), you'll be done before you know it.

If you're already a Project maven, you may have a favorite approach to building a schedule. In that case, consider following this test drive anyway—you may just learn some new Project tips and tricks.

For just about any kind of project, you can start constructing a schedule by asking yourself the following questions:

• What work must be done to achieve the project's objectives?
• What tangible results must your project produce—and when?
• How does each task depend upon the completion of other tasks?
• Who's going to do the work?
• How long do they have to get it done?

The first two chapters of this book talk about how to ask and answer these questions as you build a plan for your project. Then, you'll use the answers to these questions as you wend your way through the process of creating a schedule in Project.

The foundation for any schedule is the work that will achieve the project's objectives and deliver the desired results. Before you can do anything else, you need a list of the tasks to perform from beginning the project to sweeping up the confetti at the end. This section describes how to build a list of individual tasks.

If you're not ready to jump in and create a schedule on your own, you can download the sample project (GraduationParty_CompleteProject.mpp) from

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Creating a Project Schedule

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Building a project schedule might seem as intimidating and interminable as constructing the Great Wall of China. But if you build your schedule stone by stone (or task by task), you'll be done before you know it.

If you're already a Project maven, you may have a favorite approach to building a schedule. In that case, consider following this test drive anyway—you may just learn some new Project tips and tricks.

For just about any kind of project, you can start constructing a schedule by asking yourself the following questions:

• What work must be done to achieve the project's objectives?
• What tangible results must your project produce—and when?
• How does each task depend upon the completion of other tasks?
• Who's going to do the work?
• How long do they have to get it done?

The first two chapters of this book talk about how to ask and answer these questions as you build a plan for your project. Then, you'll use the answers to these questions as you wend your way through the process of creating a schedule in Project.

The foundation for any schedule is the work that will achieve the project's objectives and deliver the desired results. Before you can do anything else, you need a list of the tasks to perform from beginning the project to sweeping up the confetti at the end. This section describes how to build a list of individual tasks.

If you're not ready to jump in and create a schedule on your own, you can download the sample project (GraduationParty_CompleteProject.mpp) from www.missingmanuals.com/cds and follow along. As you follow along in the chapter, you can add new tasks to this schedule and modify its tasks and resources.

Section 3.1.1.1: Listing project tasks

In this test drive, you'll create the steps for part of the project schedule—preparing the food and drinks for the party. For extra practice, you can try filling out the rest of the schedule on your own.

1. Start Project by choosing Start → All Programs → Microsoft Office → Microsoft Office Project 2007.
   Project opens a blank project, as shown in .
   

   Figure 3-1: When you first start a blank project, the Project Guide (on the screen's left side) squirms with enthusiasm to help you schedule that blank project. In the upper-right corner, click the Close (X) button to get the Project Guide out of your way; it will reopen the next time you open Project. To permanently hide the Project Guide, choose Tools → Options, and then select the Interface tab. Turn off the Display Project Guide checkbox.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Saving Your Project

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Now, save your hard work so you can come back to it later. You must save Project files, just like any document or spreadsheet.

1. Choose File → Save.
   The Save As dialog box appears. If you've saved the project file before, then the Save dialog box appears.
2. In the File name field, type a name, and then click Save.
   Project saves the file in the location you specified.

As you work on your project, remember to save early and save often. Pressing Ctrl+S to save a Project file is so fast, you can make it a habit in no time. explains other ways to save projects ().

Congratulations! You've created your first project.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter 4: Breaking Work intoTask-Sized Chunks

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

When you organize a simple activity like seeing a movie with friends, you probably don't bother writing out the steps. You just call your friends, pick a movie, get tickets, and buy popcorn without a formal plan. However, for more complex projects—like preparing your income tax return or launching a new product line—identifying the work involved is key to planning how and when to get it done. For example, missing the April 15 deadline can cost you hundreds of dollars in penalties. That new product may make a profit only if you keep costs below $100,000 and get it on the shelves before Thanksgiving. At such times, cost, delivery dates, and other objectives are important.

That's where a WBS (work breakdown structure) comes in. Carving up the project's work into a hierarchy of progressively smaller chunks until you get to bite-sized pieces is the first step to figuring out how and when everything will get done. If you're new to managing projects, don't panic—you've built a WBS before. The movie example in the previous paragraph is actually a simple WBS. The structure of a WBS is much like the system of blood vessels in your body, with the aorta representing the entire project and the smaller blood vessels as progressively smaller chunks of the overall work at each level (summary tasks). The hoards of tiny capillaries that deliver blood to every part of your body correspond to the individual tasks (called work packages) at the bottom of the WBS, which are the smallest chunks of work that you assign to people to complete the project.

In this chapter, you'll learn how to create a WBS that successfully communicates the work within a project. Equally important, you'll learn how to tell when the WBS is broken down enough. The rest of the chapter helps you get your WBS into Microsoft Project, so you can proceed to constructing a project schedule as described in .

The fastest way to create a WBS is to construct it directly in Project, and this chapter shows you several ways to do just that. If you're working alone, you can empty your brain into Project, or you can just as easily transcribe the results of collaborative WBS sessions. You can also build a WBS in Microsoft Word, and import the results into Project (in case you love working in Word, or teams submit individual Word documents for their portions of the project). Finally, you'll also learn how to create documents that describe and support your project's work packages.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Identifying the Work to Be Done

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Knowing the high-level tasks that make up your project is important, but big chunks like Build Bridge, Hire New Staff, and Plan Grand Opening Party don't help when you're trying to estimate costs, line up resources, schedule work, or track progress. You need to get much more specific about the actual work all this is going to take. The point of a WBS is to break down the work into small enough pieces so you can do the following:

• Improve estimates. Smaller tasks are not only less intimidating, they make it much easier to figure out how many people you need to perform each portion of work, how long it'll take, and how much it'll cost.
• Keep the team focused. Because the WBS spells out exactly what's needed to achieve the project's objectives, it acts as a checklist for the work on the project team's plate. And it also gently guides team members away from doing things outside the scope of the project.
• Assign work to resources. When the work is broken down into discrete tasks, it's easier to identify the skills needed to complete the assignment. The project manager can clearly determine who's responsible for what. Also, team members are more likely to understand their individual assignments, which makes them happy, and helps keep the project on track.
  On the other hand, don't go overboard by dissecting work into miniscule assignments. Productivity drops when team members keep switching to new assignments while your temptation to micro-manage increases. (You'll learn how to determine the appropriate size for a work package in the next section.)
• Keep the project on track. Shorter tasks give you frequent checkpoints for tracking costs, effort, and completion dates. Moreover, if tasks have strayed off course, you can take corrective action before things get too far out of hand.
  In the PMI project management methodology, introduced briefly in , a WBS is the result of the scope definition process. The starting point is a scope statement (), in which you define the boundaries of the project—what's within the scope of the project and, just as important, what isn't within the scope. For example, knowing whether the cleaning service you hire takes on teenagers' rooms could be essential to success. For many projects, especially those performed for government agencies, the WBS is a contractually binding document, making the correct inclusion and exclusion of work essential.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Building a WBS in Microsoft Project

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Your WBS may not have started out in Project. A WBS might be scribbled on a whiteboard, scrawled on sticky notes pasted to flip charts, or just rattling around noisily in your head. Regardless of where your ideas are, you can make short work of getting them into Project. Once you get familiar with the techniques for outlining tasks described on the next few pages, you'll develop a rhythm to your data entry. If you already have an outline, you can quickly type it into Project from the top down (see the box on ). Or if work packages are bubbling up in your brain, you can enter them without worrying about the order of the tasks or the overall structure. You can rearrange and add summary tasks and work packages later.

One of the more efficient data entry methods is to start at the top of a WBS and complete each level of tasks before dropping to the next level. Because Project creates a new task at the same outline level as the previous task, this approach keeps indenting and outdenting to a minimum.

For maximum efficiency, when you flesh out a lowest-level summary task, insert as many rows as there are work packages for that summary task, and then type the names of the work packages in the Task Name cells. The following steps show you exactly how to work your way down a WBS one level at a time:

1. Choose File → New to create a new blank project file.
   The Gantt Chart view appears with the Entry table on the left and the Gantt Chart timescale on the right. If the Gantt Chart view doesn't appear, choose View → Gantt Chart or, in the View bar, click Gantt Chart.
2. If the WBS column doesn't appear in the Entry table, right-click the Task Name heading and, from the shortcut menu, choose Insert Column.
   The Column Definition dialog box appears. In the "Field name" drop-down list, choose WBS, as shown in , and then click OK. The new column appears to the left of the Task Name column.
   

   Figure 4-2: In the Column Definition dialog box, in addition to choosing the field to display, you can label the column with a different name, align the text in the column, and specify the column width.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Setting Up Customized WBS Codes

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The WBS codes built into Project are simple outline codes with a number for each level in the outline hierarchy. For instance, a WBS code of 2.1.3 might represent the second phase of the project, the first summary task in that phase, and the third work package for that summary task. If your organization uses customized codes, you can build a tailored numbering system—called a code mask—to specify each level of your WBS code. If you use abbreviations for phases, numbers for summary tasks, and letters for work packages, a customized WBS for the design phase of a project might look like this: Dsn 1.a.

To define a customized WBS code, follow these steps:

1. Choose Project → WBS → Define Code.
   The WBS Code Definition dialog box appears. Although any existing WBS codes show numbers for each level with a period as a separator, the boxes in the WBS Code Definition dialog box are empty until you specify a custom scheme for your WBS codes.
   If you assemble several projects into a single master project (), you can make WBS codes unique for each project, even if they use the same code mask. If you work with multiple projects, set up the code mask for a new project before you get too deep into defining the project tasks. That way you don't have to renumber all your tasks later. In the Project Code Prefix box, type a prefix for the current project. Project inserts the project prefix at the beginning of the WBS codes for the tasks in the project; for instance, PRJ01.1.4.1.
2. In the "Code mask" section, in the first Sequence cell, choose the type of characters you want to use for the top level of the hierarchy, as shown in the top figure of .
   You can choose from Numbers (ordered), Uppercase Letters (ordered), Lowercase Letters (ordered), and, for most flexible coding, Characters (unordered). Ordered numbers and letters mean that Project automatically increments the numbers or letters as you add tasks to the WBS, for example, proceeding from 1.1 to 1.2. to 1.3.
3. In the first Length cell, choose a number (from 1 to 10) for the length of the mask for the top level.
   Project initially selects Any, which means the entry for the level can be of any length. If the level uses a number, Project increments the number beginning at 1 and continuing to 10, 100, or 1000, if necessary. If the level uses letters, then you can type a code of any number of characters at that level.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Documenting a WBS in Another Program

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Everyone has a favorite word processor, but Microsoft Word is a strong favorite for WBS creation because of its outlining feature. Word makes it easy to indent, outdent, insert, move, and delete tasks. Then, with a few additional steps, you can import the Word WBS into Project, as described in the next section. Moreover, more of your team members are likely to be familiar with Word than with Project, so you're likely to get project information from them in Word documents.

Folks who are fans of Word outlining already know that adding and rearranging topics goes as fast as your fingers on the keyboard. If you haven't experienced the joy of Word outlining, here are some techniques you can use:

• Switch to Outline view. In Word 2007, click the View tab, and then, in the Document Views section, click Outline. In Word 2003, choose View → Outline.
• Add tasks. Insert a new line by clicking at the end of the preceding task, and then pressing Enter. Type the task name. Press Enter to add another task.
• Demote tasks. Select the task or tasks you want to push to a lower level, and then press Tab (or Alt+Shift+right arrow key). In Word 2007, click Outlining → Outline Tools → Demote, as shown in . In Word 2003, you can also press Tab or, on the Outlining toolbar, click the Demote arrow.
  In Outline mode, you can select an outline item by clicking to the left of the item. To select several adjacent items, drag to the left of the items. Ctrl+click items to select several nonadjacent items.
  

  Figure 4-9: Microsoft Word's Outline view is a friendly environment for project outlining. To promote an item to the top level, click the "Promote to Heading1" button. Word offers a button for demoting items to Body Text, but it's best to stick to heading levels, since these levels translate into Project outline levels when you import the tasks from Word into Project. (This picture shows Word 2007.)
• Promote tasks. Select the task or tasks you want to promote to a higher level and then press Shift+Tab or Alt+Shift+left arrow key. In Word 2007, click Outlining → Outline Tools → Promote. In Word 2003, press Shift+Tab or, on the Outlining toolbar, click the Promote arrow.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Importing a WBS into Project

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

If you build a list of tasks in Word or, for that matter, Excel, WordPad, or another program that can produce text files, you can easily import tasks into Project. Suppose different teams use Word outlines to document the tasks they plan to perform. They can save their outlines as text files and send them to you. All you have to do is open the text file in Project; the Import Wizard launches to guide you through importing the tasks into a Project file.

Word doesn't save Tab-delimited files out of the box. In addition, ideally you'd like imported tasks to come in at the correct WBS level. If you use Word outlining, the heading styles in the Word document correspond to the WBS level in the Project file.

The Import WBS Word template (created in Word 2003) at www.missingmanuals.com/cds has some handy tools for importing tasks into Project. The heading styles number each task with a WBS code, so you can confirm that the tasks are at the correct level before you import them. In addition, the template includes a macro that creates a text file that separates the task name (the first value) from the outline level (the second value).

To use the macro in the Import WBS template, you must set up your copy of Word to let macros run. Because the steps to enable macros depend on the level of security you use, refer to Word Help or a book about Microsoft Word—like Word 2007: The Missing Manual by Chris Grover—for instructions.

Here are the steps to use the Word template (CH04 WBS Outline.dot) to import a WBS text file into Project:

1. Replace the text in the template with the tasks for your project.
   Use the techniques described on to indent or outdent tasks to the correct WBS level.
2. In the custom WBS toolbar, click "Create WBS for Import".
   You can specify the number of levels that you want to export, for example, if you plan to import the first several levels into a master project. When you click OK, then Word creates a new Word document with the outline levels separated from the task names with commas.
3. Choose File → Save As. Navigate to the folder you want to use, and then make sure to set the "Save as type" box to Plain Text

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Documenting Work Package Details

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

If you've ever asked a teenager to do a chore, you already know the importance of clearly specifying the work to perform and the results you expect. Otherwise, the dishes in the dishwasher might be placed in the cupboards—unfortunately, before they're washed. Providing project team members with clear guidance is equally important, but the task names in Project are too short to get into detail. For that reason, separate documents that describe work packages are a great way to tell team members how to do their assignments completely and correctly. And you don't even have to worry about keeping track of lots of loose documents: You can link them to the Project schedule, as described at the end of this section.

Figure 4-10: As you map the fields, the Preview area shows how the values in your text file map to Project fields. In this example, the Name field will hold the values Planning, Identifying Requirements, Documenting Assumptions, and so on. If the mapping isn't correct, then modify the fields in the To: Microsoft Office Project Field cells until you're satisfied

Ideally, a work package document describes the work to perform, how to tell when the work is done, and how to tell whether it's done right. A work package for baking a loaf of bread might include the steps for mixing, kneading, forming, and baking the bread. The document could specify that the bread is done when tapping the loaf delivers a hollow thump. Similarly, the work package might state that a successful loaf of bread is an attractive brown color, twice as tall as the unbaked dough, and full of evenly sized holes.

Even small projects require dozens of work package documents. You can speed up your work by creating a Word template for work packages, as basic or as fancy as your knowledge of Word. That way, you can open the template and have a document all labeled and ready for you to fill in. For example, you might set up a basic work package template with the following information:

• WBS number. The WBS number that Project assigned to the task in your Project schedule.
• Work package name

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter 5: Estimating Work Time

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Once you've identified the tasks that comprise a project, the next step is figuring out how many hours or days of work those tasks entail—and the duration to allow for that work. For example, you need to know how long it takes to repair and paint the front of a '67 Mustang Fastback to figure out whether you can hide the evidence before your parents get home from vacation.

You'll never predict project performance with total accuracy. However, estimating work time and duration as closely as you can is the goal, because high or low estimates can both cause problems. Overestimate how long your project will take, and the project might get squelched before it begins. Yet underestimating leads to disappointment, extensions, and financial consequences.

In this chapter, you'll learn about different ways to estimate time and duration, how to improve estimates, and how to avoid estimating landmines. You'll also learn how to create spreadsheets for collecting estimated numbers from team members, and then import the numbers into Microsoft Project.

In Project, work and duration are both ways of measuring project time, but each term has a specific meaning:

Work. The number of person-hours (or equipment-hours) a task requires. For example, packing all your belongings may take you (that is, one person) 20 hours. (Hey, you have a lot of sentimental keepsakes.)

Duration. How long a task lasts. Duration varies according to how many resources (people or equipment) you use, and when those resources are available. You may need 5 days for the 20-hour packing task, because you have other moving tasks to do, and can't spend more than 4 hours each day on packing. If you convince two other friends to help, the duration decreases to 1 day, but the three of you still devote 20 hours of work to boxing up gewgaws.

Whether you estimate work, duration, or both depends on whether you know how many people are available to work on tasks. If only one person performs a task, the number of hours of work initially equals the hours of duration. Up to a point, you can shorten task duration by adding additional resources, as in the packing example above. Start by estimating work. If you don't know how many resources are available, you can use the work estimate as the duration estimate. However, if you have resources in mind, you can estimate a duration that differs from hours of work. Either way, when you assign resources, Project adjusts the task work and duration accordingly ().

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Understanding Work and Duration

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In Project, work and duration are both ways of measuring project time, but each term has a specific meaning:

Work. The number of person-hours (or equipment-hours) a task requires. For example, packing all your belongings may take you (that is, one person) 20 hours. (Hey, you have a lot of sentimental keepsakes.)

Duration. How long a task lasts. Duration varies according to how many resources (people or equipment) you use, and when those resources are available. You may need 5 days for the 20-hour packing task, because you have other moving tasks to do, and can't spend more than 4 hours each day on packing. If you convince two other friends to help, the duration decreases to 1 day, but the three of you still devote 20 hours of work to boxing up gewgaws.

Whether you estimate work, duration, or both depends on whether you know how many people are available to work on tasks. If only one person performs a task, the number of hours of work initially equals the hours of duration. Up to a point, you can shorten task duration by adding additional resources, as in the packing example above. Start by estimating work. If you don't know how many resources are available, you can use the work estimate as the duration estimate. However, if you have resources in mind, you can estimate a duration that differs from hours of work. Either way, when you assign resources, Project adjusts the task work and duration accordingly ().

After you estimate work and task duration, you're ready for the chapters on building a schedule (), assigning resources (), and estimating nonlabor costs ().

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Getting Good Estimates

Content preview·