PROJECT MANAGEMENT

WHAT WE NEED TO KNOW

TODAY WE WILL LEARN:

• Understand the importance of defining a

project correctly.
• Learn what questions must be answered
to properly define a project.
• Understand how defining a project
relates to planning a project.
• Review the essential elements for a
Project Definition document.
• Planning!
SETTING THE STAGE FOR
SUCCESS!

Scope, Project Context,

Goals and Objectives
Purpose Project Dependencies
• What organizational level
• Why are we doing this? goal(s) does this project • How does this project fit
support? with the other projects that
are going on?

Scope Stakeholders Success Criteria

• What is the expected • How will we know when we
• Who is impacted by this and
benefit from this project? are done or whether the
who must be involved?
What are we going to do? project was successful?
 DEFINING PLANNING
VS A PROJECT
A PROJECT
Logistically Politically Practically Historically Financially

• Before you • You need to • The work to • People have • Effective

develop a know the key properly define a learned that execution of the
detailed and stakeholders are project is often detailed project project definition
complete project all in agreement not trivial. In fact, planning and process enables
plan, you need to with the project many process- general project the organization
know the mission (project focused and management are to leverage
parameters and purpose, goals, disciplined inefficient, and portfolio project
boundaries for objectives, and organizations difficult at best, if management
the project. success criteria) handle “project project definition processes. This
before definitions” as is not performed. allows the
proceeding separate projects. organization to
forward. Common better invest
examples include their limited
business case resources into
development initiatives that
projects, cost- offer the greatest
benefit analysis return.
projects,
selection
projects, and
assessment
projects.
 PROJECT DEFINITION
Purpose This section should answer the “Why?” question and clearly
communicate the expected business value. It should reference the
organizational objective being supported, the business problem being
solved, and its relative priority level.
Goals must be:
Specific
Goals and This section is derived from the Purpose and
communicates the targeted outcomes for the Measurable
Objectives project. It should answer the “What are you Agreed-To
going to accomplish?” question. Realistic
Timebased
Success Closely related to Goals and Objectives, this section should list the
measurable, verifiable results that will determine the success level of
Criteria this project. This section is often referred to as Critical Success Factors.

Project Documents how this project relates to other projects within the
product program and within the organization as a whole. This section
Context should also describe how the project fits within the organization and
business process flow.
 PROJECT DEFINITION
Project Closely related to Project Context, this section clearly documents any
Dependencies dependencies that could impact the results or success factors of this project.

Scope Clearly designates the organizational, process, systems, and functional

Specifications specification boundaries for the project. Should be high-level breakdown of
the Goals and Objectives.

Out-of-Scope To better communicate what is considered to be “in scope,” it is

Specifications recommended that you clearly indicate the high level work items that are
related (or associated) to this initiative, but that are not part of this project.

Assumptions This section clearly communicates the underlying basis or things to be

considered true in regards to any other aspect of this document. In most
cases, the Scope, Out-of-Scope, Assumptions, and Constraints sections
combine to clearly define what work will be performed by this project.
 PROJECT DEFINITION
Constraints This section lists any business event, schedule, budgetary, resource, or
technical factor that will limit the options available to the project.

Risks This section lists any uncertain event or condition (risk) that, if it occurs,
could have a negative impact on one or more project success criterion
(schedule, budget, quality, and so on). For each risk, it is good to list the
related causes, the perceived negative impacts, the likelihood it will occur,
and the planned response strategy and action items.

Stakeholders This section lists all the individuals, business units, and organizations
involved in the project, the role(s) each is expected to play, and an
indication of how they relate to one another. A Project Organization chart
and a Stakeholder-Role Description Table is highly recommended here.

Recommended To better describe the intent of the initiative, this section highlights the
Project recommended approach to getting the work of the project done and why
Approach it was selected over any other options. This section should note any key
strategies, methodologies, and technologies to be used.
IMPORTANT QUESTIONS TO
ANSWER

• CHECK IT OUT!
PLANNING
IMPORTANT QUESTIONS TO
TAKE INTO ACCOUNT

• CHECK IT OUT!
BUILDING A PROJECT PLAN

Determine Determine
Validate project
what needs to acceptance
definition.
be done. criteria.

Determine
Acquire Estimate the
resources
resources. work.
needed.

Update roles
Develop the
and
schedule.
responsibilities.
BUILDING A PROJECT PLAN

Determine Determine
Update project
project costs project control
organization.
and budget. system.

Plan for
Plan for
project Plan for issues.
change.
information.

Plan for Plan for team

Plan for quality.
communication management.
 WORK
THE BREAKDOWN
STRUCTURE
• It’s synonymous with a task list.
• The simplest form of WBS is the outline,
although it can also appear as a tree
diagram or other chart.
• Sticking with the outline, the WBS lists
each task, each associated subtask,
milestones, and deliverables.
• The WBS can be used to plot
assignments and schedules and to
maintain focus on the budget
 W
THE IMPORTANCE OF A B
S
Manage places.
Better work deffinitions, less changes.
Better estimates, better planning.
Better control
Clear responsibilities
Stakeholder buy-in on scope work effort
Tighter management integration
Better team performance
Risk factors are identified early
Confidence increases
GETTING STARTED
To start the work decomposition process, think
about the following:
• Does a template WBS exist as part of our methodology or from a
past project that I can use?
• What are the major deliverables?
• What is the project approach? The project lifecycle? The major
project phases?
• Think through the entire project. What does the “end” look like?

To continue the work decomposition process, think

about these questions:
• Can I break down this WBS element (deliverable) into sub-
components?
• How exactly will the deliverables be produced? What processes and
methods will be used?
• How do I ensure acceptable quality in deliverables and in the
process?
• Can I make adequate costs and duration estimates from this level of
detail?
 W
GUIDELINES FOR EFFECTIVE B
S

• CHECK IT OUT!
 WHEN TO STOP
Can each lower-level item be estimated, scheduled, budgeted,
and assigned to a responsible party?

Do I need more detail to make it easier to estimate effort, assign

work, track costs, or measure progress?

In addition, consider further decomposition of the lower-level

item, if any of the following are true:
• The work cannot be completed within the standard reporting period for the
project.
• There are specific risks associated with a smaller portion of the work
element.
• More than one individual or group is responsible.
• More than one deliverable is included.
• More than one work process is included.
• There is time gap involved.
• The resource requirements for the work element are not consistent.