Three levels of support a stake holder can have

Active support
Passive support
Neutral
 
The project is temporary—there is a beginning and an end. • The outcome of the project is unique
—that is, different in some way from anything else produced.
 
 
 
The project is temporary—there is a beginning and an end. • The outcome of the project is unique
—that is, different in some way from anything else produced.
 
 
 
Non-project work is known as operations. Operations involve the ongoing
creation of the goods or services of an organization. Examples of operations include the
production facility of a car company or the call centre of an insurance company.
 
Projects may also vary significantly in size. For example, for an insurance
company call centre department: • A small project could involve a review of recently completed
calls in order to recommend changes to the phone scripts used by the Customer Service
Representatives.
• A medium project could involve an upgrade of computer software to improve the call centre’s
automatic call routing.
• A large project could involve a relocation of the call centre to another city.
 
 
 
defines project management as “the application of knowledge, skills, tools, and techniques to
project activities to meet the project requirements
 
 
 
how best to organize the activities needed to complete the project. What follows is a basic process
for creating something new:
1. Determine the overall parameters of the project, such as why this project should be performed,
when it needs to be completed, and what funds are available to complete the project.
2. Plan the details of the work to be performed including what will be produced, when it will be
completed, and the resulting cost.
3. Produce the product, service, or result based on the planning.
4. End the project, comparing the results achieved to the original parameters of the project.
 
Each of the above steps is represented by a project phase. The collection of
phases representing the entire project is known as the Project Life Cycle (PLC).
 
The PLC used in this text is as follows:
• Initiating
• Planning • Executing • Closing
 
The following PLC will be followed throughout the first four parts of this
text as demonstrated in the diagram below. This form of project management is often called the
traditional waterfall method. The waterfall terminology comes from the idea that the work flows
from one phase to the next much like a waterfall flows downwards from one level to the next.
 
Projects are not performed in isolation but instead involve or impact individuals, groups, and
organizations known as project stakeholders.
Project stakeholders typically present during projects include:
• Project Sponsor - provides the fund. Does not actively manage project but overall guide the
project and make major decisions • Project Manager- actively manages the project ----TWO KEY
PROJET STAKEHOLDERS • Project Team • Customers • Managers • Suppliers • Government
 


What is the difference
between the Project
Sponsor and the Customer?
Is this the same role?
 
 
Related to project phases is the concept of process groups. The Project Management Institute
(2013) has grouped the processes of project management into five distinct groups:
 
•Initiating Process Group
• Planning Process Group
• Executing Process Group
• Closing Process Group
• Monitoring and Controlling Process Group
 
Related to project phases is the concept of process groups. The Project Management Institute
(2013) has grouped the processes of project management into five distinct groups: •
Initiating Process Group
• Planning Process Group • Executing Process Group • Closing Process Group • Monitoring and
Controlling Process Group
 
How Should Processes Be
Organized to Achieve the
Best Results???
 

The process to create
something new:
1. Determine the overall parameters
2. Plan for the details of the work
3. Produce the product, service, or
results
4. End the project, checking the
results against the original
parameters
 

 
Project Constraints
 
While customers would ideally prefer that a project produces as
much as possible, there are limitations to what can be achieved.
These limitations are known as project constraints. The three
fundamental project constraints, often referred to as the triple
constraint, are:
• Scope: the features and characteristics of the final project
• Time: the amount of time available to complete the project
• Cost: the budget available to complete the project
 
Over time, additional constraints have been recognized and added to the
original three constraints:
• Quality: the level of quality required for the project
• Resources: the availability of people, material, and equipment to complete the project
• Risk: the level of risk that is present for the project
 
 
The challenge for the Project Manager is to determine the best course of
action to take when constraints occur. The Project Manager must balance the satisfaction of the
customer with the performance of the project. Excellent communication and diplomacy skills are
required in order to arrive at an acceptable solution. A Project Manager’s skill in these areas often
means the difference between the success and failure of the project.
 
 
  You are working on a project with 5
team members. You have a
challenging:
 Amount of work to complete (Scope);
 Budget to meet (Cost);
 Due date (Time);
 Desired functionality and performance
(Quality);
 Desire for few or no problems (Risk).
As the project is about to begin, your team is reduced by one team
member. What is the likely effect on:
Scope? Cost? Time?
Quality? Risk?
 
 
 
 
two additional project-related structures that are often present within organizations: programs
and portfolios, and the corresponding disciplines of program management and portfolio
management.
 
When a number of projects in an organization share a common business objective, it is often
useful to group them together in order to coordinate their activities. This collection of projects is
known as a program and is managed by a Program Manager.
 
The Project Manager of each project within the program works under the direction of the Program
Manager.
 
A key benefit of program management is to increase the effectiveness of coordination between
projects in areas such as:
• coordinating decisions across projects; • coordinating schedules of projects; • coordinating
resources across projects.
 
 
For most organizations, there are usually a significant number of possible projects and programs
that the organization may undertake. However, due to financial and resource constraints,
organizations must choose a subset of these initiatives to perform at any one time in order to
achieve the strategic objectives of the organization. This subset of projects and programs is known
as the organization’s project portfolio.
 
The process of managing the content of the portfolio, including adding, prioritizing, and removing
its projects and programs, is called portfolio management.
 
A Portfolio Manager is a senior role within an organization due to the strategic nature of the work
involved.
 
A project is defined as a temporary endeavour undertaken to create a unique product, service, or
result.
 
Describe Project management is defined as the application of knowledge, skills, tools, and
techniques to project activities to meet the project requirements.
 
The Project Life Cycle (PLC) consists of the following four phases: Initiating, Planning, Executing,
and Closing.
 
Project stakeholders are individuals, groups, and organizations that are involved in, or impacted
by, a project.
 
The processes of a project are organized into five project management process groups: Initiating,
Planning, Executing, Closing, and Monitoring and Controlling.
 
The six project constraints are: scope, time, cost, quality, resources, and risk.
 
Programs are groups of projects that share a common business objective.
 
Portfolios are the project initiatives selected by an organization to perform in order to achieve the
strategic objectives of the organization.

Operations: The area responsible for the ongoing creation of the goods or services of an
organization.
 
