Lecture 4 – Project Planning, Scheduling &

Time Management

Upfront Planning & Re-planning Part 2

(References: RMC’s PMP Exam Prep, 9th Edition; PMI’s PMBOK Guide, 6th Edition)
Development, Cadence, and Life Cycle Relationship
 Development, Cadence, and Life Cycle Relationship

• The type of project deliverable(s) determines how it can be developed.

• The type of deliverable(s) and the development approach influence

the number and cadence for project deliveries.

• The deliverable approach and the desired delivery cadence determine

the project life cycle and its phases
 Development Approach

•The development approach can influence how, how much, and when
planning is conducted. Examples include:

• A specific phase for planning or organizing early in the life cycle. In these
situations, much of planning is performed up front. The initial plans are
progressively elaborated with more details throughout the project, but
there is little change to the original scope.

• An approach with high-level planning up front, followed by a design phase

where prototyping is used. After the project team and stakeholders agree
to the design, the project team completes more detailed planning.

• An approach where the project team conducts iterations, in which some

planning occurs up front to establish release plans and further planning
occurs at the beginning of each iteration.
 Project Development Approaches (Predictive, Adaptive & Hybrid)

Predictive, Traditional or
Waterfall) Hybrid
This approach relies on a A hybrid approach to project
planning process during management uses aspects of
which requirements and both predictive and agile
scope may be defined in approaches.
detail early in the project.
Detailed plans are created for With such an approach, a
the other project constraints predictive lifecycle may be
as well (e.g. cost, schedule used to manage the project
etc.). requirements that are well
Then, team strives to adhere defined, while an adaptive
to the approved plan as lifecycle may be used to
closely as possible and manage requirements that
protect the project from are less clear.
changes.
Considerations for Selecting a Development Approach

There are several factors that influence the selection of a

development approach and can be divided into categories:

Product, service, or result;

Project;
Organization
Considerations for Selecting a Development Approach

Product, Service, or Result

Many variables associated with nature of product, service, or result that

influence the development approach. The list outlines some of the variables to
consider when selecting the development approach.

▶ Degree of innovation.
▶ Requirements certainty.
▶ Scope stability.
▶ Ease of change.
▶ Delivery options.
▶ Risk.
▶ Safety requirements.
▶ Regulations.
Considerations for Selecting a Development Approach

Project
Project variables that influence the development approach are
centered around:

▶ Stakeholders.
▶ Schedule constraints.
▶ Funding availability.
Considerations for Selecting a Development Approach

Organization
Organizational variables such as the structure, culture,
capability, project team size, and location influence the
development approach:

▶ Organizational structure.
▶ Culture.
▶ Organizational capability.
▶ Project team size and location.
 Project Life Cycle Planning

• Provides a methodology for uniformity in project planning.

• It also provides control – at the end of each phase there is a meeting of PM, sponsor, senior
management and the customer to assess the accomplishments of this life cycle phase and
to get approval for the next phase.

• Monetary and schedule firm-up, staffing deployment and equipment/facility utilization.

• Likewise helps in decision making.

• Proceed with the next phase based on an approved funding level.

• Proceed to the next phase but with a new or modified set of objectives.
• Postpone approval to proceed based on a need for additional information.
• Terminate project.
Project work ranges from definable work to high-uncertainty work
(requirements uncertainty, i.e. what to do and technology uncertainty, i.e. how to do)
and depending upon the nature of the work, different development life cycles and
development approaches may be used to complete the project work.

Definable work projects are characterized by low level

of execution uncertainty & risk and have clear
procedures that have been proved successful on similar
projects in the past, such as production of a car,
construction of a house and so on.

A predictive life cycle suits well for projects that involve

definable work.
New design, problem solving, not-done-before work (e.g. R & D projects) or work
having rate of change, unclear or unknown requirements, or a final goal that is hard to
describe is explanatory and requires subject matter experts to collaborate and solve
problems to create a solution, which make such projects highly uncertain.

High-uncertainty projects have high rates of change, complexity & risk, which make the
traditional predictive approaches unfit for such projects as these approaches aim to determine
the bulk of requirements upfront and control changes through a change request.

Change-driven (a.k.a. adaptive or agile) life cycle work well for high-uncertainty projects, as
these approaches explore feasibility in short cycles and quickly adapt based on evaluation and
feedback, which reduces wastes and rework. This lifecycle uses:

• Very short feedback loops

• Frequent adaptation of process
• Reprioritization
• Regularly updated plans, and
• Frequent delivery
 Types of Project Life Cycle

Predictive Lifecycle (Fully Plan-Driven)

