First Thing First.

Initiate a project
- Initiating a project is about getting commitment to move forward. In other words, the customer or
sponsor says yes to the project and gives the go-ahead to start planning. Typically, the first step in project
initiation is to assign the project manager who guides the project through the rest of the initiation
process. Sometimes the project manager is assigned after the project's been approved. If you find yourself
in this situation, be sure to review what was done during initiation and complete any activities that were
skipped or left unfinished. The customer or sponsor should make an informed decision whether to
approve the project. That's why initiation boils down to defining the project. You identify the problem the
project is supposed to solve and gather information about the project, objectives, requirements,
deliverables, and more. Once you have an initial project definition, it's time to prepare the project
charter. This document formally authorizes the project and describes the authority of the project
manager. Throughout this chapter, I'll describe the key elements of a project definition and what goes into
a project charter.
Identify project stakeholders
- As project manager, you need to know who has a stake in the outcome of your project. They're called
stakeholders. They include the customer, project sponsor, departments involved with the project, and
people who work on project tasks. You need to know what they expect from the project and how they
contribute to it. It's vital to understand stakeholders importance, influence and interest in the project. That
way, you can build relationships with influential stakeholders and make sure they're satisfied with project
results. Let's start by identifying major stakeholder roles. The project customer is the person or group with
a problem to solve. For the hospital scheduling project, the COO oversees scheduling, so she is the
customer. The project customer brings three crucial things to a project. First, the customer funds the
project. In the hospital, the CEO oversees the overall budget for the new cancer wing and operational
improvements, but the hospital COO is in-charge of the budget for the scheduling project. Second, the
customer has a lot to say about what the project will do. Third, the customer approves deliverables from
start to finish. The next STAKEHOLDER role is project sponsor. The sponsor is someone who wants to
see the project succeed and has enough formal authority to help make that happen. Like an executive,
who believes in the project. For the scheduling project, the COO is also the project sponsor. She wants to
see it succeed because she believes effective scheduling not only improves patient care and medical
results, but also produces better financial results. Her position gives her enough authority to champion the
project. A sponsor can help prioritize objectives, talk to stakeholders who aren't being supportive, and
suggest improvements to the project plan. The third type of stakeholder is a functional or aligned
manager. Functional managers run departments and are accountable for achieving their department's
goals. They also manage the people in their departments who are the ones you need to staff your
project. Team members are also stakeholders. While they're assigned to your project, their jobs depend on
their assignments and may depend on how well they perform. Finally, there are departments or
people who affect the project, and there are departments or people who are affected by it. Both of these
groups are project stakeholders. For example, the project will affect how hospital facilities are
scheduled so the facilities department is a stakeholder in the scheduling project. As a project manager,
you need to know a lot about stakeholders in order to keep them happy. The first step is knowing who
they are.
Analyze project stakeholders
- [Narrator] It can be challenging to figure out who the stakeholders are for your project, which ones are
most important and the best way to work with them. That's where the stakeholder analysis
document comes in handy. You can store information there as you identify stakeholders and learn about
their part in your project. Identifying stakeholders and their part in the project doesn't happen all at
once. You'll figure all that out over the course of defining the project. First, you need to know how your
stakeholders are connected to your project and what motivates them. Start by including the department,
business unit or company the stakeholder belongs to and their position in the organization. Next,
determine who the stakeholder listens to. That can help if you need to figure out how to deal with that
stakeholder. You can ask that person how to handle the stakeholder or ask them to help directly. Identify
the project objectives that the stakeholder cares about and how they prioritize those objectives. That way
you know which stakeholders to talk to if an issue comes up with an objective. Categorize each
stakeholder by their influence and interest in the project. That helps you prioritize stakeholders so you can
manage the time you devote to working with them. Finally, document the stakeholder's contributions to
the project so you know what to expect from them or who to turn to for things you need. For practice, use
the stakeholder analysis spreadsheet included with this course. Fill in information about the
stakeholders for one of your own projects. In addition, the exercise files include a filled out stakeholder
analysis spreadsheet for the hospital scheduling project. Keeping stakeholders happy can be
overwhelming and time consuming if you don't know what they want and how they're involved in your
project. That's why analyzing your project stakeholders is a key task during project initiation.
Identify the project goal
- The first step toward project success is finding out what the customer really wants. The project goal is
the end result that the project wants the customer to deliver. A goal is something like a problem to
solve or an opportunity to take advantage of. It drives everything that happens in the project, so you want
to make sure you've got it right. You start by putting together a problem statement that clearly defines the
problem or opportunity. It doesn't have to be a long winded affair. It you can fit it into one sentence, all
the better. Developing a problem statement can be challenging because people often jump straight to
solutions. Solutions describe the end result, not the initial motivation. In the hospital project, suppose the
COO tells you that the hospital wants to implement a new scheduling system, that's an end result. One
way to backtrack from a solution to the original problem or opportunity is to ask why. Why do we need a
new scheduling system? Don't be afraid to ask why more than once. You can use the answers to get to the
bottom of the problem or even uncover more specific objectives for the project. For example, you ask the
COO why she's considering a new scheduling system. She says, hospital resources seem to be either
jammed up or sitting idle. When you ask why that happens, she explains that most procedures require
specific equipment, staff qualified to perform the procedure, and often a specific room to accommodate
the equipment. The current scheduling system and processes don't take all that into account. The
equipment might be scheduled, but the technician isn't available, or the scheduled room can't handle the
equipment. In addition, the hospital has received grants and donations to fund improvements to address
these issues. The problem statement for this project might be, "Hospital resources aren't being utilized
efficiently "because scheduling doesn't ensure "that the necessary equipment, staff, "and facilities are
available. "Funding is available to address scheduling issues." With a problem statement in hand, you can
define the project goal. That is the end result the project will deliver. The goal should be simple and
easy for everyone to understand. That way you can use it to get buy-in and guide the team to a successful
conclusion. For the hospital project, the project goal might be, "The project will deliver scheduling
improvements, "so hospital resources can be scheduled efficiently. "The project will take advantage of
funding available "for productivity and technology enhancements." Knowing where you're going is the
best way to start a project. Try writing a problem statement and goal for the project you're working
on using the template included in the exercise files.
Define project objectives
- [Instructor] Once you define the project goal, you can flesh it out by identifying more detailed
objectives. They help define the project scope, the approach you choose and the success criteria you have
to meet. Business objectives, support your organization's goals. For example, increase market share to
25% or provide world class healthcare. Financial objectives are all about money. Think increasing
revenue by 15% or cutting costs by 10%. Quality objectives specify how good results need to be. The
hospital might want to decrease staph infections by 80% or decrease readmittance by 75%. Projects can
also have technical objectives. These are similar to technical specifications for equipment. The hospital
might want mobile equipment that can be used in the hospital, an ambulance or at a remote emergency
site. There's also a catchall category called performance. Your project might need to finish by a specific
date. The hospital has to use the government grants before they expire. Now let's talk about best practices
for documenting objectives. One way to define clear objectives is to use SMART criteria. Specific
objectives are clear so there's no misunderstanding about what you're supposed to achieve. For example,
increase revenue by 15%. With vague objectives, you probably won't get what the project customer had in
mind. Measurable objectives make it easy to see whether or not they have been achieved. For example,
the hospital can measure the decrease in readmittance or revenue increase. With qualitative measures, you
might use survey responses such as a minimum patient satisfaction rating of four and a half
stars. Achievable or realistic objectives spell out what you can do with the resources
available. Challenging objectives can motivate people but your team might give up if they think the
objectives are impossible. Time- related objectives, identify when they need to be achieved. Be sure to set
a clear target date. For example, the government grants must be used by December 31st, 2020. Now that
the project goal and objectives are identified, you work with the appropriate stakeholders to perform a
benefit analysis. That way you can validate that the project aligns with the organization's mission and
strategy and delivers the expected value to the business. There are usually multiple ways to achieve the
project goal and objectives. That is, strategies for solving the problem. Typically, choosing a strategy is
work for senior project managers. However, choosing a strategy begins with a small group of
people familiar with the project to brainstorm possible strategies. Then they evaluate how well each
strategy satisfies the project objectives. Project objectives help flesh out the project goal and define
project scope, approach, and success criteria. The exercise files include an objectives template and a
description of what the hospital wants to achieve. Use them to list and categorize the hospital's objectives.
Gather requirements
- [Instructor] Now that you have the project goal, objectives, and strategy identified, it's time to describe
specifically what the project must deliver, known as requirements. Getting requirements right is crucial. If
you don't identify a project's true requirements, the stakeholders won't be satisfied with the project
results. And if you include requirements that aren't necessary, the project will probably take longer and
cost more than it should. For the hospital scheduling project, one objective is rescheduling procedures
decreased by 75%. One requirement for the scheduling system might be, simultaneously schedule
staff, equipment, and facilities required for a procedure. Another requirement could be, search for next
time slot that all selected items are available. These requirements are both necessary and specific. You can
expand them to provide even more detail. Gathering requirements can be challenging. Stakeholders might
describe their requirements incorrectly or provide inconsistent or contradictory requirements. They might
leave out requirements they need or include nice to haves. Sometimes people who aren't stakeholders try
to squeeze their requirements into your project. In addition, stakeholders often balk at committing the
time it takes to define requirements. There are several techniques for gathering requirements. Interviews
are one approach. The key is to interview the right people and come with a list of questions. If your
project involves several groups, try brainstorming sessions or focus groups with representatives from each
group to discuss their requirements for the project. These meetings may help you obtain buy-in from the
departments that attend. Another approach is to observe how people work. In other words, watch what
people do in their day to day activities. To validate the requirements, write them up and review them with
the workers. Questionnaires and surveys are another way to get requirements from stakeholders. Build
these documents carefully so the questions don't influence the answers people provide. If documentation
or results already exist, you can identify requirements by analyzing documents or reverse engineering
products. Next, you need to analyze the initial requirements to make sure they make sense. You might
discover that you don't have all the information you need, or that requirements are inconsistent or
duplicated. After you do some analysis, go back to your stakeholders to ask more questions and clarify
their answers. Don't worry, it can take several rounds to get a project's real requirements. Eventually, the
requirements will start to make sense. When that happens, it's time to document those requirements. To
ensure that the requirements are correct and everyone understands them, it's important to write them in a
clear, easy to understand language. Organizing requirements into related categories can help you
eliminate duplication and conflicts. Requirements provide detailed descriptions of what a project is
supposed to deliver, so it's important to get them right. For practice. Identify the techniques you might
choose to gather requirements for the hospital scheduling project and how you would address any
challenges.
Identify project deliverables and success criteria
- [Instructor] Put simply, project deliverables are the results that a project delivers. To determine whether
deliverables are what they're supposed to be, you need some way to measure them. Those measurements
are called success criteria. Deliverables can be tangible, like a building, a new product, or a new
service. They can also be more abstract, like improved results, say a decrease in reported
errors. Deliverables help you define the project scope, which basically means what is and isn't included in
the project. Deliverables then help you measure progress while your project is underway. To document
project deliverables, start by listing the end deliverables. That is the results your project delivers at the
end of the project. For example, one end deliverable for the scheduling project would be "new scheduling
system and processes launched". Next, document intermediate deliverables, which are delivered during
the course of the project. An intermediate deliverable for the scheduling project would be to sign a
contract with the scheduling system vendor. Keep in mind, the project customer doesn't necessarily
receive intermediate deliverables. For example, you might have an intermediate deliverable for
completion of initial system testing that the customer doesn't have to approve. Try to define deliverables
that can be accomplished in the timeframe between status reports, that way you can evaluate
progress based on the deliverables completed since the last report. Now that you've identified your
deliverables, how can you tell that the ones you receive are what the stakeholders want? You guessed
it, you need quantifiable criteria you can measure them with. Success criteria are definitions of what
success looks like. Some are easy to figure out, like signed vendor contracts or the certificate of
occupancy for a building. Other criteria are not so easy, because they're subjective. To be effective, write
success criteria that are clear and quantifiable. For the scheduling project, you might define success for
increased customer satisfaction as a four out of five rating on customer surveys. Deliverables are the
results your project is supposed to deliver. Success criteria help you determine whether those deliverables
are what you need. For practice, try to identify some end and intermediate deliverables for the hospital
scheduling project. Then define success criteria that are clear and quantifiable.
Identify project assumptions and risks
- [Narrator] Another aspect of defining a project is to identify project assumptions and risks. Let's start
with assumptions. During project initiation, there's a good chance you won't have all the information you
really need. Don't worry. You can make assumptions about that info so you can move ahead with the
project. Later when the project picture becomes clearer you can revisit your assumptions and modify
them if necessary. For example, with the scheduling project you won't know how much system
customization is needed until you choose the vendor, and that could affect how many in-house resources
you'll need which could affect how long the project takes. You get the idea. You might assume that the
system won't require much customization. From that, you estimate that you'll need three in-house IT
resources and they'll need a month to finish their part of the project. Assumptions can be tricky when
people don't realize they're assuming something. In that case, they assume something is true without
confirming it. Different people can make different assumptions. If those assumptions aren't brought into
the open someone will end up disappointed. For example, say that you assume that the system vendor is
going to load data into the database, and the system vendor assumes your internal IT group will do that
task. If that assumption isn't identified the system might miss an important deadline. The key is to get
assumptions out in the open. That way you can make sure everyone is on the same page. Think about
uncovering unspoken assumptions as you define and plan the project. Ask people what they expect and
what they envision when they think about the project. Don't be shy about asking more than once. Now
let's look at risks. A risk is a situation or event that might occur that could affect your project positively or
negatively. What makes a risk a risk is that it's uncertain. Early on in a project, spend some
time identifying risks that could affect the project mainly so the management team can make an educated
decision about whether or not to invest in the project. If you identify numerous risks and several are quite
worrisome management might decide it would be better to forego the project for another
one. Assumptions and risks are manageable as long as you identify them upfront. For practice, try
identifying a few assumptions and risks that could arise in the hospital scheduling project.
Prepare a project scope statement
- [Narrator] After all the work you put into defining your project, it's time to get that project definition in
writing. Project scope is the culmination of your definition work. It describes the boundaries of the
project, what is included in the scope of the project, and just as important, what isn't included. It's
important to get the project scope in writing. Otherwise, you're bound to run into scope creep. That isn't
some weird guy who casts furtive glances at your project scope. Scope creep is when stakeholders ask
questions like, "Can you do this one thing? "We forgot to ask for this. "Can you add it to the
project?" And you say yes without running the change through your change management process. The
other reason you want project scope in writing is to remind stakeholders what they agreed to at the
beginning of the project. If someone says, "I thought you were going to do "X, Y, and Z," you can go back
to the scope statement and show them that those items are out of scope. If they really want those things in
the project, you can use change management to add them. A scope statement is a document that spells out
the project's scope. Everything you've done during project initiation feeds into this document, the goal
and objectives, deliverables and success criteria, assumptions, risks, and constraints. Here's what is within
scope for the hospital scheduling project. Your scope statement also includes an out of scope section that
shows what the project doesn't include. For example, the scheduling project doesn't include an update to
the system used to assign staff to work shifts. Scheduling resident rooms in the hospital and rehabilitation
wing is also out of scope. Keeping scope under control is one key to a successful project. Use the scope
statement template in the Exercise Files folder to create a scope statement for the hospital scheduling
project.
Create a project charter
- Is the project definition done? Check. Is the scope statement ready? Check. Now you're ready to get
approval to move into planning your project. You also put together a project charter that officially
authorizes the project and publicizes it to the world. The whole point of defining a project is to give the
project customer or management team the info they need to approve the project. The review process
varies from organization to organization. Typically, the customer compares the project information to
acceptance criteria that align with the organization's goals. There are three possible outcomes from this
review. The project is approved to proceed to planning, it's denied, or it's sent back for rework. When the
project is approved, the final step in initiation is to create and distribute a project charter. This document
authorizes and publicizes the project. Here's what typically goes into a project charter. The name of the
project, the purpose of the project, a short summary of its goal and objectives will do, a high level project
description, which may include things like high level success criteria, requirements, scope, risks,
assumptions and constraints, a milestone schedule, cost estimate, and list of stakeholders. Remember,
you'll flesh out all of these components once you start planning your project. You also include
information about the project manager. The project manager's name, the project manager's
responsibilities, including a brief description of the work the project manager does, the extent of the
project manager's authority, and the specific work the project manager has authority to perform, such as
requesting resources or signing contracts. Finally, the charter includes a formal declaration of the
sponsor's support for the project. Think of this declaration as a power of attorney given to the project
manager by the sponsor or customer. You might wonder why a project charter describes the project
manager's authority. It's because project managers don't have the kind of authority that managers in a
structured organization do. Project managers' authority lasts as long as the projects they manage and
applies only to those projects. For that reason, it's important that people understand what a project
manager is authorized to do. When the project charter is ready to go, the project sponsor distributes it to
everyone affected by or involved in the project. Once the project has been authorized and your authority
as project manager is common knowledge, you're ready to begin planning the project.
Challenge: Project charter
(upbeat music) - [Instructor] For this challenge, review the hospital organization chart and the scope
statement from the chapter two exercise files. Remember that the project charter should include
information about the project manager's authority and the support that the project sponsor provides. The
exercise files include a challenge that poses several questions about the project charter for the Brislin
Hospital scheduling project. Take 20 to 30 minutes to answer those questions. After you've completed the
challenge, take a look at the solution to see what I came up with.