The Project Planning Phase: How to Plan for the Project

During the planning process you identify the work that must be done, who was going to do it, how long everything will take, when things will happen, and how much it'll cost. You also plan how you’ll run the project, such as how you communicate, manage change and risk and ensure quality.

All of this information goes into documents that together represent the project plan. You use the plan once the project work gets started.

• To direct the people working on your project

• Keep track of how the project is going,

• To correct course if need be

• To communicate with team members and management

Understanding work breakdown structures

After you get approval to start planning your project, the first thing you do is identify the work that has to be done. Work breakdown structure or WBS is a tool you use to divide project work into bite-size pieces, so you can plan, track and manage the project effectively.

Benefits of WBS:

• It is easier to estimate the time and cost for smaller chunks of work.

• It is easier to assign work to team members

• By breaking work into smaller pieces you build checkpoints into your project that allows you to measure progress.

WBS contains two kinds of tasks:

• Summary tasks

Summary tasks are the higher level tasks that summaries project work in some way. It can describe each process of the project.

The number of levels of summary tasks depends on the size of the project. A few levels is probably enough for a small project. With a large complex project you could have many levels of summary task

• Work packages

Work packages are the lowest level tasks that spell out the details of the work that needs to be done.

The work breakdown structure is the key to planning out a project and managing it effectively. Now that we understand what a WBS is and how it structured lets look at how you build one

Building a work breakdown structure

The best way to build a WBS is to start at the top and work your way down. By top, I mean the top level summary tasks. For larger projects you might work as a team to identify the top couple of levels of summary tasks. Then the team can split off into smaller groups to break down the work for the summary tasks. At the end everyone gets back together to review the results and correct any issues.

How to build a WBS:

1. Start by using the scope statement and deliverables to identify the top level summary tasks.

2. Breakdown the work that makes up each of the summary tasks. This is where intermediate deliverables come in handy for identifying lower-level summary tasks and work packages.