Phase: A time period of the project when similar activities take place.
 
Portfolio: The collection of projects and programs that the organization actively manages in order
to achieve its strategic objectives.
 
Process Group: A group of similar or complementary project management processes. The f ive
process groups are initiating, planning, executing, monitoring and controlling, and closing.
 
Program: A number of projects that are related in some way, such as a common business
objective.
 
Project: A temporary endeavour undertaken to create a unique product, service, or result.
 
Project Constraints: Limits to what a project is able to achieve. The six project constraints are
scope, time, cost, quality, resources, and risk.
 
Project Life Cycle: A collection of project phases that represents the entire project.
 
Project Management: The application of knowledge, skills, tools, and techniques to project
activities to meet the project requirements.
 
Project Management Institute: A global professional organization that defines standards and
guidelines for the project management field.
 
Project Stakeholders: Individuals or groups who have some involvement or are affected in some
way by the project.
 
STARTING THE PROJECT
 

 
There are two main steps when starting the project: Starting the Project
 
The first step involves determining the feasibility of the project and results in the creation of the
Business Case . Assuming the project moves forward, the next step is to set the overall goals and
objectives of the project through the creation of the Project Charter . The project should then be
officially launched through a Project Kickoff Meeting with key project participants.
 
SHOULD THE PROJECT BE STARTED?
When starting a project, there are often a number of broad options to consider for how the
project may be implemented or even whether the project should be performed at all. Determining
the options and selecting the best course of action is known as creating the Business Case. The
advantage of this process is that it provides a clear direction and focus for the project.
 
When creating the Business Case, the likely costs are compared to the potential benefits.
Estimated costs may be tangible (e.g., labour costs)
 
or
 
intangible (e.g., increased risk of missing a deadline).
 
Benefits may be tangible (e.g., increased sales) or intangible (e.g., increased brand recognition).
 
Case Study Update: Creating the Business Case
 
Working late on a Friday afternoon, Sophie Featherstone is updating the final project documents
for a recently completed project. Sophie has been with Deco Productions for just over two years,
working as a Senior Project Manager in the Product Distribution department. As she packs up to
leave, her phone rings. Checking the call display, she sees that it is Arun Singh, Vice-President,
Mobile Products Distribution. “Hello, Sophie. Glad you’re still here,” says Arun. “I need you to
manage the product launch for the new version of DecoCam. This is the biggest update to
DecoCam that we’ve had. Its goal is a 5% increase in market share, so there is a lot riding on this
one. Given all the good work you’ve done over the last couple of years, I know you’re up to it.”
 
 
 
 
Creation of the Project Charter signals that the project has started and authorizes Project Manager
to proceed with the project.
 
The creation of a Project Charter is also used to ensure that there is agreement between the
Project Sponsor, Project Manager, and other key stakeholders.
 
The Project Charter will typically contain information such as the:
 
Project Goals and Objectives : Project goals define the destination of the project—that is, what the
project will achieve and how it will support the goals of the organization. Goals should be specific
and measurable. Objectives are the specific outcomes that are required in order to meet the
project goals.
 
 • Project Budget : The budget represents the funds that are available for the project. The amount
may be based on initial estimates performed during the Initiating Phase or may represent the
amount that was originally allocated for the project.
 
• Project Sponsor and Project Manager : The Project Sponsor and Project Manager are two
important roles required in order to proceed with the project.
 
• Additional Key Project Stakeholders : During the Initiating Phase, project stakeholders are
identified. Those stakeholders who will be actively involved in the project and play a significant
role are listed in the Project Charter.
 
• Overall project milestones : Significant points in the project, known as milestones, are listed in
the Project Charter. Examples of overall milestones are the start of the project and the target date
for the completion of the project.
 
• Overall Project Risks : Any risks (i.e., unexpected events that could affect the outcome of the
project) known at this point in the project should be listed in the Project Charter.
 
 


Something is needed to announce
the project exists and authorize the
Project Manager to proceed with the
project

The solution: the Project Charter

This document contains information
such as the:
 Project’s Goals and Objectives
 Project Budget
 Project Sponsor and Project
Manager
 Key Project Stakeholders
  Overall Project Milestones
Overall Project Risks
 
 

Launch the Project:

The Project Kickoff
Meeting

Particularly for larger
projects, a gathering of the
key stakeholders to officially
launch or “kickoff” the
project is advisable

This allows the key
stakeholders to interact and
questions or concerns to be
raised before the project
proceeds into the Planning
Phase
The agenda for this meeting should include the following: kickoff
• Introduction of the project stakeholders (if they have not previously met)
• Review of the organization’s strategy and goals
• Discussion of the project goals, objectives, and budget
• Overview of key milestones throughout the project
• Discussion of any known risks or current issues
 
 Key Concepts
In order for a project to start, the senior management of the sponsoring organization develops a
project concept.
 
Goals and objectives are defined for the project.
 
Key project roles include the Project Sponsor and Project Manager.
 
The project officially begins when the Project Sponsor approves the Project Charter. -yes
 
Business Case: A documented study to determine the costs and benefits of a proposed initiative
that will be used as a basis for future project work.
 
Milestone: An important event that occurs during a project.
 
Project Charter: A document that signals that the project has started and authorizes the Project
Manager to proceed with the project.
 
Project Kickoff Meeting is a meeting held to officially launch the project.: A meeting held with key
project stakeholders at the end of the Initiating Phase to officially launch the project.
 
Project Manager: The individual who is assigned to manage the project and ensure that the
objectives are completed.
 
Project Sponsor: The individual who provides the financial resources, support, and approval for
the project.
 
Planning Phase : STAKEHOLDER PLANNING
 
The purpose of stakeholder planning is not only to identify all of the project’s stakeholders, but
also to build effective and appropriate relationships with each stakeholder.- Two purpose of
stakeholder planning
 
There are two main steps when planning for project stakeholders:
“What are the characteristics of the stakeholders?”
“How can we manage the stakeholders?”
 
 The Total Float
For each activity, the total float is calculated as the difference between the earliest
an activity may start/end and the latest an activity may start/end. Therefore:
Total Float = LS – ES OR Total Float = LF – EF. The formula is equal to LS-ES

KICKOFF PROCESS The Project Kickoff Meeting

