Develop a project plan

Project planning overview

- A big part of project management is planning out your project in detail. You begin by identifying the
work that must be done. To make the project easy to manage, you break the work down into bite size
pieces. Once you have your list of tasks, you can start estimating who's going to do the work, how long
each task will take, and how much they'll cost. Figuring out when things happen requires some special
techniques. To build a schedule, you have to take into account factors like how tasks depend on one
another, how much resources are available to work on tasks and when those resources are
available. Planning also includes how you'll run the project, how will the team communicate, with what
tools and how often. You'll also put together other plans for managing change and risk, and what you'll do
to ensure quality. All of this information goes into a set of documents that represent the project plan. The
completed project plan doesn't get put on a shelf to gather dust. You use it over the life of the project to
direct the people working on your project, to keep track of how the project is going, to correct course, and
to communicate with stakeholders. Are you ready to build a project plan? We'll explore each
component of a project plan in detail. Because a project schedule is a key component of your plan, an
entire chapter is devoted to how you build one.
What is a work breakdown structure?
- [Instructor] After you get the go ahead to plan your project, the first thing you do is identify the work
that has to be done. Even small projects can have lots of tasks. That's why project managers use a
diagram called a work breakdown structure, or WBS, to organize work. You use it to divvy up project
work into manageable pieces so you can plan, track, and manage your project. Creating a WBS helps
manage the project in several ways. First, it's easier to estimate time and cost for smaller chunks of
work. Say the sponsor wants to know how long the whole project will take. You can't come up with a
good answer off the top of your head. It's a lot easier to think about how long smaller parts of the project
will take. After you estimate the small chunks, you can add them up to get an estimate for the entire
project. It's also easier to assign work to team members. By breaking work into smaller pieces, you'll have
built-in checkpoints to measure progress on the project. A WBS contains two kinds of tasks; summary
tasks and work packages. Summary tasks are the higher-level tasks that summarize work in some
way. Summary tasks describe parts of the project. They could represent phases, or deliverables, or even
work done by different groups in your organization. In our scheduling project, the WBS is organized by
deliverable. How many levels of summary tasks depends on the size of the project. A few levels are
enough for a small project. If a project is large or complex, you might have several levels of summary
tasks. Work packages are the lowest level tasks in the work breakdown structure. They spell out lowest
level project deliverables, and the detailed work needed to deliver them. In the scheduling project, the
summary task to configure the system server might have work packages to activate modules, set options,
and add software links. Breaking your project down into manageable pieces helps you plan and manage
your project effectively.
Build a work breakdown structure
- The best way to build a work breakdown structure, or WBS, is to start at the top level of summary
tasks and work your way down. Work with your team to identify the WBS. You're less likely to forget
work that needs to be done and the team is more likely to buy into the project. As a team, you identify the
top few levels of summary tasks. Then you can have smaller groups break down the summary tasks into
smaller chunks. At the end, everyone gets back together to review the results and correct any issues. If the
full team isn't on board yet, work with your initial team to brainstorm the WBS. Then you can revise and
add more detail to the WBS later as others join the project. Start by using the scope statement and
deliverables to identify the top-level summary tasks. For example, the scope for the scheduling
project includes redesign scheduling processes, a new scheduling system, documentation, and training. So
you add summary tasks to cover all of those. Next, break down each of the summary tasks into smaller
pieces. Intermediate deliverables come in handy for identifying lower-level summary tasks and work
packages. For example, the scheduling project includes a deliverable for a signed contract with the system
vendor. Let's add tasks to obtain proposals, select the vendor, negotiate terms, and sign the contract. You
might wonder, "How much breakdown is enough?" Most project managers shoot for work packages that
take between eight and 80 hours to complete. Work packages are the lowest-level tasks in the WBS and
represent the work that needs to be done. Consider breaking down work to match the frequency of your
status reports. That way, you have measurable progress and completed tasks for every status report. Here
are some tests to determine whether you've broken work down to the right level. Time and cost are easy to
estimate. Status is easy to measure. Task durations are shorter than your reporting periods. The detail is at
the level you can and want to manage. Different parts of a project might require different levels of
decomposition. One part of the project might include more work, so you break it down to three or four
levels. If another part of the project is simpler, you might need only two levels. Don't worry about the
initial organization of your WBS. You can rearrange it later as you learn more about the project. Building
a WBS from the top down works well because you can use the scope statement and deliverables to get
started. For practice, try building more of the scheduling projects WBS based on the project's scope and
deliverables.
How to create work packages
- [Narrator] A short task name in a WBS isn't enough to tell team members what they're supposed to
do. To give your team the info they need, create work package documents that describe the work that
needs to be done in detail. The level of detail needed in the work package document depends on things
like how familiar the work is and the experience of the person assigned to the task. For example, a work
package document might include a detailed description of the work for a less experienced person. For
someone more experienced, a checklist of things to do might be enough. 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 a work package document. Otherwise, write up a description of what
you will have when the task is complete and what it should look like. As project manager, you won't
know enough about every aspect of the work to produce these detailed task descriptions. Turn to the
people who helped you build the WBS, team leaders for the groups that will work on the project or other
knowledgeable people to help fill in the details. Work packages help your team members deliver what
they're supposed to. For practice, try defining a work package for the scheduled training task that appears
in the scheduling system WBS.
Estimate time and cost
- The two questions you get hit with most often about a project are, "How much time will it take?" And,
"How much will it cost?" Estimating accurately matters because your estimates could determine whether
it makes sense to run the project. You start by estimating time, because it affects both the project's
schedule and cost. You also estimate costs that aren't time based, like materials and ancillary costs like
travel. During initiating and planning, you might work with a core planning team to develop initial
estimates. During project execution, you can get more accurate estimates from the people assigned to
tasks. They understand what has to be done and know how long it will take, based on their
experience. Plus, they're usually motivated to live up to the estimates they provide. Estimates don't have
to be perfect right off the bat. For project selection, an estimate that's plus or minus 75% might be good
enough. As you learn more about the project during planning, your estimates grow more accurate, ideally
to plus or minus 10%. There are several techniques you can use for estimating. If you have similar
projects that are already complete, use them as a foundation for your project estimate. With parametric
models, you calculate work and cost based on some measure like the number of square feet for
construction. This technique works when you have data from many similar projects. If a project
represents uncharted territory for your organization, consider bringing in experts who are familiar with
the work, like consultants or vendors. The Delphi Technique counts on several heads being better than
one. First, you ask several experts to produce estimates independent of one another. You share the results
with the group, keeping the estimates anonymous. You keep the estimates anonymous because you don't
want anyone to be influenced by the reputation or authority of a co-expert. You then ask everyone to
estimate again. Repeat this step a few more times, and then use the average of the last round as your final
estimated value. For large projects or rough estimates, top-down estimating works well. You estimate
phases or major components and then break those estimates into smaller pieces until you get to individual
tasks. Estimating from the bottom-up means you estimate each task, and then add them up until you have
the estimate for the entire project. You can also start with a top-down estimate and then revise it by
working your way back up from the bottom to the top. The project schedule and cost hinge on your
estimate, so it's important to make them as accurate as possible. For practice, based on what you
know about the hospital's scheduling project so far, which estimating technique would you choose and
how accurate an estimate would you strive for?
How to choose the best estimate
- Project estimates are a lot like your morning commute. You need to choose an estimate that gives you a
good chance of getting where you need to be when you need to be there. On some days, your commute is
a breeze, maybe 30 minutes. Most days, let's say it's 45 minutes but an accident can turn it into an
hour. For your commute, you choose a drive time that gives you some wiggle room so you get to work on
time. The same approach works equally well for your project estimates. You probably decide when to
leave for work informally. We're going to look at a similar, yet rigorous approach to choosing estimate
values for your project. If you were to graph the probability of your commute times it would look like a
bell curve with your average drive time at the peak. A bell curve is also known as a normal
distribution and it has properties that help you choose a safe estimate to give your customer First on a bell
curve, 50% of the possible values are less than the average, and 50% are greater. That means the average
value gives you a 50 50 chance of your results being equal to or less than your estimate. Think about it. If
you give your customer your average estimate you are as likely to fail as you are to succeed. I wouldn't
stake my career on those odds. On the other hand, the worst case estimate gives you the highest chance of
success. However, that number is so high, your customer might cancel the project. You probably know
that customers are prone to ask what's the best case scenario? What if everything goes right? Don't fall for
this trap. Suppose you give the customer your best case estimate say six months, and you describe
everything that has to go right to finish the project in six months. This is what they'll hear, blah, blah,
blah, blah six months, and you've set up your project to fail.. We've eliminated the best, worst, and most
likely values. You're probably wondering what number you should use for your estimate. The answer is
about halfway between the average and worst case values. Let's go back to the bell curve and pick the
value halfway between the average and worst case values. Without getting into the mathematical
details, that gives you an 86% probability of your results being less than or equal to that number. That's a
good chance of success, and the value is easy to calculate. Plus, you can tweak your value higher to
reduce the chance of missing the deadline, just like you would leave extra early if you're going to a job
interview and if you're trying to win a project you might choose a smaller value even though the risk of
failure is higher. The bottom line is choose the estimate that provides an acceptable probability of
success. For practice, use the information in the exercise files to determine the time estimate you would
give the hospital COO.
Create a resource management plan
- [Presenter] Part of planning is to identify and document project roles and responsibilities. Who reports
to whom and the skills needed to do the project work. That's where the resource management plan comes
into play. This plan also includes a staffing plan which describes everything about how you'll staff the
project. You start with a responsibility matrix. This document spells out who can make or approve
decisions, the group's performing work, and which groups need to be consulted or informed about what's
going on. A responsibility matrix includes four categories of responsibility. R means a group is
responsible for performing work. I represents inform, which means a group gets information. C means
that you consult a group about decisions. However, they aren't accountable for the decision that's made. A
is for accountable, which means the group makes or approves decisions and delegates work. During
planning, review the responsibility matrix with stakeholders and work out any disagreements. If part of
your project doesn't have an owner, meaning someone accountable for that area, talk to the
stakeholders and your project sponsor to identify who is accountable for that area. You might have
outsourcing, subcontracting, and partnering arrangements. Don't forget to add these groups and how they
contribute to the responsibility matrix. The second part of a resource management plan is a project
organization chart. It's like a regular org chart except it shows the hierarchy and reporting structure for
people involved with the project. That way, you know who to talk to if you need to escalate a request or
decision. Third, identify the skills the project requires and how many people you need with those skills. A
skills matrix helps you figure this out. To build one, take a look at your work packages and identify the
skills each package requires. Then create a matrix with your project tasks in rows and the skills you need
in the columns. Add check boxes in the matrix when tasks require a specific skill, then you estimate the
number of resources you need with each skill. You can even multiply that number by the average pay
rate to estimate the labor cost. Finally, it's time to develop the detailed staffing plan. Identify where you
plan to get resources. Are they in house, outsourced or contracted? When do you need resources? Identify
any training they need and document resource related processes. Getting team members on
board, handing out assignments, getting status updates and releasing them from the project when their
work is done. A resource management plan documents who does what, who reports to whom, the
resources you need, and how you'll manage them. As an exercise, use what you know about the project so
far to complete the responsibility matrix in the exercise files. Then using your responsibility matrix, draw
up a project organization chart.
Build a project schedule
- [Instructor] A WBS identifies the work needed 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. First, put the tasks into the right sequence. You add dependencies or links to tasks to identify
which tasks have to finish before other tasks can start, which tasks finish at the same time, and so on. For
example, the task "Build Specs" has to finish before "Review Specs" can start. Likewise, "Review Specs"
has to finish before "Approve Specs" can start. We'll look at dependencies in detail later in the course. For
now, the most common dependency type is finish to start. Next, you add the time you estimate each task
will take. Time estimates and task sequence help determine how long the entire project will take. Third,
you assign the people on your project team to tasks. With the estimated time and people assigned to do
the work, you can calculate the task duration. Finally, take into account other constraints like deadlines
and when resources are available. If your initial schedule doesn't work, you can tweak it in various
ways whether you're trying to shorten the schedule, cut costs, or even out people's workloads. 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.

