Planning a Project

• Project SOW (business need, product scope description, strategic plan
• Business Case (market demand, organizational need, customer request, technological advance, legal requirement, or social need)
• Contract
• •Enterprise environmental factors (governmental or industry standards, organization infrastructure, marketplace conditions)
• Organizational process assets (organizational standard processes, templates, historical information and lessons learned knowledge based)

• Project purpose or justification
• Measurable project objectives and related success area
• High level requirements
• High level project description
• High level risks
• Summary milestone schedule
• Summary budget
• Project approval requirements
• Assigned project manager
• Name and authority of sponsor

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.

• Objectives. List the objectives that each stakeholder cares about—from her hottest button to her coolest. If you need help rallying stakeholders around an objective, this info helps you find allies.

• Contributions. List what the stakeholder does for the project.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.

You can download a sample of a STAKEHOLDER REGISTER

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 happen exactly as planned.

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.

• Why are we going to perform this project? The answer to this question describes the point of the project. You can also rephrase this question as “What’s the problem we want to solve or the opportunity we want to leverage?” "describe the problem that the project is supposed to solve"

• What are we going to achieve? By definition, a project eventually ends. You have to 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."

• What approach are we going to take? The problems that projects solve usually have more than one solution. Part of project planning is figuring out which solution—or project strategy—is best. Then, the project plan documents the strategy you’re going to use to address the problem and why you chose it.

• What are we going to do? Based on the strategy that’s selected,  the project plan describes how the project will achieve its objectives.It delineates the boundaries of the project so stakeholders know what to expect.

• Deliverable the tangible results the project needs to produce and the success criteria you use to judge whether the deliverable are acceptable.

• Every section listed in the project scope statement has corresponding deliverable and success criteria.

• With the scope, deliverable, and success criteria in hand, you’re ready to describe the work that needs to be performed.

• When will the project start and finish? Projects have starting and ending points, so the plan documents these dates. In addition, the project schedule actually shows the sequence of tasks and when each one starts and finishes.

• Who will work on the project? People and other resources actually do the work, so the project plan includes a responsibility assignment matrix and a project organization chart to identify the team. Depending on the size of the project

• How much will it cost? Blank checks are rare in any environment, so the project plan includes a budget showing where all the money goes.

• How good do the results need to be? Given constraints on time, money, and resources, you usually don’t have the luxury of doing a spectacularly better job than required. The project plan outlines how you intend to achieve the level of quality the project requires, and how you’ll measure that quality.

• How do we know when we’re done? Part of project planning is to clearly define success. For each objective and deliverable you identify, specify how you’re going to determine whether they’re done. Otherwise, you could have trouble bringing closure to your project.

You can download a sample of a Project Scope Statement 

What Strategy Will You Use to Solve the Problem?

A strategy also has to pass a test to be a success:

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.

• Identifying the work to do. A work breakdown structure or WBS  breaks up work into small tasks that 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 have to perform.

You can download a sample of a WBS Outline & WBS Dictionary

• Laying out the project’s schedule. With the WBS complete, you can estimate the effort required to perform each task and its duration and then put tasks into the sequence in which they need to happen. The result is a schedule that approximates how long the project will take and when tasks should start and finish.

• 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 can work on tasks, and when those resources are available.Building a project team begins with identifying the skillsets you need for tasks and other resources such as equipment and materials.

• Setting the project’s budget. Whether the customer has a set amount of money to spend or your company’s executives require a minimum return on investment , money matters. The cost of a project is a combination of labor costs, equipment and material costs, and other expenses like travel or training.

A communication plan describes the rules for sharing information on a project, like whether people should email status updates, post them on a website, or scratch them into banana leaves. :)

• 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 info about 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 depend on what your organization has available, as well as how people like to communicate.

You can download a sample of a Communications Management Plan 

When you plan a project, you define its scope, the deliverable it will produce, and the objectives it will achieve. Inevitably, when the project starts, someone remembers one more thing they need, and someone else finds a better way to tackle a problem. These changes can dramatically affect the plan you so carefully prepared, so you need to evaluate requested changes to decide whether they belong in the project. If they do, then you adjust the project plan accordingly. Most projects need a change control board a group of people who decide the fate of change requests.

• Submit change requests
• Receive and record change requests
• Evaluate the effects of change requests on cost, schedule, and quality
• Decide whether change requests become part of the project
• Update project documents to incorporate accepted changes
• Track changes as you do other project task work

You can download a sample of a Change Management Plan & Change Request

Things can and will go wrong on your projects. It’s easier and faster to recover from troublesome events if you anticipate them and have a plan for how to respond. Risk management starts with identifying what could go wrong.

Then you analyze those risks and decide what you’ll do if they actually happen. As the project progresses, you monitor risks to see whether they’re getting more threatening or going away.

Finally, if a risk does become reality, you launch your counter-attack and monitor the results.

For each risk you intend to manage, you need to decide what you’re going to do if it happens. The best responses prevent bad things from occurring in the first place.

• Accept. If the risk won’t cause noticeable damage, you can just accept the consequences.

• Avoid. Avoidance is one way to handle a risk if the risk doesn’t affect the project’s ability to achieve its objectives.

• Control the pain. The formal name for this approach is risk mitigation: You take action to reduce the consequences if you can’t completely eliminate them.

• Give the risk to someone else. Transferring risk means that you let someone else take on the risk—but you pay a price.

• Give yourself options. Contingency plans are another option. They typically make use of funds set aside (called contingency funds) to handle the additional cost.

Risk management includes tracking risks that have occurred and keeping an eye on those that are still

potential problems. A risk log documents the status of each risk you've decided to manage. For risks you monitor, include a summary of the risk and your planned response.  Also, identify the person who’s monitoring each risk. You have to stay on top of risks and update the

log regularly.

You can download a sample of a Risk Management Plan & Risk Register