In a predictive life cycle, also called a plan-driven cycle, “the project scope, the
time and cost required to deliver that scope, are determined as early in the life cycle
as possible.”

A predictive cycle can also be called a waterfall cycle, because each step flows down
to the next without repeating prior steps. (However, progressive elaboration will still
occur during planning.)
 Types of Project Life Cycle

Predictive Lifecycle (Fully Plan-

Driven)
Waterfall approach
 Types of Project Life Cycle

Incremental Life Cycle

The incremental life cycle is where the scope of the project is

determined in the early part of the cycle. However, the cost
and time estimates are always modified by the team as the
project progresses

An Incremental life cycle consists of a number of dependent

increments that are completed in a prescribed sequence. Each
increment integrates additional parts of the solution until the final
increment, where the remaining parts of the solution are
integrated
 Types of Project Life Cycle

Iterative Life Cycle

Iterative life cycles are composed of several iterations, which repeat one or more
of the phases before proceeding to the next one.

Iterative approaches can only proceed when user feedback is available to be used
as the basis for initiating new cycles of development, refinement and improvement.
 Iterative Vs Incremental
Iterations develop the product through a series of repeated cycles,
while increments successively add to the functionality of the product.

Iterative

Incremental
Adaptive life Cycle (Agile)

The Adaptive life cycle is also called a flexible or change-focused

method (or agile or change-driven methods) and it responds to
immensely high levels of change as well as the ongoing
participation of different parties involves.

In the adaptive life cycle, the overall scope of a project is broken

down into different sets of requirements or sub-projects that
will be undertaken individually.

During the iteration, the functionalities of the cycle will be

discussed, implemented and, finally, reviewed by the client.
Adaptive Life Cycle

Project: Paint a lady that looks ‘out of

this world’

Cx: No, no… Cx: Goddamn Cx: I want a

Cx: Better. But Cx: I want her
Make her it, No. Make natural smile…
bring her a to smile – but
look pretty her look a natural ‘subtle’
smile. And get not pose in a
pretty and smile
rid of these tooth paste
human
messy hair ad!

Adaptiv
e
Cx: Looks Cx:
better. Make Fanastic.
it a bit Now,
lively develop the
32
rest
Cx: Cx: Thank
Develop You
more! 
 Project Phases

Collection of logically related activities usually culminating in

completion or approval of a major deliverable of the project.
Phases are used when nature of work in phase is unique to a
portion of the project and linked to development of a specific major
deliverable
Phases are time bound with a start and ending point but the
duration and effort in each phase is different.
Usually projects are multi-phase (sequential or overlapping) and
their no. may vary based on organizational need; industry; and size,
complexity & impact of project
Each phase will have all or most of the Project Management
Processes
Phases help in better management, planning and control of the
project
 Sequential Phase to Phase Relationship

Sequential seems logical to human mind

It reduces uncertainty

But makes the project plan rigid and inflexible

• Construction of a house
• Example
Documentation
• Soil Testing
• Laying the Foundation
• Construction of Grey Structure
• Finishing
• Handing Over
 Overlapping Phase to Phase Relationship

Overlapping means doing things in parallel

Usually it is not what human mind thinks first up
Provides room for schedule compression
Requirement for additional resources
Increase in risk, uncertainty, chances of rework
Example
•While building a house, the first ‘phase’ of work would be to get the
blueprint, identifying & choosing vendors, deciding on the type of flooring
and so on.
•However, as soon as the blueprint and builder are figured out, the next
phase of laying the foundation can be started without waiting for the
finalization of every detail of the house.
•While interiors of the house are underway, you can start the landscaping
around the house. M I Minhas
Sequential vs Overlapping Phase to Phase Relationship
 Progressive Elaboration

• Progressive elaboration involves continuously improving and detailing a

plan as more detailed and specific information and more accurate estimates
become available.

• Progressive elaboration allows a project management team to define work

and manage it to a greater level of detail as the project evolves.
 Rolling Wave Planning

Rolling wave planning is a tool of project schedule that focuses on iterative

work and frequent updates to the project plan.

It’s a project planning technique for projects that don’t offer all
the data needed to create a plan or schedule up front.
 Difference between Progressive
elaboration & Rolling wave planning
Project Management Process
Groups Introduction
 Project Management Plan

• A project plan is fundamental to the success of any project.

• Serves as a management guideline for the lifetime of the project.

• Development of a project plan can be time-consuming and costly but it saves the
project from rework, delays and cost overruns.

• All levels of the organization participate – upper levels provide summary information,
and the lower levels provide the details.
 Project Management Plan

• Provides the following framework:

• Eliminates conflicts between functional managers

• Eliminates conflicts between functional management and program management