It is usually advisable for the Project Manager to schedule a Project Kickoff
Meeting once the Project Charter is published. Key project stakeholders including
the Project Sponsor, other senior managers, and project team members should
be invited to attend. The agenda for this meeting should include the following:
• Introduction of the project stakeholders (if they have not previously met)
• Review of the organization’s strategy and goals
• Discussion of the project goals, objectives, and budget
• Overview of key milestones throughout the project
• Discussion of any known risks or current issues
The desired result of this meeting is that the key stakeholders understand
and support the project. The meeting should allow for any issues or concerns to
be raised, as it will be more effective to address these early on rather than later
in the project.
The Project Sponsor should approve the Project Charter. This can be accomplished
at the Project Kickoff Meeting, if it takes place. With the completion of
the Project Charter and Project Kickoff Meeting, the project is ready to enter the
Planning Phase of the PLC.

Two documents are created when planning for stake holders : Stakeholder analysis plan &
Stakeholder management plan
WHAT ARE THE CHARACTERISTICS OF THE STAKEHOLDERS?
 
The stakeholders of the project were identified during the Initiating Phase.
During planning, this list is expanded as additional stakeholders are identified.
Each stakeholder is reviewed to assess their level of power, interest, and support.

During planning phase Each stakeholder is reviewed to assess their level of power, interest, and
support.

 
Examples of stakeholders
with high levels of power include: High power or high interest stakeholders are key players in the
project
• the CEO of the company (job position);
• the person managing resources for the organization (role);
• an industry expert in a field relevant to the project (perceived expertise).
 
 
Stakeholders who may have lower levels of power include:
• project team members;
• other managers in the organization;
• the general public.
 
 


For each project
stakeholder identified:

What is their level of
power?

What is their level of
interest?

What is their level of
support?
 
Level of Support
The third category for assessing stakeholders is their level of support, which may
be supportive, neutral, or unsupportive.
 
The Project Sponsor is normally a supportive stakeholder given that they
benefit from the results of the project. An example of a neutral stakeholder may
be a government regulatory agency, as they do not have vested interest in the
project’s outcomes. For certain types of projects, activist groups who oppose the
project are an example of an unsupportive stakeholder.
While not all stakeholders can or need to be supportive, moving stakeholders
from unsupportive to supportive is usually positive for the project.
 
The following is the template for the Stakeholder Analysis:
 

 
HOW CAN WE MANAGE THE STAKEHOLDERS?
 
The Project Manager should proactively cultivate these relationships
throughout the project.
While each stakeholder relationship is unique, some general approaches are
as follows:
• High power/high interest stakeholders: while all stakeholders are significant
to some degree, this type of stakeholder is a key player in the project.
The Project Manager should pay close attention to this stakeholder
and attempt to build as strong a relationship as possible.
 
• High power/low interest stakeholders: given their high degree of power,
these stakeholders are also important. Their lower level of interest necessitates
that the Project Manager’s main priority is to understand the
needs and requirements of this stakeholder and ensure they are met.
 
• Low power/high interest stakeholders: focus on providing this stakeholder
with information that keeps them well-informed.
 
• Low power/low interest stakeholders: this stakeholder should be periodically
monitored in order to detect any change in power or interest.
 

Stakeholder Management Plan

 Key Concepts
1. Identify the stakeholders of the project.
2. Analyze their characteristics in order to determine their level of power, interest, and support.
3. Document this information in the Stakeholder Analysis.
4. Develop plans to interact with each stakeholder and document this information in the
Stakeholder Management Plan.
 
Interest: The stakeholder’s level of concern or engagement that they have with a project.
 
Level of Support: The attitude the stakeholder displays toward the project, ranging from
supportive to neutral to unsupportive.
 
Power: The stakeholder’s ability to affect the project.
 
Stakeholder Analysis: A planning document listing the stakeholders of the project and
including their perceived power, interest, and level of support.
 
Stakeholder Management Plan: A planning document containing the Project Manager’s
planned actions to manage each stakeholder relationship.

Stakeholder Management Plan: A planning document containing the Project Manager’s

planned actions to manage each stakeholder relationship.

The primary components of a stakeholder management plan are:

A list of all known stakeholders. Include their name, role or position, and
contact information.

1. Prioritization of stakeholders. Rank stakeholders based on their

ability to influence your project and how much they care about its
outcome. 
 2. Stakeholder expectations. You cannot manage expectations if
you don’t know what they are. You must document everything,
including how they prefer to communicate and what they want to
be involved with. 

3. Communication rules. The plan should outline the level,

frequency, and type of communication with each stakeholder as
well as who on the team is their point of contact. 

4. Action plans. This is the meat of your plan — It’s where you
outline how you will manage stakeholder involvement and what
steps to take to ensure expectations are met. 

 The most common dependency relationship is a finish-to-start relationship.

 

Scope Planning
 Three documents when planning for project scope
There are three main steps when planning the project scope:
“What do the project stakeholders need?”
“What will the project produce?”
“What are the details?”

The first step is to determine the list of items needed for the project. These
items are documented in the Project Requirements.
The next step is to determine
what the project will actually produce.
The output of this step is the
Work Breakdown Structure.
The final step is to fully describe the features and
characteristics of everything that will be produced. The output of this step is the
Project Scope Statement.
 

What Do the Project

Stakeholders Need?

In order to define the project
scope, the needs
(requirements) of the project
stakeholders are determined

Requirements may be gathered
in many ways, including:
 Interviews with stakeholders
 Surveys
 Focus groups
 Research
 
WHAT WILL THE PROJECT PRODUCE?
Once the requirements are known, the scope of the project may be defined. The
scope is the product, service, or result created during the project.
The first step in
defining the scope is to create a Work Breakdown Structure (WBS) for the project.
 
2nd
 
The Project Scope Statement

WBS
 
When defining the WBS, the idea is to continue to break down each deliverable
until the work involved is understood and may be assigned to a person
or team for completion. A WBS contains all of the deliverables to be produced
during the project. In order for something to be produced during the project, it
needs to be included in the WBS—if it isn’t in the WBS, it won’t be done.
 