Develop a project budget

- [Instructor] With most projects, money is important, whether you're trying to make it, save it, or stay
within a budgeted amount. Project cost is one of the three key constraints you need to manage, and the
project budget is your starting point. The project budget should be a realistic estimate of the cost to
complete the project work. If your estimate is unrealistically high, the project could be canceled. If the
estimate is too low, the project will cost more, which usually means it won't deliver the financial benefit
it's supposed to. You estimate all the costs associated with completing the project work, including labor,
materials, and other costs like travel. You can start with rough estimates for the first few levels of your
work breakdown structure. Then create more accurate estimates as you learn more about the
project. Labor cost is usually a big part of a project's cost. That is what you pay people who work on the
project. If you hire vendors or contractors, their charges go directly into project labor costs. For
employees, you typically use the burdened cost. That includes salary and employee benefits. You can get
burdened rates for roles from your accounting or HR department. Projects might use other types of time-
based resources. Think equipment or office space that you rent. These costs go into your calculations
too. Then there's material cost. The hospital scheduling project could include a new server or training
guides and documentation notebooks. Finally, be sure to include other types of costs that don't fit in the
previous three categories. For example, travel, training expenses, and fees. Have you ever gotten into a
cash crunch when you didn't have enough money on hand to pay expenses? Projects can run into cash
flow problems too, which is why you figure out when project expenses will occur. When you assign
resources and other costs to the tasks in your project schedule, you'll get a rough idea what your cash flow
looks like. Let's say management has money allocated for the project, like the grants and
donations earmarked for the hospital scheduling project. If your cost estimate is higher than the allocated
amount, you have to look at ways to reduce the project cost. You might eliminate non-essential
expenses or find less expensive resources. Maybe cut scope. In the hospital scheduling
project, management allocated $850,000. The estimate, including contingency is 950,000. You might
consider working with less contingency funds, ask for more money, or dive in to find ways to cut the total
cost. The project budget is the cost target you aim for as you manage a project. For practice, think about
what you can do about the $100,000 that exceeds the amount that management has allocated for the
scheduling project.
Identify risks
- You've already put a lot of planning into your project. The next step is to plan for what could go
wrong because you know something will. Instead of asking for an adrenaline rush, why not identify what
could go wrong so you can plan ahead for dealing with issues. Let's start with risks you're aware
of. They're called known unknowns, things like weather delays or resources being unavailable. Let's look
at some examples of things that can introduce risk to projects. Technology. It might cost more than you
expect, not work the way it's supposed to or not show up when you need it. A widely dispersed project
team can increase risk. You could have delays due to time zone differences, miscommunication from
different languages or cultures, or lack of teamwork because remote team members haven't developed
effective working relationships. Lack of detail, like specifics on deliverables, due dates or who will work
on your project can lead to all sorts of problems. Limited options, like people with rare skills increase risk
because you don't have easy alternatives to apply if a problem arises. Work with everyone on your team to
identify risks. You can ask experts for different parts of the project about the risks they foresee. Ask key
people on the project what they think and ask other project managers about risks from similar
projects. Fill out a risk information form for each risk you identify. Include as much detail as you
can. Which objectives are in danger? What events can cause the risk to occur? What the consequences
are, who owns the risk, and so on. Up until now, we've talked about risks we can anticipate but what do
you do about the risks you can't predict? These are called unknown unknowns. They come from situations
that are so unlikely that they never occur to you. The 9/11 attack was an event that no one thought
possible. You're unlikely to have to deal with such a significant unknown risk, but you will encounter
unknown risks at some point, and you need to plan for them. How? By setting aside contingency
funds and time for dealing with them. The question is, how much should you set aside? Many companies
use a percentage of the project budget like 15%, but the percentage is typically based on past
experience. To minimize the effect of risks, you first have to identify the risks that your project faces. Try
to identify several risks that the hospital scheduling project might face. For an extra challenge, use the
risk information form in the exercise files to document the risks.
Create a risk management plan
- A risk management plan documents which risks you're going to worry about and how you plan to handle
them. First, identify which risks warrant managing. Start by evaluating how likely they are and how
serious their impact would be. Rate risks by probability and impact, using a scale of one to five, where
one is unlikely or not serious, and five is highly likely or extremely serious. Then multiply the probability
and impact to calculate a risk score. It makes sense to manage risks that are at least fairly likely and
serious. That means you need a plan for any risk with a score of nine or more. For example, suppose older
hospital computers are very likely to be incompatible with the new scheduling systems. New computers
increase the budget so the impact is very serious. The risks score is 25 so you'll definitely need to manage
it. Risk one's probability and impact are both medium. Its score is nine and you need to plan for it. Risk 4
is fairly serious, but it isn't likely. Its score is 3 so you won't plan for it. Next, you plan how you'll handle
each risk. The goal of a risk response is to plan the actions you would take to reduce adverse
consequences a risk might have on your project. Here are some risk responses you can use. The easiest
option is to accept the consequences. That's fine for risks with low probability and impact. Avoiding risk
is another approach. For instance, changing the project's scope to remove the risky part of the
project. Mitigating risk means taking steps to reduce the consequences or impact of the risk. For example,
by running a feasibility study, you'll have a better idea whether a scheduling system will meet the
schedule, budget, and other objectives. Transferring risk means handing off the risk to someone else, like
when you purchase insurance. This reduces risk but doesn't eliminate it. Insurance might relieve costs, it
won't eliminate other factors like time delays. Make sure your responses aren't overkill. If a schedule
delay triggers a $500 late fee, it doesn't make sense to spend $5,000 to prevent the delay. Remember,
contingency time and funds can be used to handle risks that have no other response or to handle risks you
didn't identify upfront. The final step in a risk management plan is defining how to monitor risks and
measure responses. Create a risk log to summarize the risks you'll manage. For each risk, include a
description of the risk, the events or circumstances that trigger the risk, the probability and impact, the
response you've chosen, who will monitor the risk, the result you expect from the response if you have to
use it, and finally, the risk status. Keep your risk plan up to date as the project progresses. Some risks
become less likely as time passes. Other risks may be introduced because of project changes. Risks occur
so you track what cause them, their impact, and whether your responses are working. A risk management
plan helps protect your project from things that can go wrong. For practice, fill out more of the risk log in
the exercise files.
Set up a communication plan
- [Instructor] If you've ever heard Abbott and Costello's "Who's on First?" Skit, you know how hard it can
be to get your point across. The success of a project depends on good communication. That's why you set
up a communication plan. The right people, getting the right information at the right time, and in the right
way. You start with your audiences. Who needs to know about the project? The responsibility matrix is a
good place to look to find your audiences. Second, what do your audiences need or want to
know? Management stakeholders care about a project achieving its objectives. Early on, you give them
the project plan so they can see how you're going to deliver. Later on, they want to know about
progress. How much you've spent, and the overall project results. The project sponsor is tightly connected
with the project. You'll probably communicate with the sponsor more often, maybe in face to face
meetings. Functional managers initially need to know the skill sets you need, when you need them, and
other things like cost constraints. Once people are on assignment, these managers want to know when
their people will be done. Team members need to know what they're supposed to do. They're more likely
to buy into the project if you tell them how their work fits into the big picture. As time passes, they also
need to know what's coming up next. The last part of a communication plan is the how. How often the
methods you use and the format. Face to face communication is good for brainstorming, getting to know
people, and discussing sensitive topics. If your team is dispersed geographically, email, conference
calls, and video conferencing are indispensable. You know that stakeholder management is all about
getting and keeping stakeholders support for your project. The communication plan helps by spelling
out how you're going to communicate with stakeholders to keep them on board and happy. A
communication plan helps ensure that people get the information they need in the most effective way. To
solidify your understanding, set up a communication plan for the Hospital Scheduling Project.
Develop a quality plan
- [Instructor] Project success actually means meeting objectives, not exceeding them. Quality
management includes processes to make sure that a project satisfies its objectives and requirements. A
quality management plan is your roadmap to meeting objectives. Project quality translates into meeting
the customer's requirements and delivering on time and within budget. With deliverables and
products, quality also means conforming to specifications. A quality management plan has three
components. First, there's the quality standards for deliverables. For a product, the quality standard might
include the acceptable tolerance for its dimensions or the acceptable number of defective widgets in a
batch. For the hospital scheduling project, one quality standard might be that the scheduling system meets
all the required scheduling functions. Keep in mind that the goal is to meet the quality
standards. Obviously, you don't want quality that's below standard. The customer won't be happy. They
might ask for additional work to get it right or simply refuse to pay. This might surprise you. You don't
want quality that's higher than required. Why? Because other aspects of the project can suffer, like a later
finished date or higher cost. The second part of the quality management plan is a quality assurance
plan. This spells out the processes you use during the project to ensure that the final results meet the
quality standards. For the scheduling system, reviewing requirements and designs falls into this
category. You might also test software functions as they're developed. Finally, you plan for quality
control, which means how you measure and monitor quality in the final deliverables. The bottom line is
that you examine or measure results to see if they meet the standard set. For the scheduling project, the
final acceptance test would measure whether the processes and system achieve their objectives. For the
hospital's new cancer wing, you would do a walkthrough to confirm that the construction has been
completed correctly. Continuous improvement is a big part of quality management. If you find quality
issues, you analyze the problems to see how to prevent them or at least reduce their frequency. Cause and
effect diagrams are also called fish bone diagrams, because they look like a fish skeleton. They help
identify factors that could lead to problems. Those factors can help you figure out ways to prevent the
problems. Another tool is a Pareto diagram. This shows how many defects are generated by each
cause. That way you can address the causes that produce the most defects first. By developing a quality
management plan, you can ensure that your project meets its quality objectives. For practice, identify
potential quality assurance processes and quality control measures for each of the project objectives.
How to set up a change management plan
- [Instructor] The government tax code started out so simple but a deduction here, a new rule there and
now we have the complicated tax returns of today. You know changes are going to happen so the only
solution is to manage them. A Change Management Plan helps you add important changes into your
project while keeping out the ones that don't make sense. First, you identify what you want to control like
the project scope, requirements and the schedule or perhaps the entire project plan. The versions you
control are called baseline documents. The list of project requirements approved by the stakeholders is
your baseline. If new requirements are suggested, you use your change management process to decide
whether or not to add them to the requirements list. You also need a group that reviews change
requests and decides whether to approve them. It's called the Change Review Board and it's usually made
up of key stakeholders. Then you define a change management process. That's what will happen when
someone requests a change. The process your organization chooses depends on things like the company
culture and project size. Here are the typical components of change management processes. The first
process is documenting and submitting a change request. Use a standardized Change Request Form that
requesters fill out. It's easier to evaluate changes because each request has the information. the review
board needs to make decisions. Include details about the requested change: the reason it's needed, the
business justification and the results it should produce. Next, someone has to evaluate the request and
estimate its impact. As project manager, you can assign this task to someone on your team. The evaluator
determines whether the change is needed. If it is, the person evaluates whether the suggested approach is
correct or if an alternative would be better. The evaluator estimates the effort and cost the change would
require, the impact on the project and whether it introduces risks. Third, the Change Review
Board reviews evaluated change requests. The board might accept or reject the change request. They also
might ask for more detail or revisions. Be sure to communicate the decision to the person who requested
the change. For approved requests, you update the baseline documents to reflect the change. For example,
your project schedule might need new tasks or deadlines extended. Finally, track where change requests
are in your process. A change request log shows the status of submitted change requests, who's in charge
of the request, the impact estimate, current status and at the end, actual impact. Consider setting
thresholds so team leads can decide what to do with smaller requests. That way your change management
process isn't overwhelmed with small items. Also, create a process for emergency changes that need a
rapid decision between meetings of the Change Review Board. A Change Management Plan helps you
include changes that make sense in your project while protecting your project from being
overwhelmed with unnecessary changes. To solidify your understanding of change management, draw a
flowchart of the change management processes the hospital might use.
How to plan procurement
- [Narrator] Even with homemade chicken soup, you don't make everything from scratch. Imagine how
long it would take and how much it would cost if you had to raise your own chickens, vegetable, and
wheat and make chicken stock and noodles. The same goes in the project world. Procuring products,
services, and skills can be a lot quicker than trying to do everything yourself. When you purchase items
from outside your organization, you need to plan how you're going to do that. You guessed it. That's what
a procurement plan is for. First, you identify what you need to purchase. Maybe you need people with
specific skills, or you need more people than your organization has, or the project requires products and
materials. Second, you document your procurement processes. Who handles procurement? Is it the
purchasing department, the project team, or a combination of the two? The plan describes criteria for
choosing vendors, the selection process, types of contracts you use, and how you manage those
contracts. Fortunately, you usually don't have to invent all these processes. Most organizations already
have procurement processes in place. Talk to your purchasing department or finance group to find out
how it's done. Third, you describe your make-or-buy decision process. Basically, how you decide whether
to use in-house products or services or procure them. To make an informed make-or-buy decision, it's
important to understand your needs. Make sure your requirements are clear, and then prioritize them. That
way, it's easier to pick products that meet your requirements. Plus, you can resist bells and whistles you
don't need. You have to see if a product that meets your needs is available. If it is, evaluate how it matches
up with your requirements. Before you finalize your decision, consider the pros and cons of making
versus buying. If your project is on a tight timeline, buying is probably the right choice. The last part of
the procurement plan is a list of potential vendors who offer what you need to purchase. Describe how
you researched vendors and contractors and the criteria for developing the list. Procurement planning
helps you make smart decisions about whether to purchase products and services, and if you do, which
products and services to procure. As an exercise, identify some of the criteria you might use to choose the
scheduling system vendor.
How to obtain approval to proceed
- Now that you have a plan for the project, you need to get the stakeholders to approve the plan so you
can start work. Getting approval is important because you need the stakeholders' commitment to make the
project a success. You might think about getting approval by mailing or emailing a packet to
stakeholders and asking them to sign on the dotted line. I don't recommend that approach. Here's the
problem. People probably won't read through the plan. Sure, they might sign their names, but later if they
find something they disagree with, their commitment disappears and you end up back to planning. A face-
to-face sign off meeting is more effective. Schedule a meeting specifically for getting approval. The
agenda is straightforward. First, present the project plan to make sure that the stakeholders agree with
it. If issues arise, deal with them right then and there. Or if the issues are big enough, you might have to
reschedule the sign off so you can rework the plan. Once everyone agrees, ask them all to sign a signature
page to indicate their approval. If you can't get everyone in the same room, a video conference or
conference call works too. Ask the people in other locations to transmit their signatures to you by fax,
email, or even snail mail. Signing a project plan isn't like signing a legal document. You're never going to
go back to your stakeholders and say, "But you signed this." What's important is that the stakeholders
understand what the project is about and buy into it.
Challenge: Change
(cheerful music) - [Narrator] At this point in the hospital scheduling project, you've created drafts of
several planning documents. But in the project world, things change and this project is no exception. The
government has launched a major initiative in cancer research. Part of this initiative is using a common
scheduling tool for all cancer treatment facilities. Brisland Hospital's new cancer ward will have to use the
government scheduling tool instead of the solution that your project will implement for the rest of the
hospital. In the exercise files, there's a change request submitted by the project manager and approved by
the project customer. This change means that you'll have to revise some planning documents. For this
challenge, take 20 to 30 minutes to identify which planning documents you need to revise and at a high
level what you would change. After you work through your solution, look at the files I would revise in
response to this request.