• Provides a standard communication tool throughout the lifetime of the project

• Provides verification that the contractor understands customer’s objectives & requirements

• Provides a means for identifying inconsistencies in the planning phase

• Provides a means for early identification of problem areas and risks so that no surprises
occur downstream

• Contains all of the schedules needed for progress analysis and reporting
 Project Management Plan

• The project plan is a standard from which performance can be measured by the
customer and the project and functional managers.

• The plan serves as a cookbook by answering these questions for all personnel
identified with the project:

●● What will be accomplished?

●● How will it be accomplished?
●● Where will it be accomplished?
●● When will it be accomplished?
●● Why will it be accomplished?
 Formulate Plan

Have

Saf
SoW assumpt

ety
ions Yes
changed
Customer ?
Input
N risks
Spe

Are

s
otoo

get
cifi

great?

B ud
cati

Yes
Are
on

Schedules sufficien
s

t
Legal N
resource Iterations
os
availabl N
l
a

Soc
tur

e?
Are o
ial
Cul

objectiv
Environmental es
Yes
satisfied
Input ?
cal

N
ogi
Pol

Finalize Plans o
nol
iti
cal

h
Tec

Yes
Economic
 Project Management Plan

• The project plan is more than just a set of instructions.

• It is an attempt to eliminate crisis by preventing things from “falling through the cracks.”

• The plan is documented and approved by both the customer and the contractor to
determine what data, if any, are missing and the probable resulting effect.

• As the project matures, the project plan is revised to account for new or missing data.

• The most common reasons for revising a plan are:

●● “Crashing” activities to meet end dates

●● Trade-off decisions involving manpower, scheduling, and performance
●● Adjusting and leveling manpower requests
 Project Management Plan
Scope Management Plan
Cost Management Plan
Resource Management Plan
Risk Management Plan
Stakeholder Engagement Plan
Configuration Management Plan
Scope Baseline
Cost Baseline
Project Lifecycle Description
Schedule Management Plan
Quality Management Plan
Communication Management Plan
Procurement Management Plan
Change Management Plan
Schedule Baseline
Performance Measurement Baseline
Development Approach
 Project Management Plan vs Project Documents
Project Management Plan
• It consists of all the plans, milestones,
dates, cost etc. and is approved by
senior management or project
sponsor.
• It is frozen.
• Revised only as a result of an approved
change request.
Project Documents
• These documents are used to manage
the information which is not part of
PMP.
• These documents are prepared by the
Project Manager for his own needs.
• Out of these documents only charter,
contracts and statement of work are
shown to the Project sponsor and is of
interest to them.
• It is living and updated as project is
executed.
 Scope Management Plan
Cost Management Plan
Resource Management Plan
Risk Management Plan Procurement Management Plan
Stakeholder Engagement Plan
Project Management Plan Configuration Management Plan
Scope Baseline
Cost Baseline
Project Lifecycle Description
Assumption Log
Lessons Learned Register
Project Documents Quality Report
Milestone List
Schedule Management Plan
Quality Management Plan
Communication Management
Plan
Change Management Plan
Schedule Baseline
Performance Measurement
Baseline
Development Approach
Change Log
Risk Register
Risk Report
Activity List
M I Minhas
 Project Planning Sequence
Planning Process Group
Determine development approach, lifecycle & how to plan each KA
Define and prioritize requirements
Create scope statement
Assess what to purchase and create procurement documents
Determine planning team
Create WBS and WBS dictionary
Create, activity list and network diagram
Estimate resource requirements
Estimate activity duration and costs
Determine critical path
Develop schedule and budget
Determine quality standards, processes and metrics
Determine team charter and all roles & responsibilities (for product & project work)
Plan communication and SH engagement
Perform risk identification, qualitative & quantitative risk analysis & response planning
Go back – Iterations
Finalize procurement strategy and documents
Create change & configuration MPs
Develop realistic Project MP, including baselines
Gain formal approval of the plan from sponsor
Hold kickoff meetings
Request changes
 Kickoff Meeting

• Involves major players responsible for planning, including the PM, SMEs, and functional leads.

• There can be multiple kickoff meetings based on the size, complexity & time requirements.

 Some of the items discussed in initial kickoff meeting include:

🞑 Wage and salary administration, if applicable

🞑 Letting the employees know that their boss will be informed as
to how well or how poorly they perform
🞑 Initial discussion of the scope of the project including both the
technical objective and the business objective
🞑 The definition of success on this project
🞑 Assumptions & constraints as identified in project charter
🞑 The project’s organizational chart (if known at that time)
🞑 The participants’ roles and responsibilities
46