High-level deliverables may be broken down into smaller
deliverables. A deliverable at the lowest level of a WBS (i.e., a deliverable that is
not broken down further) is also referred to as a work package.
 
There are various approaches that may be used to create a WBS:
• A top-down approach to identify the high-level deliverables and then
progressively break them down into their work packages. This is the approach
used in the case study.
• A bottom-up approach to first identify work packages and then group
them together to create the structure of the WBS. This can be a useful
approach when the high-level deliverables are not obvious to the
project team.
• An approach using a similar project’s WBS as a starting point and then
making changes as appropriate.
• An approach using a standard WBS as defined by an organization.
 
When creating a WBS, a combination of any of the above approaches may
be used. The goal is to develop an effective WBS that contains everything that
needs to be produced during the project.

 
A common question when creating a WBS is determining when to stop
breaking deliverables down into smaller deliverables. A good approach to use is
that a deliverable does not need to be broken down further if the person or team
responsible for its creation understands the work involved.

 
While a WBS should contain all of the deliverables to be produced, there is
information that should not be included:
• Scheduling information: a WBS does not contain dates or indicate the
order that the work will be performed. Deliverables and work packages
should be considered to be listed at random.
• Cost information: a WBS does not contain any cost information.
• Detailed specifications: a WBS does not contain a description of the
deliverables.
 
Technically, a WBS would also include all project management deliverables
produced during the project, including work packages such as the Project
Charter, Project Requirements, and Project Scope Statement.
WHAT ARE THE DETAILS?
When defining the scope of the project, it is important to determine the characteristics
of the work packages in the WBS. Determining this information
often involves a series of meetings, conversations, emails, and other communications
over a period of time ranging from days to months. In order to ensure
that everyone involved in the project has access to the same information, the
work package characteristics should be summarized and documented in the
Project Scope Statement.
 
The Project Scope Statement also explicitly defines what is not included in
the project. For example, in the case study, the decision was made that the project
team would not be involved in the set up of new materials at trade shows. To
help ensure that everyone is aware of this decision, the Project Scope Statement
should state that this work is not to be performed.
The advantage of creating this document is that it becomes the document
of record for the project and may be used to verify the scope with the Project
Sponsor and other stakeholders. It is a key communication tool to ensure that
there is a common understanding of the project scope. The Project Sponsor
should provide specific approval of the Project Scope Statement.
 
The following is the Project Scope Statement template:
 
 
OTHER SUPPORTING DOCUMENTS
While the Project Scope Statement contains a description of what is (and is not)
contained in the scope of the project, there are often additional details that do
not fit easily into the structure of the Project Scope Statement. The Project Scope
Statement may refer to other supporting documents, such as:
• mural design and layout information;
• promotional video storyboard and script information;
• online slideshow design; or
• other documents that support the description of the project scope.
 
In summary, the scope of the project consists of the Project Requirements,
the WBS, the Project Scope Statement, and all of the supporting documents that
describe the content of the project.
 
Key Concepts
1. Gather the project requirements from the project stakeholders.
2. Create a Work Breakdown Structure (WBS) that defines the deliverables to be created during
the project.
3. Create a Project Scope Statement that describes the deliverables contained in the WBS.
4. Supporting documents that describe the scope of the project may be appended to the
Project Scope Statement in order to more fully describe the project scope.
Key Terminology
 Deliverable: Something that is produced during the project. The collection of all deliverables
comprises the scope of the project.
Project Requirements: A planning document that describes the items and capabilities
needed for project output.
Project Scope Statement: A planning document that fully describes the deliverables contained
in the WBS.
Scope: The product, service, or result created during the project.
Work Breakdown Structure: A hierarchical document listing the project deliverables to be
produced during the project.
Work Package: A deliverable that is at the lowest level of the WBS and is not further divided
into sub-deliverables.

What Is a Project Deliverable?

Definition, Examples & More
Projects create deliverables, which are simply the results of the project or the
processes in the project. That means a deliverable can be something as big as
the objective of the project itself or the reporting that is part of the larger
project.

Another way to put that is that there are inputs and outputs in any type of
project. That being what you put into the project, such as data, resources, etc.,
and then what comes out, which are the deliverables. Again, those deliverables
can be a product or service and it can also be the documentation that is part
of the project closure to show that the project is complete and everything has
been signed off.

A deliverable is something that is produced during the project.

A deliverable at the lowest level of a WBS (i.e., a deliverable that is

not broken down further) is also referred to as a work package.

 Type of Deliverables

Deliverables are usually classified as internal deliverables and external deliverables.

1. Internal Deliverables

Internal deliverables are usually deliverables that make a project run, but they are not
a part of the product that the end-users would like to see. They are deliverables which
the project generates internally. Project Management, Configuration Management,
Training, and Testing are some examples of internal deliverables.

2. External Deliverables

External deliverables are usually those that the project delivers to the users or the
client. An external deliverable could be an IT system and subsystems that make it up
or the resulting organizational transition and benefits from a project to reduce the
turnaround time of a process.

Additionally, project management professionals are also known to classify these

deliverables by type, as follows.

1. Project Deliverables: Usually, these are deliverables for the external stakeholders.

2. Planning Deliverables: Management plans, scheduling, and budgeting, project

artifacts, etc.

3. Activity Deliverables: Status reports, meetings, reviews, etc.

SCHEDULE PLANNING
 
Once the project scope is defined, the next step is to create a schedule. The development
of a schedule is beneficial for the following reasons:
 
It allows the project team to make commitments to its stakeholders
about the final delivery date as well as interim deliverables.
• Everyone involved in the project is able to see their efforts within the
context of the whole project and understand the connections and interdependencies
that may exist.
• It provides an established project timeline that may be used to track the
 progress of the project. This established timeline is known as a baseline.
 
There are two main steps when planning the project timeline:
 
“What are the activities of the project?”
“When will the activities be performed?”

what is the first step in planning a project schedule? – Activity list

Two docs when planning a project timeline

The first step is to create a list of the project activities required to complete
the project. The next step is to arrange the activities in logical order.

next step is to create a schedule.

WHAT ARE THE ACTIVITIES OF THE PROJECT?

