The Four Phases of Project Management - PM 360 Consulting
17445
post-template-default,single,single-post,postid-17445,single-format-standard,wp-custom-logo,theme-bridge,woocommerce-no-js,ajax_fade,page_not_loaded,,qode-content-sidebar-responsive,columns-4,qode-theme-ver-11.0,qode-theme-bridge,wpb-js-composer js-comp-ver-5.1.1,vc_responsive

The Four Phases of Project Management

The Four Phases of Project Management

The Four Phases of Project Management

Whether you’re in charge of developing a website, designing a car, moving a department to a new facility, updating an information system, or just about any other project (large or small), you’ll go through the same four phases of project management: planning, build-up, implementation, and closeout. Even though the phases have distinct qualities, they overlap.

For example, you’ll typically begin planning with a ballpark budget figure and an estimated completion date. Once you’re in the build-up and implementation phases, you’ll define and begin to execute the details of the project plan. That will give you new information, so you’ll revise your budget and end date—in other words, do more planning—according to your clearer understanding of the big picture.

Here’s an overview of each phase and the activities involved.

Planning: How to Map Out a Project

When people think of project planning, their minds tend to jump immediately to scheduling—but you won’t even get to that part until the build-up phase. Planning is really about defining fundamentals: what problem needs solving, who will be involved, and what will be done.

Determine the real problem to solve

Before you begin, take time to pinpoint what issue the project is actually supposed to fi x. It’s not always obvious. Say the CIO at your company has asked you, an IT manager, to develop a new database and data entry system. You may be eager to jump right into the project to tackle problems you have struggled with firsthand.But will that solve the company’s problem? To increase the project’s chances of success, you must look beyond the symptoms you have observed—“We can’t get the data out fast enough” and “I have to sift through four different reports just to compile an update on my clients’ recent activity”—to find the underlying issues the organization is trying to address. Before designing the database, you should ask what type of data is required, what will be done with it, how soon a fix is needed, and so on. If you don’t, you’ll run the risk of wasting time and money by creating a solution that is too simplistic, too complicated, or too late—or one that doesn’t do what users need it to do.

Identify the stakeholders

The real problem will become even clearer once you figure out who all your stakeholders are—that is, which functions or people might be affected by the project’s activities or outcomes, who will contribute resources (people, space, time, tools, and money), and who will use and benefit from the project’s output. They will work with you to spell out exactly what success on the project means. Have them sign off on what they expect at the end of the project and what they are willing to contribute to it. And if the stakeholders change midstream, be prepared not only to respond to the new players but also to include all the others in any decision to redirect the project.

Define project objectives

One of your most challenging planning tasks is to meld stakeholders’ various expectations into a coherent and manageable set of goals. The project’s success will be measured by how well you meet those goals. The more explicitly you state them at the outset, the less disagreement you will face later about whether you have met expectations.

In the planning phase, however, much is still in flux, so you’ll revise your objectives later on, as you gather information about what you need to achieve.

Determine scope, resources, and major tasks

Many projects fail either because they bite off more than they can chew and thus grossly underestimate time and money or because a significant part of the work has been overlooked. One tool that can help you avoid these problems is the Work Breakdown Structure (WBS), which aids in the process of determining scope and tasks and developing estimates.

The underlying concept is to subdivide complex activities into their most manageable units. To create a WBS:

  • Ask, “What will have to be done in order to accomplish X?”
  • Continue to ask this question until your answer is broken down into tasks that cannot be subdivided further.
  • Estimate how long it will take to complete these tasks and how much they will cost in terms of dollars and person-hours.

As a result of your thoughtful planning, you’ll be able to rough out an estimate of how many people—with what skills—you’ll need for the project. You’ll also have a good idea of how long the project will take.

Prepare for trade-offs
Time, cost, and quality are the three related variables that typically dictate what you can achieve.

Quality = Time + Cost

Change any of these variables, and you change your outcome. Of course, such alterations often occur in the middle of a project. If your time frame for developing a new database management system is suddenly cut in half, for instance, you will need to either employ twice the number of people or be satisfied with a system that isn’t as robust as originally planned. Don’t let bells and whistles get in the way of mission-critical activities. The key is to establish a level of quality that meets your stakeholders’ needs.

Knowing from the start which variable is most important to each stakeholder will help you make the right changes along the way. It’s your responsibility to keep every one informed of any tweaks and tell them what the consequences will be in terms of time, cost, and quality.

Build-Up: How to Get the Project Going

In the build-up phase, you bring your team together. Time estimates become schedules. Cost estimates become budgets. You gather your resources. You get commitments, and you make them.

Assemble your team

Your first task in this phase is to assess the skills needed for the project so you can get the right people on board. This assessment flows directly from the Work Breakdown Structure you did during the planning phase, in which you developed your best estimate of the necessary tasks and activities. You may need to bring in people— either temporary workers or employees from other parts of the organization—who have certain skills. Don’t forget to budget time and money for training to cover any gaps you can’t fill with people who are already up to speed.

Plan assignments

If you’ve built your own team, you’ve probably already decided who will do what. Or, if you’ve inherited a team but worked with the members before, you can still make the assignments yourself. But if a new, unfamiliar group is assigned to you, list the people on the team, list the skills required, and talk to each team member about her own skill set before you match people to tasks. This approach starts the process of team communication and cohesion.

Create the schedule

It would be nice if you could tally up the to-dos and say, “With the resources we have, we will need this much time”—and then get exactly what you’ve asked for. But the reality is, most projects come with fixed beginning and end dates, regardless of available resources.

