Chapter 1. Projects: In the Beginning
Microsoft Project 2013 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.
A project is different from day-to-day work, and this chapter explains how. 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 by covering the one skill that no project manager can afford to ignore: gaining and maintaining the support of stakeholders—the folks who care about the project’s success. You’ll learn how to identify stakeholders and their expectations, and how to keep them on board so they’re ready and willing to pitch in when the project needs their help.
What’s So Special About Projects?
Projects come in all shapes and sizes, from a child’s birthday party to the inauguration of a new president of the United States. What’s the common thread that unites all projects and makes them different from other kinds of work? Here’s one definition: A project is a unique endeavor with clear-cut objectives, a starting point, an ending point, and (usually) a budget. Here’s a breakdown of the definition’s main points:
Unique is the most important word in that definition, because every project is different in some way. Charity bike rides in different cities, over different routes, during different weather conditions, and organized by different teams constitute different projects. The event’s venue, site conditions, weather, and team members make every event unique, even if they have the same basic structure. In contrast, a crew that makes fundraising phone calls or mails requests for donations performs the same work every day; this kind of work is typically called operations.
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. “Train the cat” isn’t a good objective. It doesn’t specify what you’re trying to train the cat to do—or not do. (In this case, the objective may not even be feasible.) On the other hand, an objective that you can complete (albeit with some physical risk) is “Remove the cat from the Thanksgiving turkey carcass.” For a fundraiser, you might have objectives like raising a million dollars and retaining a specific percentage of the top fundraisers.
A project begins at one point in time and ends when it achieves its objectives (although some projects seem interminable). When the cleanup crew hauls off the last of the trash and the money raised is put to work, the fundraising project team is ready to move on to the next project. However, if the end of the project always seems just out of reach, poorly defined objectives are usually to blame. You’ll learn how to define objectives in Chapter 2.
Budgets play a role in most projects, because few people consider money irrelevant. In addition to achieving the objectives within the desired timeframe, you also have to keep the price tag within an acceptable range. For example, donors want to know that their money is earmarked for good works, not consumed by excessive administration. So the fundraiser’s budget might be set to 10 percent of the fundraising goal. In addition, time may be as important as money for some projects, so you might budget time as well.
Dr. Joseph M. Juran, best known for his work on quality management, was the impetus for today’s Six Sigma process-improvement methodology; he described a project as a problem scheduled for solution. The concept is the same as the definition described in the preceding list: Working with stakeholders to identify and agree upon the problem that needs solving helps identify the project’s objectives. When you schedule the problem for solution, you determine the project’s start and end dates.
What Is Project Management?
Project management is the art of balancing project objectives against the constraints of time, budget, resource availability, and quality. 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 “right” way to manage projects (the box on Picking a Project-Management Methodology identifies a few different project-management methodologies), but most methodologies cover the following five phases (illustrated in Figure 1-1):
Getting started. Often called initiating, this 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 “Hold an event to raise money.” But as you identify the stakeholders (Identify Who Has a Stake in the Project), you learn what the project is about and what the stakeholders hope to achieve. The more specific you are when you describe a project’s objectives, the greater your chances for success.
Neglecting to line up support for a project (Gaining Support for a Project) is all too common, and it’s always a big mistake. A project needs buy-in from an executive sponsor (Identify Who Has a Stake in the Project) and the stakeholders to survive challenges like contradictory objectives, resource shortages, funding issues, and so on. What’s more, you, the project manager, need official support, too, so everyone knows the extent of your authority.
Planning. This phase, which Chapter 2 covers in greater detail, is where you draw your road map: the objectives to achieve; the work to perform; who’s going to do that work, when; and how much the whole thing will cost. Moreover, you set out the rules of the game, including how people will communicate with one another, who has to approve what, how you’ll manage changes and risks, and so on.
Performing the project. Also referred to as executing, this part of project management lasts a long time, but it boils down to following the plan. As the project manager, your job is to keep the project team working on the right things at the right times.
Keeping things under control. In a perfect world, performing the project would be enough, because things would always run according to plan. But because the world isn’t perfect, project managers have to monitor projects to see whether they’re on schedule, within budget, and achieving their objectives. Whether someone gets sick, a storm washes out a bike path on the ride route, or your data center is plagued with locusts, something is bound to push your project off course. In the controlling phase, you measure project performance against the plan, decide what to do if the project is off track, make the necessary adjustments, and then measure again. Chapter 14 explains how to use Project 2013 to control things.
Gaining closure. Like personal relationships, projects need closure. Before you can call a project complete, you have to tie up loose ends like closing out contracts, transitioning resources to their new assignments, and documenting the overall project performance (Printing Views to Report Project Information). The closing phase is when you ask for official acceptance that the project is complete—your sign that your job is done. Chapter 17 describes the information to collect in this phase and different ways to archive a project.
Why Manage Projects?
The five phases of an unmanaged project go something like this: 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, resource, and dollar—and still doesn’t deliver what it’s supposed to. Despite all that, many organizations fear that project management requires bureaucratic and inflexible procedures and will make projects take longer. On the contrary, planning projects and managing the plan provides many benefits, including the following:
Happy customers. Whether a project is for outside customers or groups within your organization, customers like to get what they want when they want it. Because the first step in project management is finding out what your customers and stakeholders want to accomplish with the project, your customers are more likely to get the results they expect. And by keeping the project under control, you’re also more likely to deliver those results on time and at the right price.
Achieved objectives. Without a plan, projects tend to cultivate their own agendas, and people tend to forget the point of their work. A project plan ties a project to specific objectives, so everyone stays focused on those goals. Documented objectives also help you rein in the renegades who try to expand the scope of the project.
Timely completion. Finishing a project on time is important for more than just morale. As work goes on for a longer duration, costs increase and budgets get blown to bits. In addition, you may lose the resources you need or prevent other projects from starting. Sometimes, on-time completion is one of your objectives, like when you’re trying to get a product to market before the competition.
Flexibility. Contrary to many people’s beliefs, project management makes teams more flexible. Project management doesn’t prevent every problem, but it makes the problems that occur easier to resolve. When something goes wrong, you can evaluate your plan to quickly develop alternatives—now that’s flexibility! More importantly, keeping track of progress means you learn about bad news when you still have time to recover.
Better financial performance. Most executives are obsessed with financial performance, so many projects have financial objectives—increasing income, lowering costs, reducing expensive recalls, and so on. Project management is an executive-pleaser because it can produce more satisfying financial results.
Happier, more productive workers. Skilled workers are hard to come by and usually cost a bundle. People get more done when they can work without drama, stress, and painfully long hours. Moreover, they don’t abandon ship, so you spend less on recruiting and training replacements.
Picking the Right Projects
There’s never a shortage of projects, but there’s not enough time, money, and staff in the world to complete them all. Before you begin managing a project, make sure it earns its place in your organization’s 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 under way, because projects don’t always deliver what they promise. If a project isn’t meeting expectations, the management team 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. (The box below provides an example of how a committee might evaluate and select projects.) You can then 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 projects that meet your selection criteria on the waiting list.
The Importance of Business Objectives
Some projects are no-brainers, like the ones needed to satisfy government regulations. For example, American 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 from your list by picking only 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. But in the healthcare industry, safety trumps speed, because recalling devices already implanted in people is going to hurt the patients and the company’s 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. Here are some common objectives that trigger projects:
Increase market share
Reduce prices to stay competitive
Reduce time to market
Increase customer satisfaction
Increase product quality and/or safety
Common Selection Criteria
Although some projects get a free pass due to regulatory requirements or because the CEO says so, most have to earn their spot in the project lineup. Because business objectives vary, you need some sort of common denominator for measuring results—which often comes down to money. This section describes the most common financial measures that executives use, and the pros and cons of each. (The box on Surviving Without Selection Criteria explains what you can do if your organization doesn’t have selection criteria.)
Whether you’re trying to increase revenue, reduce costs, or improve product quality, you can usually present a project’s benefits in dollars. The winner is the project that makes the most of the money spent on it. Of course, to calculate financial results, you need numbers; and to get numbers, you have to do some prep work and estimating (Estimating Task Work and Duration). You don’t need a full-blown project plan (Project Planning in a Nutshell) to propose a project, but you do need a rough idea of the project’s potential benefits and costs. That’s why many organizations start with feasibility studies—small efforts specifically for determining whether the project delivers the financial benefits described in the following sections and, therefore, makes sense to pursue.
If some business objectives are way more important than others, you may want to evaluate the projects that support those key objectives first. Then, if you have money and resources left over, you can look at projects in other areas of the business. Risk is another consideration in selecting projects. Suppose a project has mouthwatering financial prospects and heart-stopping risks. Project proposals should include a high-level analysis of risks (Identifying Risks) so the selection committee can make informed decisions.
Payback period is the time a project takes to earn back what it cost. Consider a project that reduces warranty repairs by $10,000 each month and costs $200,000 to implement. The payback period is the cost of the project divided by the money earned or saved each month:
Payback period = $200,000 / $10,000 per month = 20 months
Payback period has simplicity on its side: The data you need is relatively easy to obtain, and even non-financial types can follow the math. But if you get really finicky about it, payback period has several limitations:
It assumes enough earnings to pay back the cost. If your company stops selling the product that the warranty-repair project supports, the monthly savings may not continue for the calculated payback period, which ends up costing money.
It ignores cash flows after the payback period ends. When you compare projects based on their payback periods, projects that generate money early beat out projects that generate more money over a longer period. Consider two projects that each cost $100,000 to complete. Project #1 saves $20,000 each month for 5 months. Project #2 saves $10,000 each month for 24 months. Project #1’s payback period is 5 months compared to Project #2’s 10 months. However, Project #2 saves $240,000, whereas Project #1 saves only $100,000.
It ignores the time value of money. There’s a price to pay for using money over a period of time. Payback period doesn’t account for the time value of money, because it uses the project cost as a lump sum, regardless of how long the project takes and when you spend the money. The measures explained in the next sections are more accurate when a project spends and receives money over time.
Net Present Value
Net present value (NPV) takes the time value of money into account, so it provides a more accurate picture of financial performance than payback period does. The time value of money is the idea that money isn’t always worth the same amount—money you earn in the future isn’t as valuable as money you earn today. For example, the value of your salary goes down as inflation reduces what each dollar of your paycheck can buy each year. The time value of money is a factor in the NPV measure because you pay a price for using money, like the interest you pay on a home mortgage. The longer you borrow money, the more interest you pay. If you pay for a project with cash on hand, you don’t pay interest. However, organizations want to earn a return on the money they invest, so the project must deliver enough earnings to balance out (or exceed) the price you pay for that money.
NPV starts by combining a project’s income (earnings or savings) and costs into cash flows. (For instance, if you earn $4,000 a month and spend $3,000 on living expenses, then your net cash flow is $1,000.) Then, NPV uses a rate of return to translate the cash flows into a single value in today’s dollars. If NPV is greater than zero, then the project earns more than that rate of return. If NPV is less than zero, then the project’s return is lower. Where does this magical rate of return come from? In most cases, you use the rate of return that your company requires on money it invests. For example, if your company demands a 10 percent return to invest in a project, you use 10 percent in the NPV calculation. If the NPV is greater than zero, then the project passes the company’s investment test. Figure 1-2 shows the NPV of a project that costs $10,000 each month for a year and then earns $15,000 each month for a year after it’s finished.
NPV has two drawbacks. First, it doesn’t tell you the return that the project provides, only whether the project exceeds the rate of return you use. You can compare NPV for several projects and pick the one with the highest value, but executives typically like to see an annual return. One way to overcome this issue is with a profitability index, which is NPV divided by the initial investment. This ratio basically tells you what bang you get for your buck from each project. The higher the profitability index, the better. The second drawback is that NPV is hard to explain to non-financial folks. (Luckily, however, most people whose jobs involve picking projects are well versed in financial measures.)
To avoid frenetic finger work calculating NPV on a handheld calculator, try Microsoft Excel’s XNPV function. You provide the required rate of return, the cash flows the investment delivers, and the dates on which they occur (remember, the value of money changes over time), and Excel does the rest.
If cash flows occur on a regular schedule like once a month, you can use Excel’s NPV function, which doesn’t require dates. This function assumes a regular schedule, and you simply input the rate of return for each time period. If the annual rate is 10 percent and you have monthly cash flows, you enter the rate as 10 percent divided by 12, or 0.833 percent. The NPV function accepts up to 254 values, which is enough for monthly cash flows for more than 10 years.
In an Excel workbook, fill in one cell with the annual rate of return you want to use, and then enter the cash flows and dates in two of the workbook columns, as shown in Figure 1-2.
The dates and cash flows don’t have to be side by side, but you can read the workbook more easily if they are.
Select a blank cell where you want to insert the function (like cell B28 in Figure 1-2), and then click the Formulas tab. On the left side of the ribbon, click Insert Function.
In the “Search for a function” box, type XNPV, and then click Go.
Click OK to insert the function into the cell, and then fill in the boxes for the function’s arguments.
In addition to adding the function to the cell, Excel opens the Function Arguments dialog box, shown in Figure 1-3, which presents the function’s three arguments with hints and feedback.
Click OK to complete the function and close the dialog box.
If you’re an old hand at Excel functions, you can type the entire function into a cell: Select the cell and then type =XNPV(, and Excel shows you the arguments it requires. You can select a cell for the first argument, type a comma, and then select the cells for the next argument.
Internal Rate of Return
A project’s internal rate of return (IRR) tells you the annual return it delivers, taking into account the time value of money. IRR is like the annual percentage yield (APY) you earn on a savings account, which includes the compounded interest you earn during the year. If your project delivers an IRR greater than the return your company requires, you’re golden.
Just like NPV, IRR depends on when cash flows in or out. For example, money you spend up front drags the IRR down more than money you spend later on. Likewise, if a project brings money in early, the IRR is higher than if the income arrives later.
Like payback period and NPV, IRR has its drawbacks. The big one is that it can give the wrong answer in some situations! It works like a charm when you have money going out for a while (negative numbers) and then the rest of the cash flows are money coming in. However, if the series of cash flows switches between positive and negative numbers, several rates of return can produce a zero NPV, so, mathematically, there are several correct answers. If you calculate IRR in Excel, the program stops as soon as it gets an answer. But if you run the function again, you might get a different result.
Another issue arises if you borrow money for your project. In that situation, the first cash flow is positive (money coming in) and the later cash flows are negative (money flowing out to pay project costs). Because of that, you have to switch the way you evaluate IRR: In such situations, you (counterintuitively) want to reject a project if its IRR is greater than your company’s required rate of return and accept a project if its IRR is less than the required rate of return.
Excel’s XIRR function calculates IRR based on cash flows and the dates on which they occur, as shown in Figure 1-4. The steps for inserting the XIRR function into a worksheet are similar to those for XNPV in the previous section. (For the mathematicians in the audience, IRR doesn’t have a formula of its own. The way you calculate IRR by hand is by running the NPV calculation with different rates of return until the answer is zero—that return is the IRR.)
If the XIRR function doesn’t find an answer after 100 tries, it displays the #NUM error in the cell. You also see the #NUM error if your series of cash flows doesn’t include at least one positive and one negative cash flow.
Gaining Support for a Project
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 projects from proposal to the final closeout. During the planning phase, stakeholders help define the project and evaluate the project plan. A few lucky stakeholders then cough up the money to fund the project. During the execution phase, stakeholders help resolve problems and make decisions about changes, risk strategies, and (if necessary) whether to fork over more money. At the end of a project, some of the stakeholders get to declare the project complete so everyone can move on to another project.
Identify Who Has a Stake in the Project
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 project’s outcome. They either give something to your project—like the managers who provide the resources you use—or they want something from it, like the sponsors who support your fundraiser in exchange for publicity. (If your stakeholders aren’t providing the support you expect, read the box on When Stakeholders Aren’t Supportive for ways to get them on board.)
Identifying stakeholders can be tough. Some people don’t realize they’re stakeholders, like the development team that learns about a project when they receive a list of requirements for a new website. Other people pretend to be stakeholders but aren’t, like a department that gets chummy because they see your project as an inexpensive way to get their new database. If you’re not careful, your project can gain extraneous requirements but no additional money.
Here are the main types of stakeholders, tips for identifying them, and some hints on keeping them happy:
Project customers are easy to spot, because they’re the ones with the checkbooks. Pleasing the stakeholders who fund your project is a matter of delivering the results they expect (Identifying Project Results). Stay on top of financial performance (Using Project Cost Reports) so you can explain financial shortfalls and your plan to get back on track. The people who control the pocketbook can be formidable allies if other groups are trying to expand the project.
Because customers foot the bill, they usually have a lot to say about the project’s objectives, requirements, and deliverables. Of course, the person who cuts the check isn’t often the person who defines requirements, but they both represent the project’s customer. (For instance, with a fundraising event, the customer sets the fundraising goal and the event budget, while the event director defines the event’s features.) Customers also approve documents, intermediate results, and the final outcome. Approvals are much easier to come by if you work closely with customers during planning to identify their objectives and what they consider success.
Project sponsors are the folks who want the project to succeed and have the authority to make things happen, like the regional director who’s backing the fundraising project. If you, the project manager, don’t have that kind of authority, you may depend on sponsors to confer some of their authority to you. A sponsor’s role is to support the project manager and the project team to make the project a success. After guiding a project through the selection process, the sponsor’s next task is to sign and distribute a project charter (Publicizing a Project and Its Manager), which publicizes the new project and your authority as the project manager.
A sponsor can help you prioritize objectives, tell you which performance measures are critical, and guide you through the rapids of organizational politics. She can also recommend ways to build commitment or fix problems. Sometimes, project sponsors are also project customers, whether for internal projects or for those that deliver products to external customers.
If you don’t have enough authority to make a crucial call or the project hits serious obstacles, the sponsor can step in. While sponsors want their projects to succeed, they expect you to manage the project. Dropping problems at their doorstep every few minutes won’t win their hearts, but neither will hiding problems until it’s too late. If you need help, don’t be afraid to get your sponsor involved.
Functional managers (also called line managers) run departments like marketing, finance, and IT. They have quotas and performance measures to meet in addition to supervising the resources in their departments. Project resources almost always come from these departments, so you have to learn to work with these folks.
The easiest way to win over functional managers is to let them do their jobs. Don’t tell them who you need (unless you already have a great working relationship). Instead, specify the skills you need and the constraints you face, like cost, availability, or experience. Then, after the managers provide you with resources, do your best to stick to the assignment dates you requested. When schedules slip, notify functional managers quickly so you can work out an alternative.
Team members who do project work are stakeholders, too, because they perform the tasks that make up the project. Other types of stakeholders often do double duty as team members, like when a customer defines requirements.
Keeping team members happy requires a combination of a reasonable workload, meaningful work, and a pleasant work environment. Communication is as important with team members as it is with every other type of stakeholder: Team members want to know how their tasks support the big picture, what their tasks represent, and when they’re scheduled to perform them.
You already know that project managers are stakeholders, because your reputation and livelihood depend on the success of your projects. The project manager is easy to identify when it’s you. How to make yourself happy is something you have to figure out on your own.
End users of the project result are also stakeholders. For example, a project to streamline your organization’s business processes will affect the employees, so you should include a representative from the department or role that’s affected.
If your project’s goal is a new product for your company to sell, it’s too early to assign stakeholder status to the customers who will purchase the product. In this situation, you might include a small group of potential customers to provide feedback on your plan.
The process of building a project plan (Project Planning in a Nutshell) helps you identify stakeholders. For instance, the purpose of the project and who benefits from it tell you who the customer and sponsor are. Project objectives help you identify which groups participate in achieving those objectives. The responsibility matrix (Identifying Project Resources) identifies the groups involved in a project and their level of involvement, so it acts as a checklist of stakeholder groups. Of course, you still have to identify the specific people to work with within those groups. When you start to build your project team, the list of functional managers and team members falls into place.
As projects pick up momentum, their details quickly become too numerous for you to remember them all. Stakeholders are so important to projects that you can’t afford to forget them. As you identify stakeholders during planning, create a stakeholder analysis table. Merely listing names and types of stakeholders in this table isn’t enough. Also include information about people’s roles, which objectives matter most to them, and whom they listen to.
Organization or department. Knowing where a stakeholder works helps you remember the objectives they care about, and helps you decide whether they should participate in different activities. For instance, if your company wants to keep strategy sessions confidential, you don’t want to invite external stakeholders to them.
Contributions. List what the stakeholder does for the project. Contributions you list here are different from the responsibilities you put in a responsibility matrix (Creating a Responsibility Matrix in Excel). In the stakeholder table, you specify the contributions that individuals make to the project in their roles as stakeholders.
Advisors. The people to whom stakeholders listen are great sources for tips on presenting information effectively and deciding which options a stakeholder might prefer.
Publicizing a Project and Its Manager
A project that gets the go-ahead needs publicity just like movies do. You want people to know the project is starting and why it’s vital. 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 its sponsor, not your position in the organization, so people need to know how far your authority goes. The project charter is like a project’s press release—it announces the project itself, as well as your responsibilities and authority as its manager.
A project charter doesn’t impress anyone unless it comes from someone powerful enough to grant you authority, like the project’s sponsor or its 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, too. You may have to tactfully suggest that the project’s customer or sponsor develop and distribute the charter.
You can often get the charter out more quickly by writing it yourself so the sponsor has only to sign and send it.
Here are typical elements of a 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 high-level overview 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 who will manage 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 sure this project is a success.
Project manager’s duties. Summarize the manager’s responsibilities. This brief introduction to the project manager’s tasks can warn people about what the project manager may expect from them—and educate people about the mysterious activities that project managers perform.
Project manager’s authority. Here’s where the sponsor or customer sprinkles authoritative fairy dust on you. Much like a power of attorney, this section tells everyone that the sponsor or customer authorizes you to perform certain activities, like hiring contractors or dipping into the project’s emergency fund.
The official commitment to the project. Don’t forget to include a brief bullet point that confirms in writing that the sponsor or customer supports the project and the project manager.
Now that the introductions are out of the way, it’s time to start planning your project. The next chapter provides an overview of a project plan—all the pieces that go into one and why they’re important. After that, you’ll learn the finer points of using Project 2013 and other programs to build and manage a project schedule.