For each deliverable of the project, the activities needed to create the deliverable
are defined. Depending on the project, a larger number of detailed activities or
a smaller number of general activities may be needed. To help determine the
number of activities, the following criteria can be used:
• Each activity should be clear to those who will perform the activity. If it
is unclear, additional activities are required.
• The duration of each activity (i.e., the total amount of time available for
the activity) should be moderate. Extremely long activity durations (e.g.,
30 days) may be challenging to manage, especially if the work is complex.
Extremely short activity durations (e.g., 10 minutes) will result in
a large number of activities that in turn increase the size and complexity
of the resulting schedule.
• Each activity should have an identifiable person or group who will be
responsible for its completion.
 
WHEN WILL THE ACTIVITIES BE PERFORMED?
Now that a list of activities has been determined, the next step is to create the
schedule for the project. This involves considering the timing of the activities.
 
This timing of activities is based on:
• the required sequence of activities based on the work involved, also
known as determining the dependencies between activities;
• the completion of activities by a certain date.
 
 
Creating the Network Diagram
A useful tool for displaying the sequence of activities is a network diagram,
which displays the project’s activities as follows:
• Each activity is represented by a rectangle.
• The network diagram is read from left to right on the page.
• The lines indicate a dependency between the activities.
 
 
Estimating Activity Duration
An important characteristic of each activity is the estimated duration. Developing
accurate duration estimates can be challenging for a number of reasons:
• Given the unique nature of projects, the activity may not have been performed
before, making it difficult to determine its likely duration.
• Unforeseen problems can cause the activity to take longer than estimated.
• The expertise of the person(s) working on the activity affects the duration.
Often, their identity is not known when the estimate is created.
There are a number of techniques that are helpful when creating duration
estimates, including the following:
• Using the experience of past projects as a guideline for the current estimate.
This may be based on the experience of the person making the
estimation or through consultation with others.
• Analyzing the actual work required for the activity in order to develop
the estimate.
 
When creating activity duration estimates, the more detailed the scope of
the project, the more accurate the estimates tend to be.
Given the difficulty and potential for inaccuracy when estimating duration,
it is usually advisable to allow extra time in the activity for unforeseen work or
issues. This is known as adding contingency to the duration. This contingency
may be placed in each activity duration estimate or as a total amount at the end
of the project. However, the use of contingency time may not be viewed positively
by all stakeholders. Some may view it as an attempt by the project team
to pad the estimates and needlessly increase the overall duration and cost of the
project. Effective communication is required in order to demonstrate the use and
 benefit of allotting or using contingency time.
 
The main benefit of creating a network diagram is that it clearly displays the
order of the activities and in particular the dependencies between the activities.
However, network diagrams are not effective at displaying the dates that
activities are planned for and are difficult to maintain throughout the project.
Because of these limitations, they are often useful for initial planning purposes
but are not subsequently maintained throughout the project.
 

Difference between Deliverables & Milestones

A deliverable is a measurable and tangible outcome of the project.
They are developed by project team members in alignment with the
goals of the project.

Milestones on the other hand are checkpoints throughout the life of the
project.
They identify when one or multiple groups of activities have been
completed thus implying that a notable point has been reached in the
project.

What is a project milestone?

 Can be conceptual or tangible
 Signals the reaching of a key stage in the project
 An important sign for the team
 A point for project management to check project goal alignment
What is a project deliverable?
 Must be tangible (i.e. a product or service)
 Signals the completion of a project phase
 An important sign for the client
 A point for the client to sign-off on project status

Milestone vs. deliverable: What’s the same and what’s different?

As you can see from the above characteristics, there IS considerable overlap
between project deliverables and project milestones. For example, a particular
deliverable may coincide with a certain milestone or vice-versa. But ultimately,
deliverables and milestones represent two distinct – if often parallel – tracks along
which projects are measured and carried out.
Let’s dive a little deeper into the distinctions.

Tangible vs. intangible

One of the major differences between milestones vs. deliverables is that a
deliverable must represent something tangible – a concrete product or service,
such as a piece of software or a marketing video – whereas a milestone can simply
be a conceptual change or moment.

You may still be wondering, So exactly what is a project milestone, then? An example
would be, when building a house, the stage where you get sign-off from the safety
inspector or town planner. This is a milestone that signals the movement into a new
phase of the project, but it isn’t a deliverable because you’re not necessarily providing
anything tangible to the client.

While a client may be well aware of a project’s milestones and ask to be kept up to
speed with them, they are mostly for internal use, i.e. being used as a focus point
for the team and management. They represent a moment when a project condition
has been satisfied and give management the opportunity to assess performance so
far.
A deliverable, on the other hand, is something which concerns both the team and
the client, which is also why all deliverables can be considered as milestones. A
deliverable is when a client has input on how it believes the project is going and
gives them the opportunity to assess performance.

Tracking milestones and deliverables can become a hectic process, especially when it
needs to be done across multiple projects. Fortunately, project management software
like Clarizen can provide automated calendar reminders as well as giving extensive
visibility into team progress towards both. To find out how we can help your project
hit its milestones and deliverables on time and within budget, talk to our team
today to organize a live demo.

The Project Schedule

 
 
In addition to the Network
Diagram, there are many different
types of project schedules types
that may be used

There is no “one way” to create a
schedule - the amount of detail
and complexity required in a
schedule depends on the
characteristics of the project

The three main types to be
discussed are:
 Milestone-based
 Activity-based
 Dependency-based
The Milestone-Based Schedule
Milestones are important events that occur during a project. They are not regular
activities that are measured by the duration and work involved, but are instead
an indicator that something significant has been completed during the project.
Milestones were first defined during the creation of the Project Charter.
They are often further defined during planning.

 
Milestone-based schedules are simple to use and understand, can be easily
accessed by team members and stakeholders, and will likely require minimal
updates during the project.
However, since activities are not contained in the schedule, they will need to
be managed outside of the schedule. This may make it more difficult to plan for
project costs and resources.
Milestone-based schedules are often appropriate for small and/or simple
projects.

 
The Activity-Based Schedule
The activity-based schedule contains the project’s activities and includes information
such as the duration, start date, and end date of each activity.
 