The question you might be asking at this point is how much breakdown is enough? One approach is to breakdown project work to match the frequency of your status report. So you have a` measurable progress and completed tasks for every status report. The rule of thumb most project managers use is the shoot for work packages that take between eight and 80 hours to complete. You can use the following test to determine whether you have broken work down to the right level.

• Timing cost are easy to estimate

• Status is easy to measure

• Task durations are shorter than your reporting periods

• The detail is at the level that you can and want to manage

Different parts of the project might require different levels of decomposition. One part of the project might include more work so you break it down to 3 levels. Another part of the project might be simpler; you might need only 2 levels.

Don't worry about the initial organization of the WBS. You could review it later on to see whether you want to rearranged tasks

Defining work packages

Now that you build a WBS, you need to make sure your team understand it. A short name in a WBS typically isn't enough to tell people exactly what they're supposed to do. To make sure your team knows what to do, create work package documents that describe the work identified in the WBS in detail.

The level of detail you include in the work package documents depends on things like, how familiar the work is and perhaps the experience of the person assigned the task. For example, a work package document might include a checklist of things to do, which helps a less experienced person understand their assignment but serves as a reminder for a more experienced individual.

You don't have to include every iota of detail in the work package document if the specifics of the work are described somewhere else. You can refer to the other document that contains the information.

A work package document does more than describe the work. It also identifies how you know the task is complete and whether it was completed correctly. For some tasks, you can include the corresponding deliverable and success criteria in work package document; otherwise write the description of what you will have when the task is complete and what it should look like.

Finally you've probably been figured out that you, the project manager don't know enough about every aspect of the work to produce these detailed descriptions for every task. Turn to the people who helped you build the WBS, Team leaders for the groups that will work on a project or other knowledgeable people to help fill in the details. If you get the details right, your team is more likely to know exactly what to do.

Building a schedule

The WBS identifies the work people have to do to complete a project, but it doesn't tell you how long the work will take or when it can be performed. To do that you need to turn your list of tasks into a schedule.

Here are the steps in building project schedule.

1. Put the tasks into the right sequential order. That is you have to specify which tasks have to finish before other tasks can start, which tasks start to finish at the same time and so on. For example you can load computers with sales presentations until the presentations are complete and working properly. To get tasks into order, you specify the dependencies also called links between tasks in your project. The most common is finished to start but you can choose from several types of dependencies. See related topic: creating dependencies between tasks.

2. You need to estimates time each task will take. The time estimates you put together for each task and the order in which tasks occur help determine how long the entire project will take. Reasonable estimates are key to figuring out when a project can finish. You have to estimate as accurately as you can, because underestimating and over estimating both lead to project problems

3. You need to identify the people on your project team and assigned them to tasks. with the estimated hours and the people assigned to do the work you can calculate the task duration.

4. Take into account other constraints such as deadlines. If your initial schedule doesn't quite do what you want you can tweak it in a number of ways whether you’re trying to shorten the schedule, cut costs or assign available people.

The schedule is one of the most important aspects of your project. It tells you how long the project will last and when you need the people who will do the work.

Identifying resources

As project manager you should understand every person's role and responsibility on the project, likewise, your team members should know the chain of command and understand their own personal role and responsibilities within that chain.

Below are the steps in identifying resources for the project:

1. Create a responsibility matrix (RACI matrix)

Responsibility matrix spells out who can make or approve decisions, the groups performing work, and which groups need to be consulted or informed of what's going on. A responsibility matrix includes four categories of responsibility.

• R means a group is responsible for performing work

• A is for accountable which means the group makes or approves decisions and delegates work

• C means that you consult a group about decisions. However, they aren’t accountable for the decision that made

• I represents inform which means the group gets information

2. Review the responsibility matrix with stakeholders during planning and work out any disagreements before work gets started. If part of your project doesn't have an owner, talk to the stakeholders and your project sponsor to determine owners of the orphaned areas. If you use resources from other organizations such as with outsourcing, sub-contracting and partnering arrangements, document how all these groups contribute in the responsibility matrix.

3. Create a project organization chart which shows the hierarchy and reporting structure for people involved with or working on a project. Your project organization chart identifies the chain of command so you know who to talk to if you need to escalate a request or decision.

4. Finally, identify the type and number of skilled team members the project requires. A skills matrix is a tool you used to determine these requirements.

Here are the steps in creating your skills matrix:

1. Examine your work packages and identify the skills the package requires.

2. Create a matrix with your project tasks in rows and skill you need in a column.

3. Check boxes in the matrix when tasks require a specific skill. The number of checkboxes for a skill helps you identify how many people you need with that skill.

4. Estimate the labor cost of the project. To do this, assign a typical pay rate to each skill. Then multiply the number of people by the pay rate. this will give you an estimate of the labor cost for the project

You now have an idea of the type and number of skilled team members your project requires as well as an estimate of the labor costs.

Building a project budget

Most projects boiled down to money; making it, saving it, or the very least staying within the budgeted amount.

Project Budget which is the total cost of the project is almost always important. As a project manager you estimate the total project cost by calculating the cost to complete all the work. In some cases you present that budget to management and they decide whether the project makes financial sense. In many instances however, you receive a target cost from the management team, then it is your responsibility to figure out how to plan a project to stay within that budget.

Here are the type of costs that make up a project price tag.

• Labor Cost

Labor costs are usually a big part of a project's cost. If you hire vendors or contractors their charges go directly into your labor costs.

Include Burden Cost in your labor cost. Burden cost is the salary and employee benefits. Including employee cost is important, because they contribute to whether a project makes financial sense.

• Time-based cost

Projects could use other types of time-based resources such as equipment or office space that you rent. Include these equipment and other time-based costs in your calculations

• Material Cost

Material cost is the amount of money invested in the production of the product or services, such as the people you used to print sales materials or the construction materials for a building

• Ancillary cost

Ancillary cost is the catch all category. Cost that doesn’t fit on the above category falls under this category.

Note: PMI categorize cost as Fixed, Variable, Direct and Indirect Cost. The above cost category may fall into one of this type of cost.

Money is almost always a consideration with projects. you might need to know only, whether the price tag is within your budget, or you might have to show that the project delivers the financial benefit your organization expects.

Identifying risks

Every project faces risks. If you don't plan for how you will deal with them, you end up putting out fires which can cost your project time and money; and increase the pressure on your people.

The risk management plan is the tool you used to plan for the risks you might encounter. With the risk management plan in place, you already decided on how to respond when risks become reality, so you’re ready to make informed and prudent decisions.

To build the risk management plan, you have to identify the risks your project faces.

Here are the Risk Knowledge Level at Project start:

Known unknowns

These are risks you're aware of and risk that you can anticipate. To help you get started here are some examples of things that can introduce risk to projects.

• Technology might not work the way it's supposed to, cost more than you expect or will not show up when you need it.

• Team members located in different areas can increase risk such as delays due to time zone differences, miscommunication due to different languages, our cultural differences, or lack of teamwork because remote team members can’t develop effective working relationships.

• Lack of detail, such as specific on the deliverables, due dates or who will work on your project, can lead to all sorts of problems.

• Limited options such as needing people with rare skills increased risk because you don't have alternatives if a problem arises.

Work with everyone on your team to identify risks. Talk to the experts from different parts of the project about the risks they foresee. Ask key people on the project what they think. Ask other project managers about risks from similar projects.

Create a risk register that will document specifics about the risk. For example which tasks are affected, what objectives are in danger, what the consequences are, and so on.

Unknown unknowns

These are the risk you can’t foresee. These risks come from situations that are so out of this world that they never occur to you.

For example prior to the invention of the personal computer manufacturers of typewriters probably didn't foresee the risks to their business. Because you can’t identify these risks, you handle them by setting aside contingency funds for dealing with them, like having an insurance policy.

Contingency funds are commonly used method for responding to small risks in the unknown unknown risks you can’t foresee. The question is how much should you set side? Many companies use a percentage of the project budget, but the percentage used is typically based on past experience.

Now that you've identified risks your project may face, you need to evaluate those risks and determine how you plan to respond to them if they occur.

To know more about Project Risk and how to manage them, you can check the following articles:

• Project Risk Management: Creating a Risk Plan

• Project Risk Management: Identifying Project Risks

• Project Risk Management: Analyzing Project Risks

• Project RiskManagement: Responding to Project Risks

• Project RiskManagement: Monitoring and Controlling Project Risks

Setting up a communication plan

Good communication is crucial to the success of a project. If your project is large and complex with people working around the globe, good communication is even more important. During planning you put together a communication plan that helped to get the right information to the right people in the most effective way.

First identify your audiences, that is who needs to know about the project. The responsibility matrix is a good place to look to find your audiences.

Second define what your audiences need or want to know.

Management stakeholders typically care most about project achieving its goals. During planning you communicate the project plan to do that. While the project is under way you communicate progress, how much you spent and the overall project results.

The project sponsor is more tightly connected with the project, so you're probably communicate with the sponsor more often and perhaps use frequent face-to-face meetings.

Functional managers initially need to know the skill set when you need them and the other things like cost constraints. When people are on assignment these managers want to know whether the assignments are going according to plan and how longer people are going to be on the assignment.

Team members need to know what they're supposed to do, and ideally how that fits into the big picture. As they complete assignments they also need to know what’s on deck.

Finally the last part of a communication plan is how you distribute information to your audiences. That is how often information is exchanged, how it sent and the format you use.

Face-to-face communication is good for brainstorming, getting no people and discussing sensitive topics.

If your team is dispersed geographically email, conference, calls and videoconferencing are indispensable. Documents are good when you have to send a lot of information or people need time to digest the information they receive.

You define your communication plan during the planning process then once the project is underway you implement that plan so your audiences get the information they need as efficiently as possible

Developing a quality management plan

When you plan a project you also have to consider the quality stakeholders want from the projects deliverables or final product. You develop a quality plan in order to help your project meet that quality standard. For a project quality translates into meeting the customer's requirements and delivering on time and within budget. If your project includes deliverables or products, quality also means those products or deliverables conform to specifications.

A quality management plan is made up of three processes:

1. Identify the quality standards for deliverables.

For example, the quality plan might include the acceptable tolerance for the dimensions of the final product, or the acceptable number of defective products in a batch. Keep in mind that the goal is for quality to meet the standards you set. Obviously you don't want quality that is below standard. The customer won’t be happy, might ask for additional work to deliver the right results or simply may refuse to pay. However, you don't want quality that is higher than required either because other aspects of the project can suffer such as the schedule lengthening or costs expanding.

2. Define a quality assurance plan.

Document how you will demonstrate that the quality standards have been met. For example you might spot test the products coming off the production line to statistically determine the number of defective products in a batch. Although it isn't a separate quality process you can also plan your project to prevent defects in the first place. For example you might opt for a simpler design that makes it easier to manufacture a product and thus reduces the number of defective products that come off the assembly line.

3. The quality control process

The quality control process is how you will monitor and measure the quality of your results. Inspections go by a number of names: review, walk through and audit to name a few. The bottom line is that you examine or measure results to see if they meet the standards set.

Continuous improvement is a big part of quality management. If you find quality issues you also analyze the problems to see how to prevent them, or at least reduce their frequency.

The Fishbone diagram or cause and effect diagramsis a toll to help identify factors that could lead to problems, which in turn help you figure out ways to prevent the problems.

Pareto diagram is another tool, which shows how many defects are generated by each cause. The diagram lists the causes by the number of defects they generate so you can address the causes that produced the most defects first.

During the planning process you define the quality standards that are required, how you will measure quality and how you will determine that the result meets the quality standard you set. Once the project is underway you began monitoring and measuring results and evaluating whether they meet the quality standards you set.

Setting up a change management plan

One at a time, request for changes can seem small, but those small changes add up and can completely derail your project schedule and budget. Changes are unavoidable, so the only solution is to manage them.

Managing Project Change:

• Know the item that you want to control, such as the project scope, requirements or the entire project plan. The versions you control are called baseline documents. For example if you have an approved list of requirements for the project that’s your baseline.

• Use your change management process to decide whether new requirements can be added or not to the project plan. Keep in mind you don't use change management on draft versions of documents. When stakeholders sign off on them that’s when they go under change management.

• Have a change review board that reviews change requests and decides whether to approve them. This group is usually made up of key stakeholders such as the customer, functional managers and team leads.

• Define a change management process to use when someone requests the change. Here is one example of a change management process:

1. Submit change request.

A standardized change request form that people fill out makes it easier to evaluate changes, because each request has the information the review board needs to evaluate and make decisions. Typically, a change request form includes details about the requested change, the reason for the change, the business justification and the results it should produce.

2. The change review board reviews submitted change request.

The board may reject the change request. They might ask the requester to provide more detail; or revise and resubmit it; or they may accept the change request. If the board accepts the request it moves to the evaluation step.

3. Evaluate the impact of the change.

As project manager you can assign this task to someone on your team. The evaluator looks at different ways to handle the request and determines the impact of each alternative. The results of the evaluation are the change request impact statement, which outlines the alternatives and their impact. It might include a recommendation for how to proceed.

4. The impact statement comes back to the review board.

If the board approves the impact statement you add the request of the project plan. Whether the decision is yes or no be sure to notify the person who requested the change.

5. Update the baseline documents.

For example your project schedule might need new tasks added or deadlines extended for specific tasks.

6. Track where change are in your process.

You can use a change request log to record the status of submitted change requests.

As the request works its way through the steps you update the log with who is in charge of the request, the impact estimate, current status and at the end actual impact.

It's also a good idea to have a process for emergency changes that need a rapid decision between meetings of the change review board.

You can also check the following articles:

• Exploring Project Management

• The Project Initiation Phase: How to Start a Project

• The Project Planning Phase: How to Plan for the Project

• Building a Project Schedule

• Project Monitoring and Controlling: How to Run the Project

• The Project Closing Phase: The Project Conclusion

There are many sources of information to learn more about Project management. Here are some books I recommend:

• Successful Project Management: Applying Best Practices, Proven Methods, and Real-World Techniques with Microsoft Project by Bonnie Biafore

• Project Planning and Control by James P. Lewis

• Making Things Happen by Scott Berkun

• Fast Forward MBA in Project Management

• 101 Project Management Problems and How to Solve Them: Practical Advice for Handling Real-World Project Challenges by Tom Kendrick.

#ProjectManagement