To create a realistic schedule within those constraints, work backward from any drop-dead deadlines you know about—that is, dates that cannot be changed—to see when your deliverables must be ready. For instance, if an annual report is due for a shareholder’s meeting and you know it takes the printer two weeks, then all the final art and copy for the report must be ready to go to the printer two weeks before the meeting.

Hold a kickoff meeting

As soon as you’ve chosen your players and set the schedule, bring everyone together for a kickoff meeting. Go over the project’s plan and objectives with the group in as much detail as possible, and review the proposed time frame. Be sure to clarify roles and responsibilities. Encourage people to point out spots where problems may occur and where improvements could be made. Take all suggestions seriously—especially in areas where the team members have more experience than you do—and adjust your estimates and activities accordingly.

Develop a budget

The first question to ask when developing a budget is, “What will it take to actually do the work?” To determine your costs, break down the project into the following categories: personnel, travel, training, supplies, space, research, capital expenditures, and overhead.

After you’ve entered the figures from these standard categories into the budget, ask a trusted adviser what you forgot. Did you overlook insurance? Licensing fees? Costs for legal or accounting support?

A budget, no matter how carefully planned, is just your best guess. Expect actual numbers to deviate from original estimates, and stay as flexible as possible within your limitations of time, quality demands, and total money available.

Implementation: How to Execute the Project

It’s time to put the plan into action. The implementation phase is often the most gratifying, because work actually gets done, but it can also be the most frustrating. The details can be tedious and, at times, overwhelming.

Monitor and control process and budget

Whether you have a formal project control system in place or you do your own regular check-ups, try to maintain a big-picture perspective so that you don’t become engulfed by details and petty problems. Project-monitoring software systems can help you measure your progress.

No single approach works for all projects. A system that’s right for a large project can easily swamp a small one with paperwork, whereas a system that works for small projects won’t have enough muscle for a big one.

Respond quickly to changes in data or information as they come in, and look for early signs of problems so you can initiate corrective action. Otherwise, all you are doing is monitoring, not exercising control. Make it clear to your team that your responses to problems that arise won’t do any good if you don’t receive timely information. (But don’t jump in to fix things too quickly—allow your team members to work out small problems on their own.

Watch the real numbers as they roll in to ensure that they are matching the budgeted amounts. Be ready to explain why extra costs are unavoidable. Common ones that sneak up on projects include increased overtime to keep things on schedule, consultant fees to resolve unforeseen problems, and fluctuations in currency exchange rates.

Report progress

Stakeholders will generally want regular updates and status reports. Consult with them to see how much information they’d like and in what format. Don’t hide or downplay problems as they come up, or you can easily transform them into crises. If you keep your stakeholders informed, they may turn out to be good resources when issues do arise.

Hold weekly team meetings

When you’re immersed in project details, it’s easy to be diverted from critical activities to side paths that waste time. You and your team can stay focused by meeting once a week and periodically asking yourselves what’s essential to the project’s success.

Set clear agendas for your meetings. Try structuring them around production numbers, revenue goals, or whatever other metrics you’ve chosen to gauge performance. Many of your agenda items will naturally stem from targets the project has missed, met, or exceeded: For instance, you may need to discuss as a group whether to incorporate more travel into the project because you’ve noticed a decline in productivity at a satellite office. Or you might ask the product designers on your team to continue gathering among themselves on a biweekly basis because they’ve doubled their creative output since they’ve begun doing so.Keep the momentum going by following up each week on any to-dos and connecting them with the metrics for overall performance. Also, celebrate small successes along the way—that will rekindle the team’s enthusiasm as you make progress toward your larger objectives.

Manage problems

Some problems have such far-reaching consequences that they can threaten the success of the entire project. The most common are: time slippage, scope creep, quality issues, and people problems.

Pay attention to small signs of emerging problems, such as a team member’s increased tension and irritability, loss of enthusiasm, or inability to make decisions. When you see signs like these, get to the heart of the problem quickly and deal with it. Don’t let it grow from a small irritant into a disaster.

Closeout: How to Handle End Matters

Though some projects feel endless, they all, eventually, come to a close. How do you, as project manager, know when to make that happen? And how do you go about it?

Evaluate project performance

Before closing out your project, your team needs to meet its goals (or determine, along with key stakeholders, that those goals no longer apply). Compare your progress with the scope everyone agreed on at the beginning. That will tell you how well the project has performed—and if there’s still work to do. When you discuss your findings with your stakeholders, make sure you reach consensus with them on how “finished” the project is. Keep your scope front and center so everyone uses the same yardstick to measure success.

Close the project

The steps you take to wrap things up will depend on whether your team assumes ownership of its own deliverables, hands them off to others in the organization, or must terminate the project altogether.

If all has gone as planned with your project, then it’s time for celebration. Even if, as is more likely, there are some rough spots along the way—the project takes longer than expected, the result is less than hoped for, or the costs overtake your estimates—it’s still important to recognize the team’s efforts and accomplishments.

Debrief with the team

No matter what the outcome, make sure you have scheduled a post-evaluation—time to debrief and document the process so that the full benefits of lessons learned can be shared. The post-evaluation is an opportunity for discovery, not for criticism and blame. Team members who fear they’ll be punished for past problems may try to hide them rather than help find better ways of handling them in the future.

 

HBR Editiors November 3rd 2016

Adapted from HBR Guide to Project Management; content originally published in Pocket Mentor: Managing Projects, Harvard Business Review Press, 2006.