For certain types of projects that have fixed end dates, such as events, a
work-back schedule may be used. A work-back schedule is a specific type of
activity-based schedule in which the timing of each activity is determined by
working backward from the project’s end date. For example, during the case
study, the project must be complete (except for the project closing) by May 8th.
Working backward from this date, it is determined that:
• the video script should be created three weeks before this date
(April 17th);
• the video storyboard should be created four weeks before this date
(April 10th).
Using this work-back method, the remainder of the activities are planned
relative to the project’s end date.
Activity-based schedules may also be implemented as a series of lists using a
workflow approach, such as a Kanban schedule. Kanban is a scheduling system
originally developed at Toyota to improve its manufacturing process.
Using this method, a board representing the project is divided into multiple
lists. Each list contains activities at different stages of the project.
 
For
example, the board may be set up to contain three lists: To-Do, Doing, and
Done. At the start of the project, all activities are contained in the To-Do list.
The project team will then select which tasks to work on first and move them
to the Doing list. As activities are completed, they are moved to the Done list.
At any point in the project, the content of the board visually demonstrates the
status of the project.
Using a workflow approach, the case study project would appear as follows
during the third week of the project:

 
Activity-based schedules are simple to use, straightforward to update, and
may be easily accessed by team members and stakeholders during the project.
However, this type of schedule does not demonstrate the dependencies that
may be present between activities. Changes to the timing of activities during the
project could cause problems if these dependencies are not considered.
Activity-based schedules are often appropriate for small to medium-sized
projects.

 
The Dependency-Based Schedule
Similar to the activity-based schedule, the dependency-based schedule contains
all project activities along with their durations, start dates, and end dates.
Additionally, this type of schedule displays any dependencies that may be present
between activities.
This type of schedule is usually created using project management software
and displayed in the Gantt Chart format. The Gantt Chart is named after
Henry Gantt, an engineer and management consultant who developed the project
management tool during the 1910s.
A Gantt Chart is divided into two sections. On the left side is a spreadsheet
with each row representing an activity of the project. On the right side is
a timeline made up of horizontal bars that represent the duration and timing
of each activity. Dependencies are represented by an arrow between activities.
Milestones are represented by a diamond shape.
The following is the dependency-based schedule for the case study project
using the Gantt Chart format:

 
The main advantage of the dependency-based schedule is that it clearly demonstrates
the timeline of the project including the dependencies between activities.
If changes are made to the timing of activities during the project, the impact
on other dependent activities is displayed.
Due to the complexity of this type of schedule, more time is required for its
maintenance and project management software is usually required to view or update
the schedule. This results in the schedule being less accessible to the project
team and other stakeholders.
Dependency-based schedules may be appropriate for large and/or complex
projects
Dependencies

Finish-to-Start (all
dependencies displayed so
far)

Start-to-Start Dependencies

Finish-to-Finish
Dependencies
all the dependencies described are known as Finish-to-Start
(FS) dependencies. This is the most common type of dependency where the first
activity must finish before the second activity may start. The majority of dependencies
are FS.
There are other, less common dependency types that may occur during projects.
A Start-to-Start (SS) dependency occurs when two activities must start at
the same time but may finish at different times. For example, the “create outreach
list” and “perform outreach” activities could have been defined with an SS
dependency. This would be appropriate if creating the outreach list also involved
performing outreach (e.g., testing some of the names that were placed on the
outreach list). This dependency type appears on a Gantt Chart as follows:

 
 
Critical Path Analysis
 
For this project, there are two paths through the network:
• Select vacation destination à apply for passport à depart for vacation
(13 days)
• Select vacation destination à book vacation à pack for vacation à
depart for vacation (5 days)
The first path (13 days) is the critical path since it is the longest sequence of
dependent tasks and therefore represents the earliest time that this project may
be completed. In other words, it would take 13 days for you to be sitting in an
airport, with your tickets, suitcases, and passport in hand.
 
Another concept related to the critical path is total float. Total float is the
amount of time an activity may be delayed before it delays the project end date.
A related concept is known as free float. Free float is the amount of time an
activity may be delayed before it delays a subsequent task or the project end
date. Throughout the remainder of this text, total float will be discussed and
calculated.
 
 
By definition, all activities on the critical path have zero total float in that
a delay in any activity on the critical path will delay the end of the project. The
two activities that are not on the critical path—“book vacation” and “pack for
vacation”—share a total of eight days of float. This can be deduced by calculating
that during the ten days required for the “apply for passport” activity, two days
are required to complete the “book vacation” and “pack for vacation” activities.
This leaves eight remaining days of total float. Therefore, the two activities may
be delayed up to eight days without impacting the project’s completion date.
 
 
CRITICAL PATH ANALYSIS—THE CALCULATIONS
 
Calculating the critical path involves looking at the schedule in two distinct
ways:
 1. Determining the earliest date that each activity may occur by performing a
forward pass of the schedule. This will determine the Early Start (ES) and
Early Finish (EF) times for each activity.
2. Determining the latest date that each activity may occur by performing a
backward pass of the schedule. This will determine the Late Start (LS) and
Late Finish (LF) times for each activity.
 
The following table is an activity list that includes the duration and predecessor for a series
of project activities. What is the duration of the critical path?
 Start serves as predecessor for both A and E, creating a divergence into two paths. 
Activity A serves as predecessor for both B and C, creating another divergence.

Activity E serves as a predecessor for both B and F, creating another divergence.

The resulting list of paths with their aggregated duration is below. The critical path is
Start-E-B-D-End, and the duration of the critical path with the data given is 14.
18

Several individual housing projects done in the same area by the same firm might best be managed as
part of a _______________.
B. program

Work Package: A deliverable that is at the lowest level of the WBS

Is a deliverable-oriented grouping of the work involved in a project that defines the total
scope of the project *?
Work breakdown structure

Key Concepts
1. Using the WBS as a starting point, create an Activity List consisting of one or more activities
defined for each work package.
2. Create a project schedule by defining the dependencies between the activities and required
activity dates.
3. There are many formats of project schedules, including network diagrams, milestonedriven
schedules, activity date-driven schedules, and activity dependency-driven
schedules.
4. There are four dependency types: Finish-to-Start, Start-to-Start, Finish-to-Finish, and
Start-to-Finish. Start-to-Finish dependency types are rare and are not covered in detail
in this text.
5. Activity timing may be affected by the amount of lead or lag defined by the Project
Manager.
6. Understanding the critical path allows the Project Manager to determine the total project
duration and the impact of activity delays on the project’s completion date.

Key Terminology
Activity List: A list of all activities defined for the project.
Activity-Based Schedule: A schedule containing the dates of the activities defined for the
project.
Backward Pass: A process that involves moving backward through the project schedule in
order to determine the latest date that each task can start and finish.
Baseline: An approved part of the project plan, such as the scope, cost, or schedule. It may be
used as a basis for comparison when measuring the progress of the project or considering
potential changes to the plan.
Critical Path: The longest sequence of activities in the project schedule. This sequence of activities
represents the earliest planned completion time for the project. Determines the sequence of activities
Dependency: The required sequence of activities based on the work involved.
Dependency-Based Schedule: A schedule containing the dates and dependencies of the activities
defined for the project, often displayed in the Gantt Chart format.
Duration: The total amount of time required to complete an activity. Does not include nonworking
days such as weekends or holidays.
Early Finish: The earliest time that an activity may finish in a project schedule taking into account
the defined dependencies and any other scheduling constraints.
Early Start: The earliest time that an activity may start in a project schedule taking into account
the defined dependencies and any other scheduling constraints.

Forward Pass: A process that involves moving forward through the project schedule in order
to determine the earliest date that each task can start and finish.
Free Float: The amount of time an activity may be delayed before it delays a subsequent task
or the project end date.
Gantt Chart: A chart illustrating the dependencies between activities in a project schedule,
where activities are listed in vertical rows and activity durations are represented as horizontal
bars.
Lag: The delay or gap of time between two dependent activities.
Late Finish: The latest time that an activity may finish in a project schedule taking into account
the defined dependencies and any other scheduling constraints.
Late Start: The latest time that an activity may start in a project schedule taking into account
the defined dependencies and any other scheduling constraints.
Lead: The amount of overlap time between two dependent activities.
Milestone: An important event that occurs during a project.
Milestone-Based Schedule: A schedule containing the dates of the milestones defined for
the project.
Network Diagram: A graph that demonstrates the sequence of activities during the project.
Activities are represented as rectangles, and dependencies between activities are represented
as lines.
Total Float: The amount of time an activity may be delayed before it delays the project end
date.
Work-Back Schedule: A specific type of activity-based schedule in which the timing of each
activity is determined by working backward from the project’s end date.

A project is already running behind a schedule

For example, let’s say that a project is already underway when it becomes
apparent that the project’s target date may not be met. Rather than delaying the
project, the Project Manager looks at the following options:
• Overtime could be scheduled or additional workers could be added to
the project. However, this tends to increase the costs of the project (that
is, it affects the cost constraint), and additional workers may not be available
(resource constraint).
• The workers could attempt to work faster and get more work done in
the remaining time. However, this tends to cause problems (quality
constraint) and may damage the reputation of the organization (risk
constraint).
• A discussion could be held with the project sponsors in order to reduce
the results of the project (scope constraint).
This example demonstrates an important characteristic of constraints: when
one constraint changes, it often impacts many if not all of the other constraints.
One would hope that changes to constraints would be a rare event on a project.
Unfortunately, they are relatively common. During projects, budgets often
change, schedules change, resources are unavailable or delayed, changes to the
scope of the project are proposed, and so on. Managing the interaction between
project constraints becomes an ongoing task.
The challenge for the Project Manager is to determine the best course of
action to take when constraints occur. The Project Manager must balance the
satisfaction of the customer with the performance of the project. Excellent communication
and diplomacy skills are required in order to arrive at an acceptable
solution. A Project Manager’s skill in these areas often means the difference
between the success and failure of the project.

Project management is about knowing exactly what your

goals are, how you’re going to achieve them, what
resources you’ll need, and how long it will take you to
reach that specific goal. In fact, project management’s
goal is to make sure that everyone involved in a project
knows these and is aware of the purpose of the project.
Project management is a process that includes planning, putting the project plan into action, and
measuring progress and performance.

Managing a project includes identifying your project’s requirements and writing down what
everyone needs from the project. What are the objectives for your project? When everyone
understands the goal, it’s much easier to keep them all on the right path. Make sure you set goals
that everyone agrees on to avoid team conflicts later on. Understanding and addressing the needs
of everyone affected by the project means the end result of your project is far more likely to
satisfy your stakeholders. Last but not least, as project manager, you will also be balancing the
many competing project constraints.

The phases of project management are:

Stage 1: Initiation 
This phase of project management marks the beginning of the project and is where
the project charter is developed, and stakeholders are identified.

Stage 2: Planning
This is where the project plan is developed. That means costs are estimated,
resources are determined, and requirements (scope and work breakdown
structure) are defined. This is also where risk is identified and planned for, and
where communications are built.

Stage 3: Execution
This project phase is where the project is carried out, all while procuring resources
and managing stakeholder expectations.

Stage 5: Closing
This stage of project management is where the project is finalized, the deliverable is given
to the customer, stakeholders are told of the completion of the project, and all resources
are released back to their resource managers.

3. In which process group should you spend the most time and money? Executing
4.  Approximately how much time do good project managers spend on each
process group and why.
5. Andy Crowe's research found that alpha project managers spend about 2% of
their time initiating, 21% planning, 69% executing, 5% monitoring and controlling,
and 3% closing projects. The most time should be spent on executing, followed
by planning.

A pro A project manager is leading a project to investigate the feasibility of constructing a

dam to generate hydroelectric power. The project needs to be analyzed from technical,
economic, and social points of view. The project manager has created the project charter on
behalf of the project sponsor, and it is now approved. Which of the following processes should
be performed next?

The Identify Stakeholders process is the process of identifying all people or organizations
impacted by the project and documenting relevant information regarding their interests,
involvement, and impact on project success. Both the Develop Project Charter process and the
Identify Stakeholders process are part of the Initiating Process Group which should be
completed before proceeding to the processes in the Planning Process Group. In this scenario,
since the project charter has been developed and approved, the Identify Stakeholders process
should be performed next.ject manager is leading a project to investigate the feasibility of
constructing a dam to generate hydroelectric power. The project needs to be analyzed

fr

Answer : C
The Identify Stakeholders process is the process of identifying all people or organizations impacted
by the project and documenting relevant information regarding their interests, involvement, and
impact on project success. Both the Develop Project Charter process and the Identify Stakeholders
process are part of the Initiating Process Group which should be completed before proceeding to the
processes in the Planning Process Group. In this scenario, since the project charter has been
developed and approved, the Identify Stakeholders process should be performed next.
om technical, economic, and social points of view. The project manager has created the
project charter on behalf of the project sponsor, and it i
s now approved. Which of the following
PROJECT SPONSOR VS PROJECT MANAGER

1. During the concept phase the project sponsor will be responsible for defining the
requirements and benefits for the business case with the support of the project
manager.  An example is where there is a requirement to build a nursery room at
a local primary school – the sponsor will have to talk to all the stakeholders to
the the strongest business case possible while the project manager will support
the sponsor in gathering contractor costs based on the requirements.  
2. The definition phase requires much more involvement from the project manager.
The project manager will work with the contractors and team to have enough
detail in order to get the approval to continue into the development phase for the
new nursery room.   At this stage the project management plan is written and owned
by the project manager.  The PMP provides detail on how the project will be run and
is the responsibility of the project manager.  The project sponsor will oversee the
project managers work at this stage and sign the PMP off. 
3. The development phase is when the project manager are responsible for the day to
day running of the project according to the project management plan an example of
this will be managing  and co-ordinating the contractors involved in building the
new nursery.  The sponsor will oversee the project managers work and there will be
stage reviews where the sponsor will provide acceptance to the project manager to
continue to the next stage i.e. once foundation are laid the sponsor will sign off the
stage.  During this phase the project manager will escalate any risks or issues they
encounter and cannot resolve to the sponsor who will work with the Project manager
to resolve.  Any changes will pass to the sponsor who will arbitrate between
requirements and accept and reject changes as relevant.
4. During the handover and close stage the project manager will handover the
deliverables to the users i.e. the new nursery room to the school.  The sponsor will
liase with the users to sign off whether the deliverables are fit for purpose.  A lessons
learned workshop will be held and will involve input from the sponsor and project
manager to ensure any lessons learned are captured and shared with similar
projects going forward.
5. Once the project has been handed over the project manager takes a step back.  The
project sponsor will then be responsible to ensure that the project delivered against the
requirements and realise the benefits in the business case i.e. the new nursery room
provides much needed spaces for the local community 
Project Sponsor:  A person or group who provides resources and support for the project, program or
portfolio and is accountable for enabling success.

1. Promotion.  They are the project champion that attempts to keep the project at the
highest priority within the organization.
2. Authorization.  They authorize the project and assign the project manager.
3. Funding.  They are responsible for ensuring funding is in place and approving changes
to the project budget.
4. Approving.  They approve the project management plan and are kept aware of how
the project is managed.
5. Scoping.  They are generally responsible for determining the initial project scope,
although the project manager is ultimately responsible for the official project scope
within the project management plan.
6. Project Charter.  This document officially creates the project and assigns the project
manager.  It falls directly within the project sponsor’s responsibility.
7. Informing.  They receive project status updates from the project manager and
disseminate the information to the relevant executives.
8. Receiving.  The project sponsor receives the project deliverables from the project
manager, approves them, and integrates them into the owner organization.

The project sponsor is one (and only one) level above the project manager.  While the project
manager is responsible for the day to day operations of the project, the project sponsor seeks to
promote the project to keep it high on the priority list, ensures the resources are in place to perform
the project, and approves changes to the project.

  Project Sponsor Project Manager

Day to Day management of project

No Yes
work

Project Deliverables Accepts Produces

Funding Approves Requests

 Project Manager:  Responsible for the day to day project work, keeping the project on
schedule and budget.  They report to the Project Sponsor.
The goal of WBS in project management is to make a large project
manageable. It helps you to:
 Develop a schedule
 Determine the cost of the project
 Set dependencies
 Write a statement of work 
 Assign responsibilities and clarify roles
 Track the progress of a project
 Work breakdown structure describes the “what”  of the project. It
doesn’t include timelines or resources. 
 A project schedule is the “what”, “when”,  and “who” of the project
includes the project’s deliverables as well as their deadlines and
resource requirements. 
 A project plan includes details on how the project will be executed,
managed, and controlled covering every aspect of the project. 
 the scope of the project consists of the Project Requirements,
 the WBS, the Project Scope Statement, and all of the supporting documents that
 describe the content of the project.h

 it defines and organizes the work required

 it facilitates the quick development of a schedule by allocating effort estimates to
specific sections of the WBS
 it can be used to identify potential scope risks if it has a branch that is not well
defined
 it provides a visual of entire scope
 it can be used to identify communication points
 it provides a visual of impacts when deliverables are falling behind
 it can be used to show and assign accountabilities and responsibilities
 it can show control points and milestones
 it provides a way to estimates project costs
 it ensures no important deliverables are forgotten
 it can assist with resource allocation
 it provides a proven and repeatable approach to planning projects

 it provides a tool for team brainstorming and collaboration

 it provides an opportunity to engage the team and make them feel invested in the
planning
A top-down approach to identify the high-level deliverables and then
progressively break them down into their work packages.

The top-down approach to defining project tasks involves starting

with the project goal or final deliverable and breaking it down into
smaller planning chunks. We call them work packages. Each of
these work packages or “chunks” is further refined into greater
detail, and then work items are assigned to team members.

The top-down approach works well when there’s a clear insight

into the details of a project, and the leading project manager has a
big picture of how the project contributes to the organization.

The benefit of top-down is that the major tasks are quickly

identified, and the details are later refined by the project team.
However, the downside is that details might be missed without a
detailed review by the project team.

Example

Let’s say you’re responsible for upgrading your application’s

hardware and software layers. Based on past experience, you
know you’ll need to install a new server, install the upgraded
operating system, and then install the latest version of the
application software. These are all top-down tasks that can be
assigned to a project team to implement. The risk is that the
application software doesn’t work on an upgraded software layer
due to a conflicting API or compiled library. The challenge is in all
those pesky details that impact your project.