Agile Development Student Handbook v4.2

Identify defects
a Res!)Lye tins
Iteraticiris)Demo
II Feedba.ck
Production Et
"Technical Support
Quality
Ass u To Tic e
Development
Deplayrnent
Design Agile
Docunnent Design RELEASE
Et Protype Development TO
—pi
MethodoLogy iVILARKE
Requiremrerrt Brainstiarrn
Analysis l i
t
Agile application development lifecycle
Table Of Contents
Duration: 3days
1. Introduction-What is a Project?
— Projects as Opposed to Operational Management
— Projects as Part of Strategic Management
— Projects as Integral to Program Management
2. The Project Life Cycle

— Generic Project Life Cycle
— The Project Management Life Cycle
— The Process Groups
— SDLC Overview
— IIBA Knowledge Areas
3. Project Management Concepts and Methodologies

— Waterfall
— Agile
Table Of Contents...contd
4. Project Initiation-The BA Role
— Stakeholder Analysis and the Stakeholder Register
— Initial Business Analysis Artifacts
— Documenting Requirements within a Requirements Gathering Approach
— Types and Sources of Requirements
5. Initiation-The PM Role: Baselines

— Develop Project Charter
— Collect Requirements
— Project Scope Statement
— Work Breakdown Structure
— Scope Baseline
— Define Activities
— Project Schedule Network Diagram (Dependency Network)
— Estimate Activity Resources
— Effort vs. Duration and Compensation
— Develop the Project Schedule
— Critical Path Method
— Schedule Compression
Table Of Contents...Contd
 6. Initiation-Important Subsidiary Management Plans
— Test Plan
 Test Planning and Development Considerations
 Test Budgeting Methods and Test Plan Content
— Human Resource Plan
 Organizational Charts
 RAM Charts, RACI, and Roles and Responsibilities
— Communications Management Plan
— Risk Management Plan
 Risk Planning and Identification
 Qualitative Risk Analysis
 Risk Register 7.
Performing the Work-Project Execution
— Cost Control
— Earned Value Management, CPI, SPI
— Scope Control
— Requirements Communication
— Solution Assessment and Validation
— Requirements Traceability Matrix
— Software Testing
— Levels of Testing
Table Of Contents...Contd
8. Closing the Project
— Project Closure-Product Acceptance
— Closing the Project-Things That Must Be Accomplished
9. Agile Overview
— What is Agile All About? The Agile Manifesto and Principles
— The Levels of Agile Planning
— Release Planning-The Product Backlog, Sprint Backlog
— Story Points and Velocity
— Iteration Planning
— Daily Scrums, Sprint Reviews, Demos, and Retrospectives
Introduction
Challenges for Organizations
1Managing current business operations

V - rans ro rm•i ng businessso as to . . .
in the changing
business circumstances
1Balancing between business as usual (BAU) and business change
operations ... sustain
_ _M_ _
Definition of Project
 A chan ge is introdu ced by me ans of Projects
 A temporary organization that is created for the purpose of delivering

one or more business products according to agreed business case.
 Characteristics of Project
 Change
 Temporary
 Cross-functional
 Un i qu e
 Un certain ty
Why do we need Project Management ?
i/To keep control over the specialist

[work
i/To manage the risks effectively Plan 11114.

i/Project management is the planning,
delegating, monitoring and control of Control Delegate
all the project and the motivation of
14
those involved, to achieve the project
objectives within the expected
performance targets for time, cost, 4 Monitor Ili
quality, scope, benefits and risks.
Project Management
Operations Management
Operations Management is an ongoing Projects are temporary and help the

organizational function that performs activities business to meet organizational
to produce products or supply services. For goals and to respond quickly and
instance, production operations, easily to the external environment.
manufacturing, IT Service Management, and
accounting operations. Organizations use projects to change
operations, products and services to
Furthermore, operations are permanent meet business need, gain competitive
endeavors that produce repetitive outputs. advantage and respond to new
Resources are assigned to do the same tasks markets.
according to operating procedures and policy.
Project Management
Different Objectives
Projects require project management whereas operations requires business process management
or operations management.
However, projects and operations do meet at various points during the life-cycle of a product or
service.
For example when:

Re-engineering business processes, Developing or changing product and services, and
Improving operations or product development.
The goal of process management is to improve processes continually. Improving operational

processes may increase effectiveness, cut costs and gain competitive advantage.
Projects are about driving change in the organisation. For instance, using business process re-
engineering to align business need with customer expectation.
Project Management
Different Skills
Moreover, the skills needed by the project manager are different to those needed by operational
managers.
Project Manager Operational Manager
Role ends with project Routine
Temporary team Stable organisation
Many different skills Specialist skills
Work not done before Work repeatable
Time, cost and scope constraints Annual planning cycle
Difficult to estimate time and budget Budgets set and fixed events
Organizational Strategy
And
Project Selection
Why Project Managers Need to Understand the

Strategic Management Process
 Changes in the organization's mission and strategy
— Project managers must respond to changes with appropriate decisions about

future projects and adjustments to current projects.
— Project managers who understand their organization's strategy can become

effective advocates of projects aligned with the firm's mission.
Projects and Strategy
 Mistakes caused by not understanding the role of projects in

accomplishing strategy:
— Focusing on problems or solutions with low strategic priority.
— Focusing on the immediate customer rather than the whole market place and value
chain.
— Overemphasizing technology that results in projects that pursue exotic technology that
does not fit the strategy or customer need
— Trying to solve customer issues with a product or service rather than focusing on the
20% with 80% of the value (Pareto's Law).
— Engaging in a never-ending search for perfection only the project team really cares
about.
The Strategic Management Process:

An Overview
 Strategic Management
— Requires every project to be clearly linked to strategy.
— Provides theme and focus of firm's future direction.
 Responding to changes in the external environment—environmental scanning
 Allocating scarce resources of the firm to improve its competitive position—
internal responses to new programs
— Requires strong links among mission, goals, objectives, strategy,

and implementation.
Project Portfolio Management Problems

 The Implementation Gap
— The lack of understanding and consensus on strategy among top management
and middle-level (functional) managers who independently implement the
strategy.
 Organization Politics
— Project selection is based on the persuasiveness and power of people advocating
the projects.
 Resource Conflicts and Multitasking
— Multi-project environment creates interdependency relationships of shared
resources which results in the starting, stopping, and restarting projects.
A Portfolio Management System
 Design of a project portfolio system:
— Classification of a project
— Selection criteria depending upon classification
— Sources of proposals
— Evaluating proposals
— Managing the portfolio of projects.

A Portfolio Management System

 Selection Criteria
— Financial: payback, net present value (NPV), internal rate of
return (IRR)
— Non-financial: projects of strategic importance to the firm.
 Multi - Weighted Scoring Models

— Use several weighted selection criteria to evaluate project proposals.
Financial Models
 The Payback Model
— Measures the time the project will take to recover the
project investment.
— Uses more desirable shorter paybacks.
— Emphasizes cash flows, a key factor in business.
 Limitations of Payback:
— Ignores the time value of money.
— Assumes cash inflows for the investment period (and
not beyond).
— Does not consider profitability.
Nonfinancial Strategic Criteria

 To capture larger market share
 To make it difficult for competitors to enter the market
 To develop an enabler product, which by its introduction will increase sales in more profitable
products
 To develop core technology that will be used in next-generation products
 To reduce dependency on unreliable suppliers
 To prevent government intervention and regulation

Multi-Criteria Selection Models
 Checklist Model
— Uses a list of questions to review potential projects and to determine their
acceptance or rejection.
— Fails to answer the relative importance or value of a potential project and
doesn't to allow for comparison with other potential projects.
 Multi - Weighted Scoring Model

— Uses several weighted qualitative and/or quantitative selection criteria to
evaluate project proposals.
— Allows for comparison of projects with other potential projects
Applying a Selection Model
 Project Classification
— Deciding how well a strategic or operations project fits the
organization's strategy.
 Selecting a Model
— Applying a weighted scoring model to bring projects to closer with the
organization's strategic goals.
 Reduces the number of wasteful projects
 Helps identify proper goals for projects
 Helps everyone involved understand how

and why a project is selected
Project Proposals
 Sources and Solicitation of Project Proposals
— Within the organization
— Request for proposal (RFP) from external sources (contractors and vendors)
• Ranking Proposals and Selection of Projects
— Prioritizing requires discipline, accountability,
res pons i bil ity, c onstra i nts, re duce d flex ibili t y, a nd
loss of power.
 Managing the Portfolio
— Senior management input
— The priority team (project office) responsibilities
Managing the Portfolio
 Senior Management Input

— Provide guidance in selecting criteria that are aligned with
the organization's goals
— Decide how to balance available resources among current projects
 The Priority Team Responsibilities
— Publish the priority of every project

— Ensure that the project selection process is open and free of
power politics.
— Reassess the organization's goals and priorities

— Evaluate the progress of current projects
Project Portfolio Matrix Dimensions

 Bread-and-butter Projects
— Involve evolutionary improvements to
current products and services.
 Pearls
— Represent revolutionary commercial
opportunities using proven technical
advances.
 Oysters
— Involve technological breakthroughs
with high commercial payoffs.
 White Elephants
— Showed promise at one time
but are no longer viable.
Project as a Part of
Program Management
Portfolio
Management
Project
Program mgmt mgmt
Service Project
mgmt mgmt
Service
mgmt
Other
activities
Project as a Part of
Program Management
Project management is the planning, organizing,

Within a program, these same
directing, and controlling of company resources...
responsibilities (i.e., allocation, utilization,
for a relatively short-term objective.
and direction) are assigned to people at
three levels in the management hierarchy;
It is clear from this definition
the higher the level, the more general the
that project management is concerned with the
responsibilities.
dynamic allocation, utilization, and direction of
resources (both human and technical), with time -in
relation to both individual efforts and product
For example, at the bottom of the
delivery schedule -- and with costs, relating to both
management hierarchy, project managers
the acquisition and consumption of funding.
are assigned to the various projects within
the overall program. Each manager carries
As a corollary, it is safe to say that without the
out the management responsibilities we
direction project management provides, work
described above.
would have to proceed via a series of negotiations,
and/or it would not align with the goals, value
proposition, or needs of the enterprise.
Project Lifecycle
Project Lifecycle
Project Life Cycle Overview
The project management life cycle consists of five process groups (often referred to as phases):
Initiation, Planning, Execution, Control, and Closure.
It is important not to skip any of these stages if you want to keep your project from failing.
For example, if you skip from initiation to execution without effectively planning the project,
mistakes can be made, the project will be too disorganized, and it will fall apart. Likewise, if you,
like many project managers skip the closure phase of the project management life cycle, you
could risk making similar mistakes in future projects by not learning and reviewing your
mistakes..
Phase 1: Initiation
Before you can get to planning a project, the project has to be initiated. Project initiation
consists of the following steps:
1.Create a document outlining the product or project. This initial document is informal
compared to the project charter. It simply describes what will be created or what the overall
goal is of the project.
2.A project feasibility report will need to be completed. Before investing too much time in a
project, you must check to see whether or not it is feasible that you will be able to complete
the project, product, or process with the available resources.
3.Once you have determined the project is feasible, then a project manager and team will be
assigned to the project.
4.The project scope statement is the next deliverable. This deliverable outlines what will be
done (the project scope), how it will be done, and why it will be done.
5.Finally, a project charter is created that will demonstrate who is in charge of the project, the
project's scope, and the project's critical success factors.
Phase 2 : Planning
Once the project has been approved, a deadline has been set, and the scope has been agreed upon,
then the project planning phase of the project management life cycle begins. The project planning
phase consists of the following steps:
1. Review the project scope and revise the scope statement if necessary. You want to keep your
project from entering a phenomenon known as "scope creep" where the scope of the project
grows or expands without making necessary changes to the budget or schedule of the project.
Make sure the project scope is something that can be reasonably completed, is specific, and is
measurable.
2. Complete project decomposition, resulting in the work breakdown structure. Project

decomposition involves breaking the project down into its component parts: Milestones, tasks,
etc., and the work breakdown structure depicts these parts in a hierarchical structure.
3. Once the work breakdown structure has been created, an organizational breakdown structure
can be put together. An organizational breakdown structure demonstrates, visually, the
hierarchy of the individuals involved in the project.
4. Resource allocation is now performed. Who will be responsible for what in the project? What
will the budget be used for? What objects will be required for the project and at what points?
Take time to carefully plan resources for the project.
Phase 2 : Planning
5. Create the project schedule. When will milestones need to be completed by?
Who is responsible for each task in the project? How often will communication
take place?
6. Plan the project's budget and how resources will be gathered for the project.
7. Perform a risk assessment. What risks are involved in completing the project?
8. What budget will be needed should any of these risks materialize during the
project execution phase? By planning now for unfortunate events, you can
increase the likelihood that things will not go wrong during your project.
9. Put together a stakeholder analysis and communication plan. When will

communication occur, who is responsible for communicating what to whom?
10. Finalize the project plan. Make sure all elements have been covered.
Seek approval of the project plan from superiors.
Phase 3 : Execution
The project management life cycle phase, execution, begins when team members
actually begin working o n the tasks assigned them by the project manager. During this
phase, if a product is being created, then the product is put together. During the
project execution phase, the following tasks are completed:
Time management - the project manager checks to ensure that the project is being completed on
schedule.
Cost management - the PM ensures that all expenses are accounted for and necessary
Quality management - is the quality of the product or process to the specifications of
the stakeholders?
Change management - should something change in the stakeholder's specifications or
schedule the project man ager may need to change the plans for the project
accordingly.
Issue management - during the execution phase, issues should be carefully tracked so
that the project manager and other team members are aware of any problems that
come up during execution.
Phase 4 : Monitoring and Control
Life Cycle Phase IV: Project Control

Project control really happens close in proximity with project execution. Project
control involves monitoring the project for risks and keeping those risks at bay.
It also involves keeping changes in the project to a minimum.
Project control often mistakenly gets lumped in with project execution functions, but
it's important not to do this. At times, during the control phase, project managers
may find that a given risk or problem forces them to revisit phase II - planning.
This is because some risks or issues that come up and were unforeseen may
make the project, as planned, unable to reach completion.
Good project managers will implement a system to monitor and control their
project's progress to ensure project success.
Phase 5 : Closure
Project closure is one of the most oft-overlooked phases of the project management
life cycle and yet it's no less important than any other phase of the life cycle. Project
closure involves the following steps:
1. Writing a project closure report. This report includes information such as the
project sign off, releasing of the staff, cost management and schedule
management strategies, lessons learned through the project, and what the
results of the project were.
2. Redistributing resources that were assigned to the project.
3. Filing any administrative paperwork regarding the project's completion.
4. Preparing any stepping stones for the next project.

Project Lifecycle
Wrapping it Up
Finally, while the five phases of the project management life cycle appear linear
here, often times, a project manager will have to return to an earlier step, complete
it, and work back through the project management phases.
For example, if during the control phase a defect is found, a project manager may
have to return to the planning phase. During the execution phase, if change must
occur, a return to the planning phase will be necessary.
Don't be afraid to return to an earlier phase if necessary - but don't neglect the
phases either.
Process Groups
Project Management Process Groups
A process group is a logical grouping of activities, inputs, tools,

techniques, and outputs required for any type of project.
Monitoring
Initiating Planning Executing Closing
Contra Iliny
Define a new project or Greve bp an integratcl Complete the work and Track and review Finalize all activities
new phase, identify project management satisfy project project progress and and fcrmally close the
sta keholders, a nod pla n to ado in project objectiv4m. performa nce; ma roge project or phase
obtai n authorization: objectives Va ria Rce and change
''Authorize the Work" "Plan the Work" ''Work the Plan" YtControl the Plan" "' Ehd the Wcrk"
 Project Charter  Project Mgt. Plans &  Project De livery ble.  Change Logs  Final Prodtrt,
 Stikeholcler Register Related 13ccuments  irk Performance  Approved Change Sep/ ice, or Result
- Soolfpe Data R.ed uses (Le purpose of
- Requirernwit  Team Performance  Wbrk 1:e.rforrra .._ project)
- c•' le Assessment Information  Closed Prccuremert
- Cog  Project  .hedu le Forecasts .(e..g. formal signature
- Quaky CdrnmunicatiPns te.g.. , Cot Forecast of acceptance)
Human RISCTLI rCe2.,
status report)  Updates to Project
- Cornmun icy "ti
 Selected Suppliers Plan
rJ - Risk
- Preicilferrient & A g reement.  Qualty Caotrol
- iThangie  Change Rego Measurement.
St2tkotiolders  issue Lag.  Verified Deliverable
 Accepted Derables
Project Lifecycle
• •
Knowledge Areas 1 ProJect Project Project Project Project Project Project Project Project Project
Integration Scope Time Cost Quality Human Resource Communications Risk Procurement Stakeholder
Management Management i . Management Management Management management management Management Management Management
Inftlating DEvelop Project Identify
Process Charter Stakeholders
Grou
Develop Project Plan Scope Plan Schedule Plan Cost Plan Human Plan Plan Risk Plan Plan
Management Management Management Management Resource Communications Management NM rem ent Stakeholder
Plan Management Management Management management
Called Define Activities Estimate Costs Estimate Adholty Identify RISks
Requirements
Sequenc Determin Perform
Planning Define Scope e Activities e Budget Qualitative
a Process Risk Analysis
e Group Create YOBS Estimate Advity
Resources Plan Quality Perform
3IP
Quantitative Risk
Analysis
Durations
Rang'tL
V Develop Schedule Responses
Management
1
:";-,-.' -:*. and Perform Cis Acquire Project Manage Conduct Manage
r' c Team Communications
'.' • - • : z rrafect AssureP Procurements Stakeholdei
fg Dearing ..
Engagement
.., ROMS Develop Project
g Group "MITI
3'
a` ivlanage Project
earn
Monitor A''' Validate Scope Control Schedule Control Costs Control Quality Control Control Control Control
Monitoring, Coritro ;:_,k7t Communications Risks Procurements Stakeholder
and Work Control Scope Engagemen
COrrtr011ing t
proc PErform
.......:..' Integrated
Gro Change
Control
Closing Close Project dose
Process I or. Phase Procurements
Group
SDLC Model
A framework that describes the activities performed at each stage of a

software development project.
%no
qRequirements
Software
Analysis ill
Development
Design Life Cycle
411! Development
Maintenance
Waterfall Model
 Requirements — defines needed

information, function, behavior,
performance and interfaces.
 Design — data structures, software
architecture, interface
representations, algorithmic
details.
 Implementation — source code,
database, user documentation,
testing.
Waterfall Model
 Test — check if all code modules

work together and if the system as
a whole behaves as per the
specifications.
 Installation — deployment of
system, user-training.
 Maintenance — bug fixes, added
functionality (an on-going
process).
Waterfall Model - Strengths
 Easy to understand, easy to use

 Provides structure to inexperienced staff
 Milestones are well understood
 Sets requirements stability
 Good for management control (plan, staff, track)
1E1 Waterfall Model - Deficiencies
 All requirements must be known upfront

 Deliverables created for each phase are considered
frozen — inhibits flexibility
 Does not reflect problem-solving nature of software
development — iterations of phases
 Integration is one big bang at the end
 Little opportunity for customer to preview the
system (until it may be too late)
Waterfall Model - Applicability
 Requirements are very well known

 When it is possible to produce a stable design
 E.g. a new version of an existing product
 E.g. porting an existing product to a new platform.
V-Shaped SDLC Model
 A variant of the Waterfall

Project Ri Production,
Requirements
Planning
operation ai
Maintenance
that emphasizes the
Product • System &
verification and validation
Requirements & Acceptance
SPecificati an
Analysis
Testing of the product.
Architecture High-
Level Design
Integration &
Testing
 Testing of the product is
planned in parallel with a
Detailed Design Unit Testing corresponding phase of
development
Coding
V-Shaped SDLC Model - Steps
 Project and Requirements Planning —  Coding — transform algorithms into

allocate resources software
 Product Requirements and  Unit — check that each

Specification Analysis — complete module acts as expected
specification of the software system
 Integration and Testing — check that
 Architecture or High -Level Design — modules interconnect correctly
defines how software functions fulfill
the design
 System and acceptance testing —
check the entire software system in
 Detailed Design — develop algorithms its environment
for each architectural component
 P r o d uct i o n, o pe r at i o n a nd
mai nt e n an ce — pr o vi de f o r
e nha nce me n t a n d co r r e ct i o ns
V-Shaped SDLC Model - Strengths
 Emphasize planning for verification and

of the product in early stages of
product development
 Each deliverable must hF testable
 Project management can track progress by
miles ,...
 Easy to use
V-Shaped SDLC Model - Weaknesses
 Does not easily handle concurrent events

 Does not handle iterations or phases
 Does not easily handle dynamic changes in
requirements
When to use the V-Shaped Model
 Excellent choice for systems requiring high

reliability — hospital patient control
applications
 All requirements are known up-front
 When design is stable
 Solution and technology are known
Prototyping Model
 Developers build a prototype during the

requirements phase
 Prototype is evaluated by end users
 Users give corrective feedback
 Developers further refine the prototype
 When the user is satisfied, the prototype code
is brought up to the standards needed for a
final product.
-1111=111'
Prototyping - Steps
 A preliminary project plan is developed

 An partial high-level paper model is created
 The model is source for a partial requirements specification
 A prototype is built with basic and critical functions
 The designer builds
— the database
— user interface
— algorithmic functions
 The designer demonstrates the prototype, the user evaluates
for problems and suggests improvements.
 This loop continues until the user is satisfied
Prototyping Strengths
 Customers can "see" the system requirements as
they are being gathered
 Developers learn from customers
 A more accurate end product
 Unexpected requirements accommodated
 Allows for flexible design and development
 Steady, visible signs of progress produced
 Interaction with the prototype stimulates awareness
of additional needed functionality
Prototyping - Weaknesses
 Tendency to abandon structured program

development for "code-and-fix" development
 Bad reputation for "quick-and-dirty" methods
 Overall maintainability may be overlooked
 Process may continue forever (scope creep)
Prototyping - Applicability
 Requirements are unstable or have to be clarified

 As the requirements clarification stage of a waterfall
model
 Develop user interfaces
 New, original development
Rapid Application Development Model (RAD)
 Requirements planning phase (a workshop utilizing

structured discussion of business problems)
 User design phase — users to participate in the
nontechnical design of the system
 Construction phase — productivity tools, such as code
generators, screen generators.
 Cutover phase -- installation of the system, user
acceptance testing and user training
I Rapid Application Development Model (RAD) - Steps
Requirements planning
phase
User design phase
Construction phase
Cutover phase
Rapid Application Development Model (RAD) - Strengths
 Reduced cycle time and improved productivity with

fewer people means lower costs
 customer involved throughout the complete cycle
minimizes risk of not achieving customer satisfaction
and business needs
 Focus moves from documentation to code
 Uses modeling concept.< to capture information
about business, data, and processes.
Rapid Application Development Model (RAD) - Weaknesses
 Accelerated development process must give quick
responses to the user
 Risk of never achieving closure
 Hard to use with legacy systems
 Requires a system that can be modularized
 Developers and customers must be committed to
rapid-fire activities in an abbreviated time frame.
 May compromises functionality and performance in
exchange for faster development and better
application maintenance
When to use RAD
 When requirements are not fully understood.

 User involved throughout the life cycle
 Functionality delivered in increments
 High performance not required
 System can be modularized
Incremental SDLC Model
 Construct a partial
Validation
System implementation of a total system
Feasibility Soitmare Plans Validation
and  Then slowly add in crease d
Veritic-ati on
Pedui ements
-
Product
fun ctionality
Design
 T h e in c r e me n t al m o d e l p r i o ri ti z e s
re q u i re m e n t s of th e s y s t e m a n d
t h e n i m pl e me n t s t h e m i n g r o u p s.
De:ailed Design  Each subseque nt release of the
Code system adds fu nctions to the
Product Verification
previous release, until all
In:eg raj o n
designe d functionality has been
Implementation System Test
implemented.
Operations & Revalidation
Maintenance
Incremen: n
Incremental Model Strengths
 Develop high-risk or major functions first

 Each release delivers an operational product
 Customer can respond to each build
 Uses "divide and conquer" breakdown of tasks
 Lowers initial delivery cost
 Initial product delivery is faster
 Customers get important functionality early
Incremental Model Weaknesses
 Requires good planning and design

 Requires early definition of a complete and
fully functional system to allow for the
definition of increments
 Well-defined module interfaces are required
(some will be developed long before others)
 Total cost of the complete system is not lower
When to use the Incremental Model
 Most of the requirements are known up-front but

are expected to evolve over time
 A need to get basic functionality to the market early
 On projects which have lengthy development
schedules
Spiral SDLC
Model
Determine Evaluate
objectives,
alternatives,
alternatives;
Identify,
 Adds risk analysis, and
constraints resolve risks
4g1 RAD prototyping to
the waterfall model
Concept
 Each cycle involves the
i
same sequence of steps
Plan Develop
Requirements
next
Design
next level as the waterfall process
phases product
Implement -
A—, model
Spiral Quadrant
Determine objectives, alternatives and constraints
 Objectives: functionality, performance, hardware/software

interface, critical success factors, etc.
 Alternatives: build, reuse, buy, sub-contract, etc.
 Constraints: cost, schedule, man-power, experience etc.
Spiral Quadrant
Evaluate alternatives, identify and resolve risks
 Study alternatives relative to objectives and constraints

 Identify risks (lack of experience, new technology, tight
schedules, etc.)
 Resolve risks
Spiral Quadrant
Develop next-level product
 Typical activites:
— Create a design
— Review design
— Develop code
— Inspect code
— Test product
Spiral Quadrant
Ian next phase
 Typical activities
— Develop project plan
— Develop a test plan
— Develop an installation plan
Spiral Model Strengths
 Provides early indication of insurmountable risks,

without much cost
 Users see the system early because of rapid
prototyping tools
 Critical high-risk functions are developed first
 Users can be closely tied to all lifecycle steps
 Early and frequent feedback from users
Spiral Model Weaknesses
 Time spent for evaluating risks too large for small or

low-risk projects
 Time spent planning, resetting objectives, doing risk
analysis and prototyping may be excessive
 The model is complex
 Risk assessment expertise is required
 Spiral may continue indefinitely
 Developers must be reassigned during non-
development phase activities
When to use Spiral Model
 When creation of a prototype is appropriate
 When costs and risk evaluation is important
 For medium to high-risk projects
 Users are unsure of their needs
 Requirements are complex
 New product line
 Significant changes are expected
Tailored SDLC Models
 No single model fits all projects
 If there is no suitable model for a particular project,
pick a model that comes close and modify it for your
needs.
If project should consider risk but complete spiral
model is too much — start with spiral and simplify
it
If project should be delivered in increments but
there are serious reliability issues — combine
incremental model with the V-shaped model
 Each team must pick or customize a SDLC model to
fit its project
Quality the degree to which the software
satisfies stated and implied requirements
 Absence of system crashes

 Correspondence between the software and the users'
expectations
 Adherence to specified requirements
Quality must be controlled because it lowers production speed,

increases maintenance costs and can adversely affect
business
the good enough is enemy of the excelle nt
Quality Assurance Plan
 The plan for quality assurance activities should be in writing

so all stakeholders can review it during the lifecycle.
 Some elements that should be considered by the plan are:
defect tracking, unit testing, source-code tracking, integration
testing and system testing.
Quality Assurance Plan
 Defect tracing — keeps track of each defect found, its source,

when it was detected, when it was resolved, how it was
resolved, etc
 Unit testing — each individual module is tested
 Source code tracing — step through source code line by line
 Integration testing - test new code in combination with code
that already has been integrated
 System testing — execution of the software for the purpose of
finding defects.
Conclusion
 SDLC
— A framework that describes the activities
performed at
each stage of a software development project.
 Waterfall and V-Shaped and Incremental models
need requirements to be known up-front.
— E.g. when creating new versions of existing systems.
 Prototyping, RAD and Spiral models do not need
all requirements to be known
— E.g. New systems.
— Uses series of prototypes that evolve into the finished
system.
Stakeholder Management
Project Stakeholder Management
IPlanStakeholder
Management
- - . . . . . . . . . . .
1---
Control
Stakeholder
Engagement
I
Identify Stakeholders
 Project Charter  Stakeholder Stakeholder

 Procurement analysis register
documents  Expert judgment
 Enterprise  Meetings
environmental
factors
 Organizational
process assets
Project Stakeholder Management
> Inputs:
Project Charter:
Provides the information of key stakeholders
Procurement documents:
Provides the key stakeholder information mentioned in the
contracts
Stakeholder Analysis
> Process of systematically gathering and analyzing
quantitative and qualitative information to determine
whose interests should be taken into account throughout
the project
STEP 1:
> Identify all potential stakeholders and relevant information
— Roles, departments, interests, knowledge levels,
expectations, and most importantly the influence levels
> Identify the potential impact or support each stakeholder
could generate
> Classify them to define an approach strategy
Afferent Classification methods
> Power/interest gird, grouping the stake holders based on their level
of authority and their level or concern("interest") regarding the
project outcomes
> Power/influence gird, grouping the stake holders based on their level
of authority ("power") and their active involvement ("influence") in
the project
> Influence/impact gird, grouping the stakeholders based on their
active involvement ("influence") in the project and their ability to
effect changes the project's planning or execution ("impact") and
> Salience model, describing class of stake holders based on their
power ( ability to impose their will), urgency (need for immediate
attention), and legitimacy ( their involvement is appropriate)
Power Interest Grid
High
Keep Satisfied Manage Closely
Monitor Keep Informed
Low
Low
Interest High
Outputs
> Stakeholder Register
— Identification information
 Name, org position, location etc.
— Assessment information
 Requirements, expectations, influence in project etc
— Stakeholder classification
 Internal / external,
 Supporter / neutral / resistor etc
> Stakeholder management strategy
Defines an approach to increase support and minimize
negative impacts of stakeholders throughout entire project
life cycle
Plan Stakeholder Management
 Project  Expert judgment Stakeholder

management  Meetings management
plan oo s & Tec nique Analytical plan
 Stakeholder techniques Project
register documents
 Enterprise updates
environmental
factors
 Organizational
process assets
Plan Stakeholder Management
Inputs:
Project Management Plan:
Description of how work will be executed to accomplish the
project objectives
Description of how human resources requirements will be met
and how roles and responsibly reporting relationships, and
staffing management will be addressed and structured for the
project
Change management plan that documents how changes will be
monitored and controlled
Plan stakeholder management
> Tools and techniques
Expert judgment:
Meetings: Meetings should be held with experts and project team
to define the engagement of stakeholders
Analytical Techniques: Analyze various techniques to plan
engagement levels required for project completion
Outputs
> Stake holder management plan
 Desired and current engagement levels of key stakeholders
 Scope and impact of change to stakeholders
 Identified interrelationships and potential overlap between
stakeholders
 Stake holders communications requirements for the current
project phase
 Time frame and frequency for the distribution of required
information to stakeholders
 Methods for updating and refining the stakeholder
management plan as the project progress and develops.
Manage Stakeholder Engagement
 Stakeholder  Communication  Issue log

management plan methods Change requests
 Communications Interpersonal Project
management plan
skills management
 Change log
 Organizational  Management plan updates
process assets skills  Project
documents
updates
 Organizational
process assets
updates
Communication Methods
> Interactive
— Most efficient way to ensure common understanding by
all
participants
> Push
— Letters, memos, emails, fax, reports, blogs, etc.
> Pull 11 1 1 1 1 A
MIN' ......-
Manage stakeholder Engagement
> Interpersonal Skills
Building trust
Resolving conflict
Active listening
Overcoming resistanc
> Management Skills
Issue Log
 A powerful tool for PM to monitor /manage stakeholder
expectations
 A written/documented log with project issues
 Helps to monitor who is responsible for resolving specific
issues by a target date
 A Sample:
Cat ioup
A :Ii. hem • &Num
• niniky Acebrolarfpni
I—I. • • '"
Ir
1 11.1.+916 lane Dampen PriApitrdui
Resolution C u num
"Vri AA Dew ilpdon cil Pc don
A. Dote Azurso.
C•Itioaral
Inkier!
P.
7.5414404.
GI.C1F1415 K.IL'e 05.1-50 I I fraoys•• 7 .:e•.2 's
J.,14:1.11131 t* oiluin ea ;,. S'X' ±...'..,-
Control Stakeholder Engagement
Project Information Work
.
oo s & Tec niques
management management performance
plan systems information
Issue log Expert judgment Change requests
Work
 • Meetings Project
performance management
data plan updates
Project Project
documents documents
updates
Organizational
process assets
updates
Project Integration Management
Integration Management Overview
 This is the only knowledge area that contains processes from
all the 5 process groups
 Integration management helps in bringing all the different
processes & activities in a project
 Integration is achieved through the 6 processes available in
Integration management
Need for Integration
Integration can be between:
Processes
 Project & performing organizations
> Project objectives
Example:
 Tree planting project
Story > Orchestra
Ship captain
Project Integration Management
1. Develop Project Charter
2. Develop Project Management Plan
3. Direct and Manage Project Work
4. Monitor and Control Project Work
5. Perform Integrated Change Control
6. Close Project or Phase

Develop Project Charter
 Project Expert Project Charter

Statement of Judgment
work
 Business Case
oo s & Tec moue Facilitation
Techniques
 Enterprise
Environmental
Factors
 Organizational
Process Assets
98
Intro — Project charter
> It is a formal authorization to start a project or a phase
> It establishes the existence of a project
> This formal authorization ensures that common project failures
are prevented
Common project failures:
Declining profits
Rework
Low motivation
Intro Project charter
 It focuses on documenting the initial requirements
 Stakeholder expectations are translated into high level
requirements
 It links the customer and the project
 This is the appropriate process for naming a PM
Linking is between: Customer & project (internal project)
Performing organization & project (external project)
 Expert Project Charter

 Project Judgment
oo s & Tec ni • ue
Statement of  Facilitation
work
 Business Case
Techniques 0
 Enterprise
Environmental
Factors
 Organizational
Process Assets
101
Inputs — Develop Project Charter
Project statement of work is a narrative description of products
or services to be delivered
SOW is used for preparing charter
SOW is provided by sponsor — Internal projects
SOW is provided by customer — External projects
SOW contains
Product scope description
Business need
Business case contains the business justification for the project
Business case creates urgency in the top management
Inputs — Develop Project Charter
 Enterprise environment factors (EEF) are conditions, situations
or events in a company or in the market that directly or
indirectly influence the project's success
 EEF include all issues, conditions, situations and

circumstances that can influence the project in positive or
negative manner
 EEF may be because of market conditions or may exist within
the organization
Enterprise Environmental Factors
 Marketplace conditions: currency exchange fluctuations,
vendor prices, costs of materials, demand and supply
 Company culture: reporting relationships, work-life how to save your job?4
balance, bureaucratic mindset, technology adoption,

service orientation
 Risk tolerances: if the sponsor is risk averse and if the
PM likes to take excessive risk then there could be issue
 Project management information systems (PMIS): tools
that the company utilizes for collecting and sharing
project information
 Work authorization systems: it is the manner in which
work gets assigned to individuals. Work can be assigned
through issuance of a role description sheet or through
an email detailing their tasks
Organizational Process Assets(OPA)
> OPA includes:
Plans
Procedures
Policies: hiring policies,
procurement policies etc.
Guidelines
Templates: claim
templates, warranty templates,
authorization forms, time reporting templates etc.
> Lessons learnt and historical information are important
knowledge bases that fall under OPA. Past project documents,
training material, benchmark reports, industry reports etc. are
part of knowledge base.
Tools & techniques
 Expert judgment is the knowledge derived from qualified
sources
 This primarily includes the subject matter experts
JUDGEMENT
106
Develop project
management plan
 Expert Judgment  Project Charter

 Project  Facilitation
Statement Techniques Collect
of work requirements
 Business Case C
 Enterprise
Environmental
Factors
 Organizational Define scope
Process Assets
Identify
stakeholders
107
Output — Project charter
 Project charter is the output of the Develop Project Charter
 It is a document that formally authorizes a project or a phase
Planning process
Initiating process
group
group V et g r k - d r fO r
--Initiating processes -- Planning processes 1. Pro)ett Purpose
-- Project 2. Measurable project obJettives

-- Project Charter
management plan 3. High Level Requrrements
-- High Level
-- Detailed 4. 1-ligh Level project description
-- Get the project 5. High Level product characteristics
-- Perform detailed
started E. summary milestone schedule
plans
7. Summary budget
108
Project charter contains...
 Project purpose or justification,
 Measurable project objectives and related success criteria.
 High-level requirements,
 Assumptions and constraints,
 High-level project description and boundaries,
 High-level risks,
 Summary milestone schedule,
 Summary budget,
 Stakeholder list.
 Project approval requirements (i.e., what constitutes project success, who decides the project is
successful, and who signs off on the project),
 Assigned project manager, responsibility, and authority level, and
 Name and authority of the sponsor or other person(s) authorizing the project charter.
Develop Project Management Plan
 Expert Project
 Project Charter Judgment Management
 Outputs from oo s & Tec nique  Facilitation Plan
other processes Techniques
 Enterprise
Environmental
Factors
 Organizational
Process Assets
110
(PMP)
> Subsidiary plans & baselines
Subsidiary plans- plans on
HOW a project team
intended to address each
of the knowledge areas
> Subsidiary plans provide guidelines on HOW the project will

be defined, executed, monitored, controlled & closed
> This is a process of creating detailed plans & baselines
ri)  Project Charter ri)  Expert  Project

Develop project CI)
 Outputs from Judgment Management
charter other processes  v4  Facilitation Plan
 Enterprise Techniques
Environmental U
O
Factors CI)
r
Outputs from  Organizational

planning processes Process Assets C3
O
H
Enterprise /
Organization
112
Inputs — Develop PMP
 Project charter is signed of by the sponsor to start the project.
This contains high level information
 PM uses this information to prepare the project management
plan which contains detailed information
Inputs Develop PMP
 Subsidiary plans are plans which says how a particular knowledge area will be
performed
 Subsidiary plans are prepared during planning of respective knowledge areas and
are added together to form PMP
 Baselines include scope baseline, cost performance baseline and schedule baseline
which are together called Performance Measurement Baselines
 Scope management plan

 Schedule management plan
 Requirements management plan
 Quality management plan
 Human resource plan
 Communication management plan
 Risk management plan
 Procurement management plan
Subsidiary plans
Outputs of planning processes in other knowledge areas Project
 Scope baseline Management
 Cost performance baseline Plan
 Schedule baseline
Baselines
Outputs of planning processes in other knowledge areas
114
Inputs Develop PMP
> Few of the Enterprise Environmental Factors that are

applicable for developing the project management plan include
company culture, industry guidelines etc.
> Organizational process assets that are applicable to this
process include templates for the project management plan,
documents from previous projects including lessons learnt
Output — Develop PMP
> PMP includes all the subsidiary plans and the baselines
> PMP also includes information about the lifecycle of the
project along with the processes that will be used for the
proj ect
Lifecycle
chosen
Subsidiary Processes
plans selected
116
Output - Develop Project
Manag
ement
Plan
 Project Charter  Expert 4 • Project
 Outputs from Judgment Management
other processes  Facilitation Plan
 Enterprise Techniques
Environmental 0
Factors All executing
 Organizational processes
Process Assets
All monitoring &
controlling
processes
All closing
processes
117
Direct and Manage Project Work
 Project  Expert  Deliverables

Management Judgment  Work
oo s & Tec ni • ue
Plan  Project Performance
 Approved Management Data
Change Information  Change
Requests System Requests
 Enterprise  Meetings  Project
Environmental Management
Factors Plan Updates
 Organizational  Project
Process Assets documents
updates
118
Introduction
 This process is all about executing and getting the work done
according to the Project management plan
4#7
Inputs Direct and Manage
Project Work
 Project  Expert  Deliverables

Develop project
management plan
Management Judgment  Work
Plan  Project Performance
 Approved Management Data
Change Information O  Change
Requests System Requests
 Enterprise  Meetings  Project
Perform integrated
Environmental Management
change control
Factors Plan Updates
 Organizational  Project
Process Assets documents
updates
Enterprise /
Organization
120
Inputs - Direct and Manage Project
Work
> PMP is an input to this process because it has the information
on how to execute the project
> Work will be performed based on the plan and the plans are
contained in the PMP
Inputs - Direct and Manage Project Work
> Approved change requests are result of a discussion on
whether the change should be implemented or not
> PMP is changed based on only approved change requests
> All change requests either approved or rejected should be
documented
> Approved change requests include:
Approved corrective actions. E.g. Team should work fast to
meet the missed deadlines
Approved preventive actions. E.g. Fill the fuel in vehicle
once the fuel indicator goes below the warning threshold
Approved defect repair. E.g. Fix the Loose key cap in a
Laptop - is a defect repair
Outputs- Direct and Manage Project Work
 Project Management
Plan
 Approved Change
 Expert Judgment
 Project
Management
1
4 Deliverables
Work
Performance
Perform quality
control
Requests Information Data
 Enterprise System  Change Requests
Environmental  Meetings  Project Work performance
Factors Management data
 Organizational Plan updates
Process Assets  Project
documents
updates Perform integrated
change control
Develop project
management plan
4 Project documents
123
Outputs- Direct and Manage Project
Work
> Deliverable: It is a unique product, service, result or capability.
A project produces a deliverable. Accomplishing the
deliverable marks the completion of the project or phase
> Work performance data: It is the raw information about the
work performed. Work performance data is collected regularly
as the work is executed. It becomes the key input for the
controlling processes
Outputs- Direct and Manage
Project Work
 Change requests (CR): Authorized recommended actions to
deal with issues. In this process CRs are related to issues
arising as a result of executing the work & accomplishing
deliverables
 CRs remain as recommendations until they are approved
 PMP updates are the result of approved changes which are
i m p l e m e n t e d .
125
Monitor and Control Project Work
 Project  Expert  Change requests

management Judgment  Work
oo s & Tec moue

Plan  Facilitation performance
 Schedule Techniques reports
forecasts  Analytical  Project
 Cost forecasts techniques management
 Validated  Project plan updates
Changes management  Project
 Work information documents
Performance system updates
Information  Meetings
 Enterprise
126
Introduction - Monitor and control project work
 Monitoring the project happens throughout the project

lifecycle
 Closely monitoring a project will help us identify issues early
in the project and take necessary actions
 Controlling the project ensures that only approved change
requests are implemented
Inputs: Monitor and Control Project Work
Develop project
management plan  Project  Expert 4  Change requests
management Judgment Work
Plan Facilitation performance
 Schedule Techniques reports
forecasts  Analytical 0  Project
Report performance  Cost forecasts techniques management
 Validated  Project plan updates
Changes management  Project
 Work information documents
Environment / Performance system updates
Organization Information  Meetings
 Enterprise
Environmental
Factors
 Organizational
Process Assets
128
Inputs: Monitor and Control Project Work
 PMP has the information on how to perform this process
 Performance reports have the current performance of the
proj ect
 This process is all about checking the planned versus actual
spQTTiNq THE DIFFERENCE
Plan _1 Actual
Project Management Plan Performance Reports
Monitoring and controlling Project Work
129
Outputs: Monitor and Control Project Work
 Project  Expert Judgment Change requests

management acilitation  Work Perform integrated
Plan Techniques performance change control
 Schedule Analytical reports
forecasts techniques  Project
 Cost forecasts Project management
 Validated management plan updates
Changes information  Project
Develop project
 Work system documents management plan
Performance eetings updates
Information
 Enterprise
Environmental
Factors
 Organizational
Process Assets Project documents
130
Outputs: Monitor and Control Project Work
 This is a process of measuring and

tracking project performance
 Change requests are the main output
which provides the necessary action to be Plan )
taken to bring back the project on track I-
,,... Actual
131
Perform Integrated Change Control
 Project  Expert  Approved

Too s & Tec niques
management Judgment Change
plan  Meetings requests
 Work  Change control  Change log
performance tools  Project
reports management
 Change requests plan updates
 Enterprise  Project
Environmental documents
Factors updates
 Organizational
Process Assets
132
Introduction: Perform Integrated
Change Control
 This process involves evaluating, approving/rejecting and
managing the change requests
ecommended change
requests
> Change
requests
should
never be
implement
ed without
approval
133
Change Control
 Changes should always be documented and recorded in
document management system
11.
Change can be initiated in However,. it should be Change Control

any form, verbal, email etc.., documented and Procedures (Process
And by any stakeholder recorded formally for handling changes)
134
Change Control
 Change control board is a function
which has the authority to either
approve or reject changes
 Change control procedures should be
followed for approving or rejecting
changes
 Change control that is centrally
managed to provide for an efficient
and standardized approval and
rejection is called configuration
Configuration
management system Project A

Tmegraried Change Control
Management
System
Project C
integrated Chang Control
135
Inputs: Perform Integrated Change Control
Develop project
management plan
 Project  Expert Judgment  Approved
management Meetings Change requests
plan  Change control Change log
Direct and manage
 Work tools  Project
project Work
performance O management
reports plan updates
 Change requests  Project
 Enterprise documents
All controlling Environmental updates
processes Factors
 Organizational
Process Assets
Enterprise /
Organization
136
Inputs: Perform Integrated Change Control
 PMP has the information on how to perform this process. PMP

also has the baselines required for this process
 Work performance information is the raw information on the
current status of the project
 Change
F
Heed Erma.- Eritegrated

C. rir64 41,4E3.
Change Control
/
R 6.
Approved
Change Change
Request Request
137
Tools & technique:
Perform Integrated Change
> Change control meetinAtgadd to evaluate and
authorize changes
> Expert judgment includes inviting experts to be part of the
change control board
Outputs: Perform Integrated Change Control
Direct and manage

project execution
 Expert Judgment  Approved

 Project  Meetings Change requests Perform quality
management  Change log control
 Change control
plan tools  Project
 Work O management
performance plan updates Administer
reports  Project procurements
 Change requests documents
 Enterprise updates
Environmental Project
Factors management plan
updates
 Organizational
Process Assets
Project document
updates
139
Outputs: Perform Integrated
Change Control
 The mail output of this process is the change request status
updates
 Change request status updates can be approved or rejected
 Approved — Approved change request
 Rejected - updated in the change log
Approved
Rejected
Change Request Status Updates

Close Project or Phase
 Project Expert Final product,

management Judgment service or result
plan
oo s & Tec moue  Analytical transition
 Accepted Techniques Organizational
Deliverables  Meetings process assets
 Organizational updates
Process Assets
141
Introduction Close project or phase
> This process is about formally closing the project or phase by
finalizing all the activities from all process groups
> This process produces procedures that contain all the
instructions/steps to formally close a project or phase
Inputs: Close Project or Phase
Develop project
management plan  Project
management
 Expert 4  Final product,
Judgment service or result
plan  Analytical transition
 Accepted Techniques  Organizational
Deliverables  Meetings 0 process assets
Validate scope  Organizational updates
Process Assets
Organization
143
Inputs: Close Project or Phase
 PMP is an input because this has the details on how to perform
this process of finalizing and formally completing the project
 Accepted deliverables which can be product, service or a result
are needed to verify the completion
Outputs: Close Project or Phase
 Project Expert 4  Final product,

management Judgment service or result
plan  Analytical transition
Customer
 Accepted Techniques  Organizational
Deliverables  Meetings 0 process assets
 Organizational updates
Process Assets
Organization
145
Outputs: Close Project or Phase
 Final product, service or result should undergo a formal
handover after a formal review of the deliverable
 There should be a formal statement to confirm that the
deliverable is complete
Project Scope Management
Integration
Human Resource
Communications
Stakeholder
148
Plan Scope Management
Collect Requirements
Define Scope
Create WBS
Validate Scope
Control Scope
149
Why Project Scope Management?
 To ensure that the project includes all the work
and only the work required to complete the
project deliverables
 To define, monitor, manage or control the
in-scope and out-of-scope requirements
1. Plan Scope Management — This is new in PMBOK 5th edition
2. Collect Requirements
3. Define Scope
4. Create WBS
5. Validate Scope
6. Control Scope
... ,
Project Management Process Groups
initiating Planning Executing Monitoring Closing

Knowledge Areas
Process Process Process and Controlling Process
Group Group Group Process Group Group
Plan Scope Validate Scope

Project Scope Management Control Scope
Management Collect
Requirements
Define Scope
Create WBS
Product Scope Vs Project Scope
 Product Scope
The features and functions that characterize a
service, result or a product
 Project Scope
The work performed to deliver a product, service
or result.
 Project Scope may include product scope.
 Project  Expert  Scope

management Judgment management
oo s & Tec moue  Meetings
plan plan
 Project charter Requirements
 Enterprise management
environmental plan
factors
 Organizational
Process Assets
153
 This is new in PMBOK 5th edition
 It is a process of creating a "Scope management plan" which is
a document to know how scope will be defined, validated and
controlled.
 It provides guidance and direction on how scope will be
managed throughout the project.
Plan Scope Management - Inputs
 Project Management Plan
 Project Charter
— Project Context
— High level product description and features
 Enterprise Environmental Factors
— Organization culture
— Infrastructure
— Marketplace conditions
— Resource administration
 Organizational process assets
— Policies and Procedures
— Historical information
— Lessons Learned KB
Tools & Techniques
 Expert Judgment
— Collective information from experienced / trained persons
or groups to come up with "scope management plan" which
is a primary output of this process
 Meetings
— Project manager, project teams, sponsor, selected
stakeholders, etc. Together attend the meeting to come up
with scope management plan
Plan Scope Management - Output
 "Scope management plan" is the main output of this process.
— It contains the information of how scope will be defined, developed,
monitored, controlled and verified
— It is a subsidiary plan or component of "Project Management Plan"
— It contains the processes
 for preparing a detailed project scope statement
 that enables how WBS can be created, maintained and
approved
 Specifies how formal acceptance of
deliverables/completed project deliverables will be
obtained
 Process to control how to validate scope
Plan Scope Management - Output
 "Requirements management plan" is another output of this
process.
 It include the activities such as
— how requirement activities can be planned, tracked and
reported
— configuration management activities (changes to the
product are handled)
— process of prioritizing the requirements
— metrics for the product
— structure for Traceability matrix
 It is a process of acquiring, collecting, documenting, and
managing stakeholder needs and expectations/requirements to
meet the project objectives
 It provides the basis for defining and managing project scope
(including product scope)
Scope management Interviews
oo s & Tec moue

II lan ocus groups Requirements
equirements acilitated workshops documentation
anagement plan Group creativity Requirements
Stakeholder echniques traceability matrix
anagement plan Group decision
roject charter aking techniques
Stakeholder register Questionnaires and
surveys
Observations
Prototypes
Benchmarking
Context diagrams
Document analysis
160
Collect Requirements - Inputs
 Scope management Plan
(The above two are outputs from previous process)
 Stakeholder management plan -
 Used to understand how stakeholders involve in requirements activities
— Used to understand stakeholder communication requirements
 Project Charter
 Stakeholder register
— all the information about stakeholders
— major requirements and major expectations that stakeholders have for
the project.
Collect Requirements Tools &
Techniques
 Interviews -
 formal or informal approach to get information from
stakeholders by talking to them directly
 Focus Groups -
 Prequalified stakeholders and SMEs share their
expectations of proposed product. A moderator directs the
group interactively
 Facilitated workshops -
 Focused sessions or workshops with key stakeholders that
also helps to get consensus
Tools & Techniques
 Group Creativity Techniques
— Brainstorming
— Nominal group technique
— Idea/mind mapping
— Affinity Diagram
— Multi-criteria decision analysis
 Group Decision-Making Techniques
— Unanimity
— Majority
— Plurality
— Dictatorship
Tools & Techniques
 Questionnaires and Surveys -
 set of written Q's given to large number of audience
 Observations -
 viewing directly how the business experts perform the tasks or job, also called as
"job shadowing"
 Prototypes -
 create a working model of the expected product before actually building it. This
helps in getting early feedback
 Benchmarking
— Compares actual with planned to provide a basis for measuring performance
 Context Diagrams
— Visual representation of a business system that covers product scope. It shows how
actors & business system interacts with each other.
 Document Analysis
— Going through existing documents and analyze the information to get the
expectations / requirements of the product
Collect Requirements - Output
Requirements documentation includes
— Business requirements
— Stakeholder requirements
— Solution requirements
 Functional
 Non-functional
— Transition requirements
— Quality requirements
— Requirement assumptions, constraints, and dependencies
Collect Requirements Output
Requirements Traceability matrix
— links the product requirements throughout the project
deliverables and tracks till the end of delivery
— Helps to manage the changes to the scope
— An example of RTM:
BlEirleSS Needs,
ID Clpportirities, Project MS Product Product Test
flequlrerrwts F.Weirtrilion Objectives Deliwarables Design Development Cases
Goals, Objectives
1.0
1.1
1.2
1.2.1
2.0
2.1
2.1.1
Define Scope
 This process helps to understand the product in a wider range
and its features extensively
 It helps come up with a detailed description of the project and
product requirements
Define Scope
* a i-nr I
 Scope  Expert judgment
Project scope
management Product analysis statement
plan Alternative Project
 Project charter generation documents
 Requirements  Facilitated updates
documentation workshops
 Organizational
process assets
168
Define Scope - Inputs
 Scope management Plan
 Project Charter
 Requirements Documentation
 Organizational Process Assets
Define Scope — Tools & Techniques
 Expert Judgment
 Product Analysis
— It includes the techniques such as product breakdown, systems
engineering, requirement analysis, value engineering and value
analysis.
 Alternatives generation
— create different options to identify different approaches to perform the
project work
— Ex: Lateral thinking, Brainstorming, etc.
 Facilitated workshops
— To gain a common understanding of project expectations
— Key stakeholders with different area-of-expertise will be participated in
this intensive workshops
Define Scope - Output
 Project Scope Statement
— Primary output of this process
— It contains
 Project scope
 Major deliverables
 Assumptions and constraints
 Accepted Criteria
 Out of scope requirements, etc.
 Project documents updates
— A few documents will be updated after completion of this process
 Stakeholder register
 Requirements traceability matrix, etc.
Define Scope - Output
 Sample template of "Project Scope Statement" document
Project Scope Statement
Project Name ________
Product Scope
Description
Project Deliverables
Project Assumptions
Project Constraints
Project Exclusions
Product Acceptance
Criteria
172
Create WBS
 It is a process of decomposing the tasks (of producing the
outcome of the project) to a smaller level, to be able to
estimate cost or effort and to assign resources
 The project deliverables or Project work is subdivided into
smaller and more manageable components
WBS — Work Breakdown Structure

Create WBS
 Scope  Decomposition Scope baseline

management  Expert Project
plan judgment documents
 Project scope updates
statement
 Requirements
documentation
 Enterprise
Environmenta
factors
 Organizational
process assets
174
Create WBS - Inputs
 Project scope statement
 Requirements documentation
 Enterprise Environmental factors
Create WBS Tools & Techniques
 Decomposition
— A process of dividing and sub-dividing the project scope
and project deliverables to "work package" level
— Work Package — the work defined at the lowest level of
WBS
— The cost & effort of the work package should be able to
estimate and manage
— Decomposition can be done by the categorization of
project
deliverables, project phases, etc.
— An identification code is assigned to each WBS
component
 Expert judgment
An Example of WBS
Filling A
Vacant Post I
The Jab ilf u The Candidate The Selection
Attracting Shortlisting The Post

The Need Job Spec
Interview Selection
Advert — Venue
— Terms
Criteria
Budgetl Content
,
The Job Advert

— Options ~ Timing Review — Interview — Induction
Location C.V.'s
_Appru
[ Person Tour ■ Relocation ■
Shortlist
— Decide
Create WBS - Output
 Scope baseline
— Primary output of this process
— It contains
 Approved Project Scope Statement
 WBS
 WBS Dictionary — A document that contains detailed
information about each WBS component
— Once the scope is base-lined, it cannot be changed
— Changes to Scope baseline can be done only through formal change
request
WBS Dictionary
 A Sample WBS Dictionary that contains information about a
work package.
Project Name; Customer Desk
Work Package ID: 1.4.1.1
Work Package Name: Designed User Screen

Work Package Description: Using the customer's User Screen
Specification, a new top-level layout design is to be created. Based on this a
non-functioning layout demonstrator is to be prepared to collect
feedbackfrom the customer. A fully functional prototype will be created for
the clientto review and a pprove.
Assigned To: Dave Litten Group/Dept: IT Systems

Estimated Cost: $3,800,00 Account Code: cllpfi/4/33
Acceptance Criteria: Resources Assigned:
Deliverables: Assu IT1 pti o ns :
179
Validate Scope
 The purpose of this process is to get the formal acceptance of
the completed deliverables from the customer
 To get formal sign-off from the customer
Validate Scope
roject
management
plan  Inspection  Accepted
Requirements Group deliverables
documentation decision- Change
Requirements making requests
traceability techniques  Work
matrix performance
Verified information
deliverables  Project
Work documents
performance
data
updates
181
Validate Scope - Inputs
 Project management plan
 Requirements traceability matrix
 Verified deliverables
— Deliverables that are completed and verified
through
"Control Quality" process
 Work performance data
— Degree of compliance with requirements
— Number and severity of non-conformities / defects
Validate Scope
Tools & Techniques
 Inspection
— To examine whether the completed deliverables meet the requirements
and product acceptance criteria
— Also called as reviews, audits, etc.
 Group Decision-making Techniques
— Techniques used when the validation is done by project team or stake
holders
— They are
 Unanimity
 Majority
 Plurality
 Dictatorship
Validate Scope - Outputs
 Accepted Deliverables
— Deliverables formally signed-off / approved by Customer
— An acknowledgement from customer/sponsor that
deliverables are accepted
 Change Requests
— CRs may arise from the completed deliverables
 Work Performance Information
— It shows the progress of the project (the status of
deliverables started, completed, accepted)
Control Scope
 It is a process
— where the status of project and product scope will be
monitored on a regular basis
— where the changes to the scope baseline are being
managed
 The changes to the scope are monitored, tracked, managed
Control Scope
 ariance ork
 'roject analysis performance
management information
plan Change requests
 Requirements Project
documentation management
 Requirements plan updates
traceability Project
matrix documents
 Work updates
performance
Organizational
data process assets
 Organizational A updates
process assets
186
Control Scope - Inputs
 Project management plan
 Scope baseline
 Change management plan
 Configuration management plan
 Requirements traceability matrix
 Work performance data
Control Scope — Tools & Techniques
 Variance Analysis
It is a technique to compare the baseline with
actual project performance
It determines the cause and degree of the
difference between both.
It helps to make a decision whether preventive or
corrective action is required
Control Scope - Outputs
 Work Performance Information
 Change requests
 Project management plan updates
 Organizational process assets updates
Project Time Management
> Plan Schedule Management
> Define Activities
> Sequence Activities
> Estimate Activity Resources
> Estimate Activity Durations
> Develop Schedule
> Control Schedule
Introduction - Project Time Management
>Any management plan contains information on
HOW the project team intends to perform
something
 Schedule management plan has the details on
how to perform time management processes
like how to define activities, how to estimate
duration etc.
199. SOM.
I I Gr., s l G9-4. .1.1r, !G.,. i,r1r3
0.1 Fluieurdarened feeerberblows 919.99
- I • •Ie : - r• ar I C. Yllocnlication 11011-e -12-0113
4.M _
__ a lca c ler n Merlon Inelnwered
1,2•1•.[Iell1Peret
-...-
ael-raL
- C IDOC
0.1,10 • 0.e.r1
CIE aE. Corne.le. •
_• •
.7-- ••• - Ont., DOC. Irell•-•13.3.2
 -•trol lel•acErfIcallon os .2a eirl
system-6rerannorenel 4.•
M-51003.
Poin2 •inc nuon Pi ,n 17.111.7.1
4cerrnealic n
Vera I-, an 0.alteararl
IA aclures 17inv
•  .
2,4 1.93. : . .• . .•
20 onclur I Peoo-Ui pla Verilleanon •••99, e..•
.rotatyr o arr.o. , 9.....” , mr•
I Pi andiar at ',en Verinealion
L
• IDecno
As5
C
blIcenagairerora:na
fin-C1 DOC,-
191
7 , 2
r i - .E . 1 - 1 Plan 6.11. - Eire,

E ▪ YE, 411E- HIS, Mand e•t1=11131.1
Introduction Project Time Management
> PMP encompasses all subsidiary plans and schedule

management plan is one of the subsidiary plans
> Schedule management plan preparation effort is included as
part of overall PMP preparation effort
> Schedule management elan contains information on what
192
Plan Schedule Management
 Project  Expert Schedule

plan Analytical techniques plan
 Project charter Meetings
 Enterprise
environmental
factors
 Organizational
process assets
193
Introduction: Plan Schedule Management
> Plan schedule management has the details of how the

processes of time management knowledge area will be
performed
> Schedule management plan is a subsidiary plan which forms
part of PMP
Inputs: Plan Schedule Management
Develop project
management plan  Project  Expert 4 • Schedule
plan  Analytical plan
 Project charter techniques
 Enterprise  Meetings 0
Develop charter environmental
factors
 Organizational
process assets
Enterprise/
Organization
195
Inputs: Plan Schedule Management
> Project management plan contains scope baseline which
comprises of project scope statement, WBS and WBS
dictionary which aids in preparing schedule management plan
> Schedule related cost, risk is also used while developing
schedule management plan
> Project charter has the high level schedule which aids in
preparing the schedule management plan
> As part of EEF - organization culture, PMIS, work
authorization systems will influence this process
> As part of OPA - Templates, guidelines, processes, tools
influence this process
Tools & techniques: Plan Schedule
Management
 Expert judgment utilizes expert's knowledge of domain,
industry etc. in preparing schedule management plan
 Analytical techniques such as estimating methodologies ,
scheduling software are evaluated and selected
 Meetings may be held among relevant stakeholders to perform
this process
Outputs: Plan Schedule Management
Other schedule
 Project  Expert 4 • Schedule management
management Judgment management processes
plan  Analytical plan
 Enterprise  Meetings 0
environmental
factors Identify risks
 Organizational
process assets
Perform
quantitative risk
analysis
198
Outputs: Plan Schedule Management
> Schedule management plan which is a subsidiary

plan of PMP has the information on how to
perform the processes of time management
knowledge area
> Schedule management plan various from project
to project based on the project needs
> This contains the level of accuracy, units of
measure, permissible variation or limits, method
used for measuring performance, reporting
formats etc.
Define Activities
 Schedule  Decomposition  Activity list

management  Rolling wave  Activity
plan planning attributes
 Scope baseline  Expert Milestone list
 Enterprise judgment
environmental
factors
 Organizational
process assets
200
Introduction —Dune
 Defining activities specifies a list
Activities
tions that would
accomplish a deliverable
 Deliverable is called as work package in Work Breakdown
Structure
 Usually, the list of activities is denoted directly below a work
package
 Activities awn gcrijons to be performed. Best way to
differentiate between deliverables and activities is to document
activities in verb-noun format as shown in the diagram below
1
0160,tiaral
Work Packages Pax
1. Send email Develop Home page

List of Activities for 2. Gather requirements 2. Prepare style sheet
each Work Package 3. Conduct meeting
4. Start designing
Inputs: Define Activities
Plan schedule
management
 Schedule  Decomposition 41 Activity list
anagement Rolling wave Activity
plan planning 1-1 attributes
 Scope baseline Milestone list
 Enterprise
Expert
judgment C
Create WBS environmental
factors
 Organizational
Enterprise/ process assets
Organization
202
Inputs — Define Activities
 How to perform the process Define activities is provided in the
schedule management plan which is part of PMP
 Project scope statement, WBS, WBS dictionary form the scope
baselip "ment
Project Scope
scope WBS
dictionary baseline
statement
 EEF
has the <1_
informatio
n on which system EEF: Proieet Management
Inicarrnatican Systems
the project management information is

stored. OPA has the templates etc...
OPA: 'Templates
203
Tools & techniques Define Activities
 Decomposition is the act of dividing the work packages into
activities. This should always be done along with the team
members for better results
ice-
2i-i2caz
411111& 111111, ONO
z H2O f cm•
lyerc , gn Prc.>ctdc wat e r
 Rolling wave planning is a form of progressive elaboration.

Detailed planning is performed for the immediately occurring
activities and high level planning is performed for activities
occurring at a later stage
 Expert judgment includes suggesting
activities to accomplish a
work package. Even team members can
provide the expertise
Outputs: Define Activities
Sequence activities
Estimate activity
resources
Estimate activity
Decomposition Activity list durations
Schedule Rolling wave Activity
management planning attributes Develop schedule
plan Expert 0 Milestone list
Scope baseline judgment Sequence activities
Enterprise Estimate activity
environmental resources
factors
Organizational Estimate activity
process assets durations
Develop schedule
Sequence activities
205
Outputs: Define Activities
 Activity list is performed to accomplish a work package
 Activity attributes provide more information about activities
mentioned in activity list. For example, Activity attributes for
send email activity are:
1. This activity should be performed before gather
requirements activity
2. This activity should be performed on 31st Dec 2013
 Milestones are important events in the activity list. In the
1'11. •
example pp • '
-
12-eaLsecable
j
milestone v I 1
5 1 5. . . 1 - 1 . Pac ka ge s Harrel le ...P.,' x c

p i M s y
1_ Sepacl email II:Leuelop. Horne page

List of Activities for 2_ GatF•er reggirerrbersts 2_ Preya re style sibeec
each W-ork Package 3_ .C..M.ZICIA.Gt rsseetinsg
WIL.aet
206
Sequence Activities
Schedule  Precedence Project schedule

management plan diagramming network diagrams
method (PDM) Project documents
Activity list
 Dependency updates
Activity attributes determination
Milestone list  Leads and lags
Project scope
statement
Enterprise
environmental
factors
Organizational
process assets
20 7
Introduction: Sequence Activities
> Each activity will have one or more predecessor and successor.
This ensures that all activities are connected
> Exception is that first activity will not have a predecessor and
last activity does not have a successor
Inputs: Sequence Activities
F
chedule recedence roject
anagement iagramming chedule
Define activities plan method network
Activity list (PDM) diagrams
Activity Dependency Project
attributes determination documents
Milestone list Leads and updates
Project scope lags
Define scope statement
Enterprise
environmenta
1 factors
Organization
al process
Enterprise/ assets
Organization
20 9
. • •
Inputs: Sequence
Activities
 Activity list has the list of activities to be
performed. Activity attributes has the
additional information about the activities.
Milestone list mark the key achievement
 Project scope statement contains the
product description which has the details
of features and functionality. We can relate
the order of the features and functionality
of the product by determining the order of
the activities
210
Tools & techniques: Sequence
A c p •ft •e s
>- Precedence diagramming metho ( yt DM uses rectangles to represent
activities and connects them using arrows. This tool is also called Activity on
node
>- PDM includes 4 types of logical relationships :
1. Finish to Start — Activity C cannot start unless Activity A has finished
2. Start to Start — Activity B cannot start unless Activity A has started
3. Finish to Finish — Activity B cannot finish unless Activity A has finished
4. Start to Finish - Activity B cannot finish unless Activity A has started
>- Dependency determination establishes logical relationships as a result of
existing dependencies.
The type of logical relationship possible are:
1. Mandatory or hard logic are the result of inherent nature of work.
Contractual compliance and product limitations are examples
Tools & techniques: Sequence
Activities
> Dependency determination establishes logical relationships as
a result of existing dependencies.
The type of logical relationship possible are:
1. Mandatory or hard logic are the result of inherent nature of
work. Contractual compliance and product limitations are
examples
2. Discretionary or preferential logic dependencies exist as a
result of preferences of project team
3. External dependency indicates that an activity outside of the
project has an effect on the sequence project activities. The
relationship between activities is dependent on the external
event
Tools & techniques:
Sequence
Activities Start to
Start with
a Lag
 Applying leads and lags takes into _J

Lag
account any delays or advances between (Waiting)
+ 1 Hr
Document Material
activities. The delays are called as lags

and advances are called as leads
 Lag which is also called as waiting time,
Lead
(-2 days)
is the amount of delay that exists 4

between activities Start Work (Drilhng)
 Schedule network templates includes the

templates from previous projects. Sub
network is the portion of the
network from past project
213
Outputs: Sequence Activities
Schedule Precedence Project schedule

management diagramming network
plan method (PDM) diagrams Develop Schedule
Activity list  •••-1 Dependency Project
Activity determination documents
attributes „(1.) Leads and lags updates
Milestone list
Project scope
statement
Enterprise
environmental O
factors r. o
Organizational Project document
process assets updates
214
Outputs: Sequence Activities
 Project schedule network diagrams are displays and the logical
relationships between the activities
1 day 3 days 2 days
Buy Build shed Supervise
z
Materials base cement hardeni rig
Shed
Shed design
2 days ready
selected
Cut ikssemble
wood shed
3 days
215
Estimate Activity Resources
 Schedule Expert judg nent Activity resource

management plan Alternative requirements
Activity list analysis Resource
Activity attributes Published breakdown
 Resource calendars estimating data structure
 Risk register Bottom-up Project documents
 Activity cost estimating updates
estimates Project
 Enterprise management
environmental software
factors
 Organizational
process assets
216
Introduction: Estimate Activity Resources
 Identify the type and quantity of resources needed to

accomplish the activities. Document the details for each
activity
 Estimate cost is another process which is closely associated
with this process at an activity level
217
Inputs: Estimate Activity Resources
Define activities
7 chedule
anagement
an
xpert judgment
lternative
analysis
1
ctivity
source
quirements
 Activity list Published Resource
 Activity estimating data breakdown
attributes  Bottom-up structure
 Resource estimating Project
calendars  Project documents
Acquire project  Risk register management updates
team/Conduct  Activity cost software
procurements estimates
 Enterprise
environmental
factors
 Organizational
process assets
Enterprise/Organizati
on
218
Inputs: Estimate Activity Resources
 Activity list contains the list of activities that need to be
performed to accomplish a deliverable
 Activity attributes are supporting information about the
activity
 Activity resource requirements will depend on availability
which is available in resource calendar. Activity resource
requirements will also depend on the skill level
Tools & techniques: Estimate Activity
Resources
> Bottom-up estimating involves
estimating resources of an activity
after it has been decomposed into
smaller levels
> Published estimating data includes

known productivity and resource
requirements based on similar past
projects or benchmarking
Outputs: Estimate Activity Resources
Estimate activity
duration
 Expert judgment  Activity Develop schedule

 Schedule  Alternative resource
management analysis requirements
 Resource Develop HR plan
plan  Published
 Activity list estimating data breakdown
 Activity  Bottom-up structure
Plan procurements
attributes estimating  Project
 Resource  Project documents
calendars management updates
Project documents
 Risk register software
 Activity cost
estimates
 Enterprise
environmental
factors
 Organizational
process assets
221
Outputs: Estimate Activity Resources
 Activity resource requirements contains the type and quantities

of resources to accomplish the activities
 Adding the resources will result in total resources at a work
package level
 Resource breakdown structure is a hierarchical breakdown of
the resources by categories
'Resource Breakdown Project
Resources
Structure
Hu man Vendor%
Material! Resources
Hardware Management Local

Front-Line
Vendors
Senior Internatio•na
Software Engpneers Managers I Vendors.
luniOr
Donsurnabres Workers
Managers
Estimate Activity Durations
Schedule management xpert judgment Activity duration

I, lan alogous estimating estimates
oo s & Tec niques

. ctivity list arametric estimating Project documents
ctivity attributes hree-point estimating updates
ctivity resource Group decision-
equirements aking techniques
esource calendars eserve analysis
roject scope
statement
l' isk register
esource breakdown
structure
nterprise
environmental factors
Organizational process
assets
223
Introduction: Estimate Activity
Durations
 Estimating activity duration requires information on resources
as well as work involved for an activity
 This process is about identifying number of work periods to
complete activities
Inputs: Estimate Activity Durations
■ xpert judgment
alogous
timating rn
 Parametric
estimating
 Three-point
estimating O
 Group decision-
making
techniques
Reserve analysis
225
Define activities
Acquire project
team/ Conduct
procurements
Estimate activity
resources
Define scope
Enterprise/
Organization
chedule
anagement
an
 Activity list
 Activity
attributes
 Activity
resource
requirements
 Resource
calendars
 Project scope
statement
 Risk register
 Resource
breakdown
structure
 Enterprise
environmental
factors
 Organizational
process assets
ctivity duration
.timates
oject
documents
updates
Inputs: Estimate Activity Durations
 Activity list contains the list of activities that need to be
performed to accomplish a deliverable
 Activity attributes are supporting information about the
activity
 Activity resource requirements will depend on availability
which is available in resource calendar. Activity resource
requirements will also depend on the skill level
 Project scope statement has assumptions and constraints for
this process
Durations
 Three persons guessing is better than one person guessing
 Three point estimates uses three values to determine the duration
of an activity using the PERT formula: An optimistic estimate,
a pessimistic estimate, a most likely estimate
 PERT or Three point Estimation = (0+4M+P)/6
 Eg : Optimistic : 2 Days,
Pessimistic = 6 days & Most likely is 4
days. Three Point Estimation
 PERT = (2+(4X4)+6)/6 = 4Days.

?27
Durations
 Parametric estimating uses statistical relationship between past
duration data and variables like number of meters of road, function
point count, etc., to estimate current activity duration
 Actual duration of activities of previous projects are used to
estimate duration of activities of current project in Analogous
estimating. This is also called top-downrrz-
estimating and used when there is
limited information. Relies on expert
judgment and is reliable when current
project is similar to the previous project
It is used in the early phases of the
project
228
Durations
 Reserve analysis involves taking into consideration time buffers
when estimating duration for activities. Risks which may
impact the schedule should be considered when estimating
duration.
 This buffer can be calculated based on fixed percentage of
activity duration or based on quantitative risk analysis
.11101 20% of Estimated Duration of

activity
Paint Wall
Ouantitative Rick
12 Days Analvgig
229
Outputs: Estimate Activity Durations
- ctivity duration Develop schedule

chedule pert judgment estimates
management  Analogous Project
plan estimating documents
 Activity list  Parametric updates
 Activity estimating
attributes  Three-point
 Activity resource estimating
requirements  Group decision- Identify Risks
 Resource making
calendars techniques
 Project scope  Reserve analysis
statement
 Risk register
 Resource
breakdown
structure Project documents
 Enterprise
environmental
factors
 Organizational
process assets
230
Develop Schedule
Schedule management Schedule network Schedule baseline
plan analysis Project schedule
Activity list Critical path method Schedule data
Activity attributes Critical chain method Project calendars
Project schedule Resource optimization Project management
network diagrams techniques plan updates
Activity resource Modeling techniques Project documents
requirements Leads and lags updates
Resource calendars Schedule compression
Activity duration Scheduling tool
estimates
Project scope
statement
Risk register
Project staff
assignments
Resource breakdown
structure
Enterprise
environmental factors
Organizational process
assets
231
Introduction: Develop Schedule
 This process is all about determining planned start and finish
dates of activities in a project. The planned start and finish date
of activities are dependent on the outputs of time management
planning processes
 Developing a schedule is a sequential process
 Project schedule normally undergoes multiple iterations of
changes. The approved version of project schedule becomes
the schedule baseline
S. Projedt
Sdhedloie 1. Activity List
Approved,
Schedule Baseline
2. Protect
4. Activity Schedule
Duration Network Di
Estimates a g ra
232
Inputs: Develop Schedule
Define activities chedule
Schedule aseline
management Project
Acquire project plan Schedule
team/ conduct network schedule
 Activity list
procurements analysis Schedule data
 Activity
attributes Critical path Project
Estimate activity  Project schedule method calendars
resources network Critical chain Project
diagrams method management
 Activity resource Resource plan updates
Sequence activities requirements optimization Project
 Resource techniques documents
calendars Modeling updates
 Activity duration techniques
Estimate activity estimates
resources Leads and lags
 Project scope
statement Schedule
compression
 Risk register
Estimate activity Scheduling tool
 Project staff
resources assignments
 Resource
breakdown
Estimate activity structure
resources  Organizational
process assets
233
Inputs: Develop Schedule
 The major outputs of all the time management planning
processes are inputs to developing the schedule
 All the planning effort for time management comes together in
this process
Time Management Planning

Effort Comes Together
Activity ciroject
Resource Schedule
Requirements Network
Diagrairns
Activity List, Activity

Activity Duration
Attributes Estimates
Sclltdult
 evL-lhpresern
234
Tools & technique: Develop Schedule
> Critical path method is about determining planned start and
finish dates for an activity. We use the duration and the logical
relationships to derive the start and finish dates
7 day
 •
.3 days
.r.
• .11 days . .
I.  .- •..... __tip
3 days
r •1 1:ay. 16 11i'
5 days
1 2 1.1:11.2;—_. 2 tlnyg .
.-
6 days
235
Critical Path Method - Start at Day I (Approach 2)
11 12 15
B D
6 4
9 14 15 18 19 23
A TF = 3; FF = 0 TF 3; FF = 3 F
5 5
10 18 19 23
TF = 0; FE = 0 C E TF = 0: FF = 0
5 8
6 10 11 18
TF=0;FF=0 IF 0; FF = 0
LEGEND
ES EF ES (Early Start) = EF of predesssor + 1 Total Float = LS - ES or LF - EF

Activity Name EF (Early Finish) = ES + Duration - 1 Free Float = ES of successor - EF of present - 1
Duration (days) LS (Late Start) = LE - Duration + 1
LS I LF LF (Late Finish) = LS of successor - 1
Critical Path Method - Start at Day 0 (Approach 1)
LEGEND 11 1 15
D
14 18 18
TF = 3; FF TF = 3; F = F
5
10 10 18 18 23
TF = 0; FF = 0 E IF = 0; FF = 0
5 8
10 18
T F = 0 ; F F =0 TF 0; FF = 0
ES (Early Start) = EF of predesssor
EF (Early Finish) = ES + Duration
ES EF Total Float = LS - ES or LF - EF
LS (Late Start) = LF - Duration LF
Activity Name (Late Finish) = LS of successor Free Float = ES of successor - EF of present
Duration (days)
Ls I I LF
 When determining the Early start and early finish dates
(forward pass), leads and lags between activities should be
accounted for. Lag between 2 activities is indicated by a
positive symbol
2 days
Apply Wall
Paint Wail
Paper
(3 days)
(4 days)
tarire4t Earliest Earliest Earl
start Finish start FIng5.11
Day Day Day Day

1 3 6 9
 A lead between two activities indicates that there is an

acceleration of the second activity to start before the
completion of first activity.
Lead between 2 activities is Design — 2 days Test
indicated by a negative symbol Application
(10 days)
Application
(4 da s)
> When we have larger numbers it becomes tedious to calculate

the early start and finish dates of activities
 Formulae for forward pass:
ES of 1st activity =1
EF of any activity = ES + Duration —1
ES of next activity = EF of previous activity + 1
A B
(25 Days) (45 Days)
1 25 26 70
> Backward pass is used to calculate the Late start and Late
finish dates of activities in a network
> The amount of flexibility available can be known by
calculating the earliest and latest dates of an activity
> Scenario 1: If the Latest finish date of the last activity is not
known then Latest finish date of the last activity is the same as
the Earliest finish date of that activity
> Scenario 2: Latest finish date of the last activity is known and
is different than Earliest finish data of that activity
> Latest start date of an activity is based on the Latest finish date
and the duration of the activity
-16
1_5 1_6
C; 3U
Zb C -1
1 45 2C zi 25
I, ,
C 16
 The time that the start of an activity can be delayed without

delaying the project end date is called Total Float Total float of
an activity = LS-ES OR LF-EF
 The total float is applied to all the activities in a path. If one
activity consumes the complete float then the other activities
on the path will not have any more float
 Free float is the flexibility between two activities
Free float = ES (successor) — ES - Duration
Characteristics of critical path:
1. Duration of the total project can be obtained by adding the
duration of the activities on critical path
2. Activities with longest duration
3. Usually Zero total float
4. There can be multiple critical paths
5. When there are any changes, a new critical path may arise
6. Any delay in critical path will delay the overall
project
7. Free float cannot be more than total float
8. Does not consider resources
 Critical path method applies resources to the critical path
 Critical path gets altered when resources are applied and is
called Critical Chain
 Critical chain method is done after the critical path method
 Buffers (additional time to manage uncertainties) in the project
are considered in critical chain method
 Buffers for individual activities are taken and placed in buffer
pool
 Buffer pool is applied either at the end of the project (project
buffer) or at a place where non critical activities converge the
critical path(feeder buffer)
 PM can use this buffer to deal with uncertainties
 Schedule compressing is shortening the project schedule due
to constraints
 Schedule compression is obtained using crashing and fast
tracking. Compression should always be performed on critical
path
 Crashing is done by doing a what-if /trade-off between cost
and schedule. Best solution is one which gives greatest
compression with minimum cost
44
 What-if analysis includes evaluating multiple scenarios to
impact the schedule
 We use simulation methodology to evaluated different
scenarios. Monte Carlo simulation is most widely used
 All resource may not be available at all times of project. Hence

we perform resources leveling to address the issues of having
too many resources or less resources during various times of
project
IRL•se .8=6 •-• I-6 seltealw ram r -r
mow 1:1 *MOD'

11111111111111111111111R11
'
 er•-•••M. •-• II no. ;411:13;1111P'". Now 1.1.1L.••-•11
mopir
245
M I
Outputs: Develop Schedule
Schedule Schedule network Control schedule
management plan
Schedule baseline
analysis Project schedule
Activity list
 Critical path  Schedule data
4 I  Activity attributes
Project schedule
method AT
 Project calendars
Develop project
management plan
 Critical chain
network diagrams  Project
 Activity resource method
management plan
 Resource

requirements
Resource calendars optimization 0 updates
Estimate costs
 Activity duration techniques  Project
estimates documents
Modeling updates
 Project scope techniques
statement
 Risk register Leads and lags Determine budget
 Project staff  Schedule
assignments compression
 Resource breakdown  Scheduling tool
structure
 Enterprise
Plan procurements
environmental
factors
 Organizational Plan quality
process assets
Project documents
246
Outputs: Develop Schedule
 Project schedule includes the planned start and end date for
each activity
 Project schedule can be represented as Gant chart, schedule
network diagram, bar chart etc.
 Approved version of project schedule is called Schedule
baseline a ITTT
rwrqw[wim
.1.1.-rt+T. • .••-••
r I
ileTV1.1
T.F Yol•

.0.1•
ol
7.+< 4:7 E. taw
• ma • =3.T.
=
7 ...a, ••••• IAT
•  mg. -.x4..1..1... ••.=  T•
• L Y N . " Y r
r•• T T - • • • •
T•Jn•-• • SI :••••
almay say.a . . r a a mar•
 -•-•
•••••naaw....•••• Ts.=
.1. •
Ia- r. —44 en- 'LS.. •••
-
m-4-4 VI -11
LP- 4-m-a.1 sem
4. M11.

••• -
••••
.1 0.wpm .mr•• M... TY!. n ••••
=i-m•-•="-.. Of:
OW' •J r•
 rn1 -M • ••,.
!mem .-••• • r.T 1.-ekT• •-•-• •27,11- • .15.

•••••:,••••• • AI Ti+ J-4•011.
r.71.1. •
-
-=•an. r
I• rl•
- •••• 41w.I. • IT 1 -2 , 14.• • - 9 344
E_w_y• C mzrrrn •-•-• .•-_•zec ,•

=• ,arm Dwa, ...Err= F.T rnrl• •-•. 73ST
 .••••• 4-444 7Z.
 • 1. 1. M •-•-•
 1.4
al-Jar•-
 Ea YI MT. To..
n'T n-n,1-5•1• 11.
247
Control Schedule
Project
management
. Performance
reviews
Work
performance
.
plan
Project schedule
. Project
management
information
Schedule
Work software 0 forecasts
performance Resource Change requests
data optimization Project
. Project
calendars
techniques
Modeling
management
plan updates
. Schedule data techniques Project
. Organizational
process assets
Leads and lags
Schedule
documents
updates
compression Organizational
Scheduling tool process assets
updates
248
Introduction: Control Schedule
> This process is about monitoring and controlling the project

schedule by monitoring various factors related to schedule
> This process also handles the changes
Inputs: Control Schedule
Work
Develop project performanc
management plan  Project e
management Performance
reviews informatio
plan n
 Project  Project
management Schedule
schedule forecasts
 Work software
Develop schedule Change
performance Resource
optimization requests
data
techniques Project
 Project manageme
Direct and calendars  Modeling
manage project techniques nt plan
 Schedule data updates
execution
 Organizational  Leads and lags
Project
process assets  Schedule
documents
compression
updates
 Scheduling tool
Organizati
Organization onal
process
assets
updates
250
Tools: Control Schedule
 Performance reviews is reporting to stakeholders on the actual
start and finish dates and the percentage completion of various
activities
 Variance analysis compares the estimated start and finish dates
with the actual start and finish dates. This helps in identifying
the variance and investigating reasons for variation
Outputs: Control Schedule
cn
roject
anagement
lan
MI

Performance
eviews
Project
-4 ork
erformance
nformation
Report
performance
oo s & Tec moue

Project management Schedule
1 schedule software forecasts Perform
Work  Resource Change integrated change
performance optimization requests control
data techniques Project
Project  Modeling management
calendars techniques plan updates Develop project
Schedule  Leads and Project management plan
data lags documents
Organization  Schedule updates
al process compression Organization
assets  Scheduling al process Organization
tool assets
updates
Project documents
252
Outputs: Control Schedule
> PMP updates include changes to the schedule baseline to
accommodate the approved change requests
> When a change related to schedule is approved, the PMP
should be updated
Cost Management Overview
 Project Cost Management Plan:
— Cost Management Plan is a component of Project management plan
which describes HOW cost will be Planned, estimated, budgeted &
Controlled.
 Life cycle Costing: A broader view of Project Cost
Management that includes cost of using, maintaining and
supporting the product, service or result of the project.
 The techniques for estimating the cost involved in performing
each of the project activities are the same as estimating the time
required.
 Expert judgment, analogous estimating, bottom up estimating
and reserve analysis are some of the techniques used in cost
management.
Cost Management Processes
[7.2 Estimate Costs—The

process of developing an
ir7.1 Plan Cost approximation of the monetary
Management—
The process that resources needed to complete
establishes the policies, project activities.
procedures, and
documentation for
planning, managing,
expending, and
controlling project costs. i
7.4 Control Costs—

The process of monitoring
17.3 Determine Budget— the status of the project to
update the project costs
and managing changes to
The process of the cost baseline.
aggregating the estimated
costs of individual
activities or work
packages to establish an
authorized cost baseline.
255
Plan Cost Management
Guides on how costs are managed throughout the project course
L
 Project  Expert
management Judgment
plan  Analytical
 Enterprise  Meetings
environmental
factors
 Organizational
process assets
256
Cost Management Plan
 Sets out format and establishes the criteria for planning,
structuring, estimating, budgeting and controlling project cost
Example: Cost Management Plan may establish:
— Precision level (e.g. 100.59 to $100, 999.59 to $1000)
— Accuracy level (e.g., ±10%)
— Units of measures (staff hours, staff days, Weeks)
— Organizational procedures links
— Control thresholds — Eg : Above 2% requires approval
— Earned value rules
— Reporting formats
— Process descriptions
Estimate Costs
1
U,
.  Activity cost estimates
Cost management plan
0)  Expert Judgment
 Basis of estimates
 Human resource
management plan
=  Analogous estimating
 Parametric estimating
 Project documents
Scope baseline
CT  Bottom-up estimating
updates
 Project schedule C  Three-point estimating

Risk register U  Reserve analysis
 Enterprise cu  Cost of quality
environmental factors  Project management
 Organizational process 06 software
assets  Vendor bid analysis
N
 Group decision-making
0 techniques
258
Estimate Costs
 Rough Order of Magnitude (ROM): Accuracy
of project estimate will increase as the project
progresses
During initiation: -25 % to +75% (ROM)
Definitive : - 5% to +10 %
 Estimates include (not limited to) : labor,
material, equipment, services, facilities as well
as inflation allowance, contingency costs
Estimation Techniques
 Analogous Estimating - also called top-down estimating, which
means using the actual cost of previous, similar project as basis for
estimating the cost of current project. It is a form of expert judgment.
 Parametric Estimating — uses a statistical relationship between
historical data and other variables to calculate cost estimate for an
activity. Eg : It takes 10 days for laying 1KM road.
 Bottom up Estimating - involves estimating the cost of individual
Activities, then Work package level and then summarizing or rolling
up to get a project total.
Estimation Techniques
Analogou Estimatin
Advantag s g Disadvanta
Quick es Less Accurate ges
Less Costly to Create Requiresconsiderable experience to do
well
Botom - Estimatin
More Accurate U g and
Takes time expense to do this form
p of estimating
Gains buy-in from the team Tendenc estimates
y
for the team to pad
Based onadetail analysis of the Requireunderstood project be defined

project and s that the
Determine Budget
 Cost management  Cost aggregation  Cost baseline

plan  Reserve analysis  Project funding
 Scope baseline  Expert judg nent requirements
 Activity cost  Historical  Project documents
estimates relationships updates
 Basis of estimates  Funding limit
 Project schedule reconciliation
 Resource calendars
 Risk register
 Agreements
 Organizational
process assets
262
Budget Components
Project Management
Reserve
Budget
Cost
Baseline Control Contingency
Accounts Reserve
Activity
Work Contingency Reserve
Package
Estimates
Activity level
estimates
2 63
Cost Budgeting continued...
Cost Baseline: is a time phased
budget which is used to measure
and monitor cost performance on Funding
the project. It is a summary of Requirements
estimated costs by period and
displayed in the form of an S-
curve.
Cost
Project Funding Requirements: Baseline
Funding requirements, total and
periodic are derived from the cost r
baseline and can be established to Expected
Cash flow
exceed, usually by a margin to
allow for either early progress or
cost over run
Control costs
 Work
Project  Earned value
management plan management performance
 Project funding  Forecasting information
requirements  To-complete  Cost forecasts
 Work performance performance index  Change requests
data (TCPI)  Project
 Organizational  Performance
process assets reviews management plan
 Project updates
management  Project documents
software updates
 Reserve analysis  Organizational
process assets
.....M.-
updates
265
Earned Value Management (EVM)
 What is EVM ?
 EVM is a Methodology that combines Scope, Schedule,
and Resources measurements to assess the Project
• I NOS , 1
•
 Why EVM?
 It's too late when you're this close to the iceberg!
 PV — Planned Value - Work Planned as on particular day
 EV — Earned Value — Value of work earned / completed
 AC — Actual Cost — Actual cost spent
 SPI — Schedule Performance Index
 CPI — Cost Performance Index
 BAC — Budget At Completion
 EAC — Estimate at Completion
 SV — Schedule Variance
 CV — Cost Variance
 TCPI — To Complete Cost Performance Index
Earned Value Management
(EVM)
Tips to Remember EVM :
 Index — Divided by
 Variance — Subtraction
 Always EV first
 Schedule means PV should come
 Cost means AC should come
 > 1 Means — Good Performance
 < 1 Means — Bad Performance
Project : 4 sided Wall Construction
Schedule Week 1 Week 2 Week 3 Week 4
Work Planned 1 Wall 1 Wall 1 Wall 1 Wall
Budget 1000$ 1000$ 1000$ 1000$
Current Status Completed Completed Half of the work done Pending
Amount Spent 1000$ 1200$ 600$ NA
269
EVM Formulae Calculation Answer Interpretation of the answer
PV Planned Value of Work as on 3rd Week 1,000 + 1,000 + 1,000 3,000 We planned for $3,000 worth of work.
PV* (% work completed) Complete, complete, half done or 1,000 +

EV 2,500 We have actually completed $2,500 worth of work.
4000*62.5% (25+25+12.5%) 1,000 + 500
AC Actual money spent 1,000 + 1,200 + 600 2,800 We have actually spent $2,800
BAC Total Budget 1,000 + 1,000 + 1,000 + 1,000 4,000 Our project budget is $4,000.
CV EV - AC = 2500-2800= -300 2,500 - 2,800 -300 We are over budget by $300.
SV EV- PV = 2500-3000= -500 2,500 - 3,000 -500 We are behind schedule.
EV/AC = 2500/2800= 0.893 2 500 / 2 800 We are only getting 89 cents out of every dollar
CPI ,, 0.893
<1 and hence over budget we put into the project.
EV/PV = 2500/3000=0.833
SPI 2,500 / 3,000 0.833 We are only progressing at 83% of the rate planned.
<1 and hence behind schedule
We currently estimate that the total project will cost

EAC BAC/ CPI = 4000/0.893=4479 4,000 / 0.893 4,479
$4,479.
ETC EAC-AC = 4479-2800=1679 4,479 - 2,800 1,679 We need to spend $1,679 to fmish the project.
We currently expect to be $479 over budget when

VAC BAC-EAC=4000-4479= -479 4,000 - 4479 -479
the project is completed.
270
EVM Summary
4,000
TIME 4 Weeks
schedule variance = EV - PV = negative number - behind schedule,

cost variance = EV - AC = negative number over cost
Project Human Resource
Management
 Plan Human Resource Management
 Acquire Project Team
 4111
Develop Project Team
Manage Project Team
tdd
1111
Plan Human Resource Management
I
 Project  Organization
management charts and
plan position
 Activity descriptions
resource  Networking
requirements  Organization
 Enterprise theory
environmental  Expert
factors judgment
 Organizational  Meetings
process assets
273
Management
Inputs:
Project Management plan:
Information like project lifecycle, processes, change management plan,
configuration management plan, communication methods etc.
Activity resource requirements:
Activity resource requirements' an output from Estimate activity
resources process of Time management is used as an input to determine human
resource needs for the project which are progressively elaborated in this
process
Enterprise Environmental factors:
Existing human resources, organizational culture, market place conditions
etc. which may influence the planning
Organizational process assets :
Organizational processes, policies, Templates, lessons learned, escalation
procedures etc
Management
Matrix Based — Responsibility Assignment matrix (RAM)
A RAM is a grid that shows the relation between activities
and team members. One example of RAM is RACI
(Responsible, Accountable, Consulted and Informed)
Responsibili
Collect requirements BM R
Develop plan C A/R R I
Risk management I
A.R I
Budgeting I I R A
Scheduling R
Test plan C
A l ic 1
A R I
Management
Text oriented formats
Detailed description of the team member responsibilities,
authority etc. are specified in text oriented formats
Role
Responsibilities
Authority
Management
Tools and Techniques — Plan Human resource management
Networking : Networking is the formal and informal interaction
in organization to understand political and interpersonal
factors that influence HR management
E.g. Luncheon meetings, trade conferences, symposia etc.
Organizational theories: Provides information regarding the
way in which people, team and organization behave and the
factors that influence their behavior
Meetings: Project management team conducts meetings about
the techniques to reach consensus on the human resource
management plan
Organizational Theories
Provides information regarding the way in which people, team

and organization behave and the factors that influence their
behavior
Important areas related to individual and team behavior are

Extent of motivation
Responsibility, influence and power
Recognition
3 most important theories
Maslow's Need Hierarchy Theory
McGregor's 'X' and 'Y' Theory
Frederick Herzberg —
Motivation-hygiene theory
Maslow's Need Hierarchy Pyramid
Lower-Order Needs Higher-Order Needs
Needs that are satisfied Needs that are satisfied
externally; physiological internally; social, esteem,
Drive to
and safety needs. become what and self-actualization
one is needs
Internal esteem
capable of
factors - self becoming
respect,
autonomy Includes
External
factors - status,
recognition and
If-actualisation affection,
belongingnes
attention s, acceptance
Includes Esteem and
friendship
Security and
protection from
Social
Includes
physical and Hunger, thirst,
emotional harm shelter, sex
Sa e y and other
bodily needs
Physiological _...1
280
McGregor Theory X and Y
Having Little Ambition
Theory X Disliking Work
Assumptions about Workers
Avoiding Responsibility
Self-Directed
Theory Y . Enjoying Work

Assumptions about workers
Accepting Responsibility
Theory X assumes that lower order needs dominate and Y assumes that higher
order needs dominate
Herzberg's 2 factor Theory
Motivator factors or Intrinsic Hygiene factors or
factors Extrinsic factor
Achievement Salary
Recognition Company Policy
Responsibility Working conditions
Growth and Advancement Interpersonal Relationship
Challenging Job Security

output - Human resource
management plan
Provides guidance on how Project Human Resource should be
defined, staffed, managed, controlled and eventually released.
Roles and Responsibilities
Authority
Competency
Project organization chart
HR Plan (Contd...)
Staffing management plan
Staff acquisition
Internal or external
Resource calendar
Resource Histogram
Staff release plan
> Training needs
Recognition and rewards
) Compliance
Resource Histogram
 Charting Human resources
— Individually, department-wise, entire project team
 Need for the period is displayed
 Over allocations are highlighted
 Helps identifying resource leveling strategy
— Add resource or modify schedule
Resource Histogram
Resource Histogram
In Microsoft Project - E H S Enhancements.mpp [Read-Only] -1=11-171IxI
pa File Edit View Insert Format Tools Project Collaborate Window Help 6X
®I a+I qA I lw) Eto Erp—,..;1.6111;imiLliih.lo Group - I Hma
Tasks - I Resources - I Track - I Report -
—m.-
I February. i March
1123 1130 236 2313 220 227 I 316 I 3113 320 3127
400%-
350%-
300%-
Vignesh 250%-
0 verallocated:
Allocated: 200%
150%-
100%
50%-
Peak Units: 100% 200% 100%

7S% rC% I
Ready
Ex.T Ce,DS
287
Acquire Project Team
 Human resource  Pre-assignment Project staff

management  Negotiation assignments
plan Acquisition Resource
 Enterprise  Virtual teams calendars
environmental
 Multi-criteria  Project
factors management
decision
 Organizational analysis plan updates
process assets
288
Project Human Resource Management
Acquire Project Team
The process of confirming

human resource availability and
obtaining the team necessary to
complete project assignments
289
Inputs
 Human resource management plan (PM Plan)
— Roles and responsibility
— Project organization chart
— Staffing management plan
 Enterprise Environmental factors
— Existing information for Human resources
— Personal admin policies e.g. outsourcing
— Org structure
— Locations
Tools and Techniques
> Pre-assignment
— Project team selected in advance
— Occurs when
 specific people are promised as proposal
 Project dependent on specific expertise
 Staff assignments specified in project charter
> Negotiation
— Negotiate
 With functional managers to ensure competent personnel are
allocated
 Other PM teams to assign special or scarce resources
 External organizations for appropriate resources
 Acquisition
— Hire individual consultants
— Subcontract work
 Virtual teams
— Teams that share the same goal fulfilling their roles without
meeting in person
— Availability of technology makes it feasible
— Formats
 Teams from different goes
 Expert alone from a different location
 Working from home office
 Teams working in different shifts
> Virtual teams
— Critical success factors
 Communication planning
 Clear expectations
 Protocols to resolve conflicts etc
 Multi-criteria decision analysis:
Criteria are developed and used to rate or
score potential team member and weighted according to
the relative importance of the needs within the team.
Availability , cost experience ,ability, knowledge, skills ,
attitude and international factors of the resource are
considered to give a score and acquire them accordingly
Outputs
> Project Staff Assignments
— Project is deemed staffed when all the resources required
are assigned
— Project team directory
— Memos to team members
> Resource Calendar
— Time period each team member can work in the project
> PM Plan updates
— Roles and responsibilities.
 Interpersonal Team
 Human resource skills performance
management  Training assessments
plan
 Team-building Enterprise
 Project staff activities environmental
assignments
 Ground rules factors updates
 Resource
calendars  Collocation
 Recognition and
rewards
 Personnel
assessment tools
296
Project Human Resource Management
.:ki.ym rit1 LI ilahrp 1:1111 lw. kr

Develop Project Team mm-I ijiLlrlish id IIClim
The process of improving

the competencies, team
interaction and the overall
team environment to
enhance project
'11hre've gut 57 team managers, 36 projett
performance coordinators, and 63 etikeepi fitipiementim—
nnt bad fOr a company with urtly 18 employeecl''
297
> Objectives
— Improve knowledge and skills of team members
 So they can complete project deliverables
 Manage within cost and schedule budgeted
 With improved quality
— Improve feelings of trust and agreement among team
members
— Create a dynamic and cohesive team culture to
 improve individual and team productivity
 Allow cross training and mentoring
Develop project team - Inputs
 Human resources management plan
 Project Staff assignments:
Project staff assignment documents identify the people
who are on the team
 Resource calendars:
Identify times when the project team members can
participate
Develop Project Team T&T
> Interpersonal Skill
— Skills such as empathy, influence, creativity and group
facilitation
> Training
— To enhance competencies of the team members
— Planned training
— Unplanned training — based on observation, conversation,
project performance appraisals
Develop Project team T&T
 Team building activities
— Status review meetings
— Offsite team building workshops
— Important when diverse location people are involved
— PM should get support from org
 Introducing rewards
 Create a team identity
 Open communication
 Promote trust and
 Provide good team leadership
Develop Project Team T& T
 Theory on Five stages of team development
— Forming
 Learning about the project and their roles and
responsibilities
Storming
— Norming
 Team begins to work together, trust each other
— Performing
 Function as a well organized unit
 Interdependent, work through issues
— Adjourning
 Completes the work and moves on to other assignments
> Ground rules
— Team members share responsibility for enforcing rules
established
> Co-location
— All in one physical location enhances productivity
 Entire project or during the phase of the project
— Team meeting rooms, place to post schedule and other
conveniences
 War room for Lan-Chile, Conference room testing
> Recognition and Rewards
— Only desirable behaviors should be rewarded
 Willingness to work overtime to meet the schedule and
not overtime due to inefficiency
— Rewards should be based on things which all can attempt
achieving
— Good to do it during the project life cycle and not after
Personal assessment tools :
Provides the insight into areas of strengths and weakness.
E.g. — Attitudinal surveys, structured interviews, ability tests
etc.
Manage Project Team
Human resource Observation and Change requests

management conversation Project
oo s & Tec nisue

plan Project management
Project staff performance plan updates
assignments appraisals Project
Team Conflict documents
performance management updates
assessments Interpersonal Enterprise
Issue log skills environmental
Work factors updates
performance Organizational
reports process assets
Organizational updates
process assets
305
Manage Project Team
> Observes team behavior, manages conflicts, resolves issues
and appraise team member performance
> Requires variety of management skills for fostering teamwork
> Combination of skills — communication, leadership, conflict

management to name a few
Manage Project Team - Inputs
> Project Staff assignments
> Human Resources management plan
— Roles and responsibilities
> Team performance assessments
> Performance reports
— For schedule control, cost control
— Helps determining resource requirements throughout the
projects
Issue logs
Organizational process assets
— Certificate of appreciation, bonus structures, organization
perks
Manage Project Team T&T
> Observation and conversation
— Used to stay in touch with the work and attitudes of project
team members
> Project performance appraisals
— Clarification of roles and resp
— Constructive feedback to team
— Develop individual training plans
— Establish specific goals for future
 Conflict Management
— Sources could be scarce resources, scheduling
priorities
and personal work styles
— Team ground rules, group norms should help reducing
conflicts
 Conflict could be from team issues
 Openness resolves conflict
 Resolution should focus on issues not individual
> Seven Sources of Conflict
— Schedules, Project priorities, Resources, Technical opinions
— Admin procedures, Cost and Personality
> Factors influencing conflict resolution
— Relative importance
— Time pressure to resolve
— Position taken by players
— Motivation to resolve conflicts
Manage Project Team — T& T
> Conflict is best resolved by those involved in the conflict
> Six Techniques for resolving conflicts
— Withdrawing / Avoiding
— Smoothing / Accommodating
 Focus on areas of agreements and not differences
— Compromising
 Trying to satisfy all parties
— Forcing
 Win-lose
— Collaborating
 Incorporating multiple view point
 Leads to consensus and commitment
— Confronting / Problem solving
 Resolving by examining alternatives
 Requires give and take attitude
Powers of the PM
 Formal (legitimate) — Power based on position
 Reward — from giving rewards
 Penalty (coercive)
 Expert (tech or PM expert)
 Referent (Charismatic — someone likes you)
Expert and Reward is best

Penalty is Worst
Formal, reward and penalty are derived from position
) Expert is earned
> Interpersonal Skills

> Key skills
 Leadership
 Influencing
 Effective decision making
Manage Project Team - Output
> EEF
— Input to org performance appraisal
— Personnel skills update
> OPA
— Historical information
— Templates
> Change Requests
— Changing to staffing assignments
> Project management plan updates
> Project documents updates
Project Communications
Management
Potential dimensions of
communication activities
Internal and
External
Formal and
Verbal and Informal
Non verbal
Vertical and
Horizontal
Written and
Oral
Types of Communications
Internal: within the project team
Effective and active listening are also Internal
important elements of communication Vs -
E- External: customer, other projects,
Active listening is when recipient gives External vendors
continuous feedback such as nodding, -1 Listening
restating, or pare-phrasing
Formal: reports, memos,
Ensures that there is no misunderstanding Formal briefings, meetings
Vs Informal: emails, adHoc talks
Informal such as over coffee, lunch
Non-verbal can also be

Communication
paral[ngual Official: newsletters, Intranet,
Verbal
paralingual is where annual reports, company-wide
Vs Official
manner of speaking all-hands meetings
Non-verbal Vs
indicates different Unofficial Unofficial, off the record
meaning, such as sarcasm corn rnunication s
Vertical! along the organizational hierarchy -

Written: email, memo, documents, reports Written Vertical upwards and downwards
- Vs Vs Horizontal: with peers, both within and
Oral: discussions, opinions, appraisals
Oral Horizontal outside of project team
318
Qualities of Good Communication
Skills
 Listening
 Questioning
 Educating
 Motivating
 Coaching
 Confirming
 Negotiating
 Resolving
 Summarizing
 etc.
319
Project Communications
Management
Plan
Communications
Management
Manage
Communicati
ons
320
Plan Communications Management
 Project  Communication Communication

management requirement management
plan analysis plan
 Stakeholder  Communication Project
register technology documents
 Enterprise  Communication updates
environmental models
factors  Communication
 Organizational methods
process assets  Meetings
321
Plan Communications Management
> Planning and developing an approach for the project
stakeholder communication
> This approach depends on the information needs, requirements
and Organizational assets
> This process ensures effective and efficient communication
with all stakeholders
> Key is to determine
 who will communicate with whom
 who will receive what information
Poor or Inadequate Communication
> Leads to problems such as
 Sending information to wrong audience
 Delay in information delivery
 Misunderstanding or misinterpretation of the message
Plan Communications Management -
Inputs
 Project management plan
 Stakeholder register
 Contains all the details of project stakeholders.
 This register needs to updated regularly as the
stakeholders may change and add newly throughout the
project lifecycle
 Enterprise environmental factors
 Organizational process assets
Communication Channels
 Total number of communication channels

= n(n-1)/2
where n — number of stakeholders
Example:
A project with 6 stakeholders has 6(6-1)/2= 15
communication channels
Communication Models
 Medium for the information exchange between Sender and
Receiver
 Sequence of steps in
basic communication
model:
— Encode MEDIUM
&MOIR'
— Transmit message MESSAGE
NOISE
— Decode
— Acknowledge
326
— Feedback / Response
F eedhack
Communication Methods
> Interactive
— most efficient way to ensure common understanding by all
participants
> Push
— Letters, memos, emails, fax, reports, blogs, etc.
> Pull
— e-learning modules, knowledgebase, etc.
Plan Communications Management -
Outputs
 Communications Management Plan
— This is the main output of this process
— It contains
 Stakeholder communication requirements
 Format and type of communication
 Frequency of distribution of information
 Communication constraints, etc.
 Project Documents update
 Project schedule, Stakeholder register, etc. may be
updated
Manage Communications
 Communications  Communication Project

management plan technology communications
 Work performance Communication Project
reports models management
 Enterprise
environmental  Communication plan updates
factors methods  Project
 Organizational  Information documents
process assets management updates
systems  Organizational
 Performance process assets
reporting updates
329
> This process helps to
 Create
 Collect
 Distribute
 Store
 Retrieve
 Dispose
project information, as per the communications plan
> Key benefit of this process is that it enables effective and
efficient communications flow between project stakeholders
Effective & Efficient Communication
 Effective Communication
 Is the information that is provided
 in right format
 at the right time 41
 to the right audience

 with right impact
 Efficient Communication
 Providing only the information that is needed
Manage Communications - Inputs
> Communications management plan
> Work performance reports
 Contains Status information & Project performance
 These reports should be comprehensive, accurate and
available in timely manner
> Enterprise environmental factors
> Organizational process assets
Tools & Techniques
> Communication technology
> Communication models
> Communication methods
> Information management systems
— Information is managed and distributed using tools such as
hard-copy document, email, telephone, web interface,
portals, etc.
> Performance reporting
Performance Reporting
> Provides information of baseline versus actual data to analyze
the project progress, performance and forecasts
> Report may include:
— % completion of work
— Dashboard
— Risks & issues
Manage Communications Outputs
> Project communications
 Performance reports
 Deliverables status
 schedule progress
 Cost incurred
 Issue log, Project schedule, Project funding
requirements, etc.
> Organizational process assets updates
Issue Log
 A powerful tool for PM to monitor /manage stakeholder
expectations
 A written/documented log with project issues
 Helps to monitor who is responsible for resolving specific
issues by a target date
A Sample:
C.9:41
. Silo
'-+Trwurte. 1 aftl:1 .. ........ j
.. . :.•1111116 .1..Eitro.• A. Moe I )c-o-r., r Ail[141 111116:41

netlitlyi 1).klumum'
Detcriptim d iseb:ci !piker!
:111K I I 6111LNLI knka:troz.
P. Dale
71F44;10t. C. n xinil
0.4w5
A Hep awto kfkOtteeig "At,
. ..—... Lr- .61. . .. ... .1
. . .. I. . . 1041411 LEL-61611E4ln it !blurt
336
Control Communications
Project 4 Information
.
oo s & Tec niques
management management
plan systems
Project
 • 0 Expert judgment
communications Meetings
Issue log
Work
performance
data
Organizational
process assets
337
Work
performance
information
Change requests
Project
management
plan updates
Project
documents
updates
Organizational
process assets
updates
Control Communications
> Process of monitoring and controlling communications
throughout the project life cycle
> Helps to ensure the information needs of all the stakeholders
> Key benefit is to ensure an optimal information flow among all
the participants
Control Communications - Inputs
> Project management plan
> Project communications
 Delivery status, Schedule progress, Costs incurred, etc.
> Issue log
> Work performance data
 It compares the results with the performance
measurement baseline to arrive at the analysis
Control Communications Tools
& Techniques
> Information management systems
 Standard tools for PM to capture and distribute project
costs, schedule progress and performance
 Examples are spreadsheet analysis, presentations, etc.
> Expert judgment
> Meetings
Control Communications Outputs
> Work performance information
 Detail level of information about project progress
> Change requests
 Updates in Forecasts, performance reports, issue log,
etc.
Project Risk Management
 Plan Risk Management
 Identify Risks
 Perform Qualitative Risk Analysis
 Perform Quantitative Risk Analysis
 Plan Risk Responses
 Control Risks
Plan Risk Management
 Project  Analytical  Risk

management techniques management
plan  Expert lan
 Project charter judgment
 Stakeholder  Meetings
register
 Enterprise
environmental
factors
 Organizational
process assets
343
> Risk management plan is vital for the success of a
project.
> This process helps to (1-c'— -lent
+II rIk 11,41 C11 7' V‘'‘ CI +.I CI r‘- r%
activities for a project
344
Plan Risk Management - Inputs
> Project management plan
> Project charter
> Stakeholder register
—
PLANNING
Tim-w- Ale
Tools & Techniques
 Analytical techniques
 Expert
judgment
 Meetings
Analytical Techniques
> Analytical techniques are used to define Risk management
context of the project
> A "Risk management context" is a combination of
— Stakeholder risk attitudes (risk averse, risk seeking,
average) and
— Risk exposure of the given project
> "Strategic risk scoring sheets" are used to calculate high level
assessment of risk exposure of the project
Plan Risk Management - Output
> "Risk management plan" is the output of this process.
> It includes the following:
 Methodology or approach
 Roles and Responsibilities
 Budgeting
 Timing
 Risk Categories
 Definitions of Risk Probability and Impact
RBS
 Risk Breakdown Structure (RBS) — A hierarchical
representation of risks according to their risk categories
 Risk categories are created by grouping the potential causes of
risk
Example: RBS
PROJEfl
RISKS
Schedule Cost Scope

Risks Risks Risks
Nlow Testing
hoar Lade of t'undinl:
L Method
::14 lin:ding Nisthod
Reciutrenieni Inflation New Technology

1 __ irrli:Criaini its 13ncertainti cs
insufficient Labor Rum

So7pe Creep
Rt.-sources Changes
St4h44vniroiclor
PerfnnnEMI:e
incxperienced
Esfimatm EFrgulation
Changes
350
Identify Risks
isk management plan

 Documentation  Risk register
ost management plan reviews
Schedule management  Information gathering
lan
• uality management
techniques
 Checklist analysis
lan
Assumption analysis
uman resource  Diagramming
anagement plan techniques
Scope baseline  SWOT analysis
ctivity cost estimates  Expert judgment
ctivity duration
stimates
Stakeholder register
roject documents
' rocurement
ocuments
nterprise
- nvironmental factors
 rganizational
process . ssets
351
Identify Risks
 The process of determining which risks may affect the project
and documenting their characteristics
 Key benefit is that it enables the documentation of existing
risks and knowledge about it to the project team to anticipate
events
Identify Risks - Inputs
 Risk management plan
 Cost management plan
 Schedule management plan
 Quality management plan
 Human resource management plan
 Scope baseline
 Activity cost estimates
 Activity duration estimates
 Stakeholder register
 Project documents
 Procurement documents
 Organizational process assets
Identify Risks Tools &
Techni
ques
> Documentation reviews
> Information gathering techniques
> Checklist analysis
> Assumption analysis
> Diagramming techniques
> SWOT analysis
> Expert judgment
354
Information Gathering
Techniques
 Brainstorming LI
 Delphi Technique
 Interviewing
 Root cause Analysis
Diagramming Techniques
Cause and Effect Diagram
System or process flow charts
Influence Diagrams
356
Cause and Effect Diagram
 Also called as Ishikawa diagram
Cause Effect
Equipment Process People
Problem
Secondary
cause
Pri mly
cause
Materials Environment Management

Identify Risks Output
 "Risk Register" is the output of this
 Risk Register contains
 List of identified risks
 List of potential responses
358
Perform Qualitative Risk Analysis
Risk Risk probability Project
oo s & Tec ni•ue

managemen and impact documents
plan assessment updates
Scope baselin Probability and
Risk register impact matrix
Enterprise Risk data
environmental quality
factors assessment
Organizational Risk
process assets categorization
Risk urgency
assessment
Expert judgment
359
Qualitative Analysis
>A process of prioritizing the risks based on
probability of occurrence and impact
 Enables PM to minimize the level of
uncertainty
 Enables PM to focus on high-priority
risks
Perform Qualitative Risk Analysis -
Inputs
 Risk management plan
> Scope baseline
 Risk register
Perform Qualitative Risk Analysis
Tools & Techniques
 Risk probability and impact assessment
 Probability and impact matrix
 Risk data quality assessment
 Risk categorization
 Risk urgency assessment
> Expert judgment
Probability & Impact Assessment
 The level of probability of each risk and its
impact on each project objective (cost,
schedule, quality, etc.) is evaluated
 Risks are rated as per the probability & its
impact
 Risks with low ratings are included as part of
watch list for future monitoring
 Negative effects are Threats
 Positive effects are Opportunities
Risk Probability & Impact matrix
RISK MATRIX
VL L VI11
Impact
Risk Data Quality Assessment
 Once the risk is identified, the data about the
risk is to be evaluated for its accuracy and
reliability
 This is a technique to evaluate the degree to
which risk is understood and the accuracy,
quality, reliability and integrity of the data
about the risk.
Risk Categorization
Risk categorization can be done by
 Sources of risk (using RBS)
 area of project affected (using WBS)
 Project phase
 Common root causes
Perform Qualitative Risk Analysis -
Output
-1F
_ •--- .
Perform Quantitative Risk
Analysis
 Data gathering
isk
and  Project
management documents
plan representation
techniques updates
Cost
management  Quantitative risk
plan analysis and
modeling
Schedule techniques
management
plan  Expert judgment
Risk register
Enterprise
environmental
factors
Organizational
process assets
368
Quantitative Analysis
> This is a process of assigning a numerical priority rating to all
the risks individually
> When the risks are quantitatively analyzed, a decision can be
made to reduce the project uncertainty
> Re-prioritization is done once the numerical values are
assigned to all the risks.
Perform Quantitative Risk Analysis -
Inputs
> Risk management plan
> Cost management plan
> Schedule management plan
> Risk register
Perform Quantitative Risk
Analysis Tools & Techniques
Data gathering and representation
techniques
Quantitative risk analysis

and modeling techniques
Expert
judgment
Data Gathering and Representation
Techniques
 Interviewing
 Probability Distributions
- used in modeling and
simulation
C and k a Impart ya
113
C.J
Quantitative risk analysis and
modeling techniques
Sensitivity Analysis
Expected monetary
value analysis (EMV)
t
,
Modeling and
simulation
EMV Analysis
 This is a statistical concept that calculates average outcome of
the choices we make
 An example of analysis under uncertainty
HI. PrO2bilily
4
.1gC $70.lrnpael
Vei nelor A - $38,500
mod
Ckir..-644
%i!:! r•Z-f:f 7.5.% firg4a1:511ily
S55,0C.C. impoci
541,250
P.112Impact
374
Perform Quantitative Risk Analysis -
Output
' r Ilkrn-.
.r.'..'i...1%Me.07•110k.V.011.1.:%Lire&_L.A.L..
 r -ze.•-r .. . J P :L. Alr .1.—rii r • ' Iiii i'4•17 • .....- .....14.7..--
li-IN.11`1.1...r•di rINNLI!'•
4.4.4.0, a 17 - - I- - II—! • — . L.., .=.,
-if4.;. • i ...,.... . ,
..1 41.117.k. nit... _.:..E : ... ... • • ..-.. •,I • ... 1
m•-:•Parjr.r...V dirlif . • • r.l.on r.
1I 1....01211,1-15~700ror  a1-0:..i.._
- -- r. lir .A.%E•rm....:11 -r
 l'' LeAr...n alkm .... • -I Lir
imonet Risk
II0 k
Plan Risk Responses
 Risk  Strategies for  Project

management negative risks management
plan or threats plan updates
 Risk register  Strategies for Project
positive risks or documents
opportunities updates
 Contingent
response
strategies
 Expert
judgment
376
Plan Risk Responses
> This is a process of developing various actions
 to enhance opportunities and
 to reduce threats
> Key benefit is to address the risks and to respond according to
the analysis made in previous processes
Plan Risk Responses - Inputs
>Risk management plan
>Risk register
Risk management
plan
Risk register
378
Plan Risk Responses
Tools &
 Strategies for negatiRdsilliggeS
 Avoid
 Transfer
 Mitigate
 Accept
VOL.e
 Strategies for positive risks or opportunities

 Exploit
 Enhance
 Share
 Accept
 Contingent response strategies
 Expert judgment
Contingent Response Strategies
 Few definitions
Fallback plan —
 Reaction to a risk that has already occurred and the

response applied is ineffective
> Residual Risks —
 these risks are expected to remain after applying the risk
response strategy
> Secondary Risks —
 New risk occurred because of the risk response
implementation
> Contingency Reserves — Known Unknowns
> Management Reserves — Unknown Unknowns
Plan Risk Responses - Outputs
 Project management plan updates
381
Control Risks
ork
 Risk assessment
 Project
management
Risk audits
Iinformation
performance
plan  Variance and Change requests

trend analysis Project
 Risk register
 Technical management
 Work performance plan updates
performance measurement Project
data
 Reserve analysis documents
 Work
performance  Meetings updates
Organizational
reports process assets
updates
382
Control Risks Inputs
 Project management plan
 Risk register
 Work performance data
 Work performance reports
C-ICC
----7
383
Control Risks Tools & Techniques
> Risk reassessment
 Should be done regularly
> Risk audits
 Examining and documenting the effectiveness of risk
responses
> Variance and trend analysis
> Technical performance measurement
> Reserve analysis
> Meetings
Control Risks - Outputs
> Work performance information
> Change requests
 Recommended corrective actions
 Recommended preventive actions
Agile SDLC
Agile Software Development vs. Waterfall Software Development
There isn't a single methodology that you can apply across all projects. However,
many teams are moving toward an adaptive methodology, such as Agile, and moving
away from the predictive, Waterfall methodology when developing software.
The conventional Waterfall development method follows strict phases, sticking to the
original requirements and design plan created at the beginning of the project.
A project manager spends time negotiating milestones, features, resources, working

at length in the planning stages of a project, usually developing a full-blown project
plan that details how the work will be moved through many gates to completion.
Customers finalize requirements before development begins and then a lengthy

development process occurs, with the project manager tracking every movement of
the project through each handoff and finally on to delivery. If everything goes well,
this process produces an on-time, on-budget release.
is Agile SDLC
The history behind Agile software development is one of frustration with the
traditional waterfall methodology. Agile is designed to accommodate change and the
need for faster software development (as discussed in the Agile Manifesto's Values
and Principles).
The project leader typically facilitates the work of the development team, eliminates
bottlenecks, and helps the team stay focused in order to deliver software iterations on a
regular basis. It is less about milestones than it is about hours, feature selection,
prioritization, and meetings.
Agile Versus Traditional Waterfall
Metric Waterfall
Planning scale Long-term Short-term
Distance between Long Short.
customer and developer
Time between Long Short
specification and
impl entation
Time ro discover Long Short

prohlems
Project schedule risk High 1.0W
Ability to respond T,ow High
quickly to change
388
Increased Consumer Expectations
As consumers today we want and expect innovative products:

faster, cheaper and with better quality than those we've
seen
in the past.
A little video for everyone.

The new iPod nano
389
Increased Work PressurP
As knowledge workers, our business tools have

improved our cud .w/ity ,,, Lic pi tit-JUL-Mc, raising work
expectations.
Misaligned Expectations
However,
Instead of this...
Productivity driving Customer value
An overview of agile
 The term 'agile' is viewed in many different ways
 Well-known frameworks referred to as 'agile ways of working'
 Well-known behaviours, concepts and techniques characterising agile
 The Agile Manifesto comes closest to a single definition — it was
created as an alternative to 'waterfall' processes
 Agile addr esse d the ne w de mands pl ace d o n t he deli very of sof t ware .
The Agile Manifesto
We ore uncovering better ways of' develocinq

software by dicing or helping others do it.
Through this work we hove come to volue:
Individuals and over mosses

intemetions and tools
Comprehensive
Working sof t wa re aver
documentation
Customer, col over Contract negotiation
to bortEtion
Responding Following a *n
10 chonge
That is, wlie there is volue in the items 31 the right,

we, value the fern on the left more
Waterfall or Iterative and Incremental
linear, serial iterative and incremental
111, IM.MMI. IM.MMI. 0==Mil. II==MP
, ,
Imor EMI .11M.11 I= MiP IIMMil
4= Mlb 11=mMIO IN=mMIli IMmMilt
L.
l ......---•-8 11
_______
1 Tme
Time
someth ng something
goes into goes into
operational operational
Waterfall Agile
use use
 It can be viewed in many ways
**
v A* — Timeboxed approach for
developing software
(Repeat) — A collection of techniques
Product Sprint Sprint Shippable — Us i ng t he S cr um
backlog backlog Agile
(+ * daily stand-up meetings) basics
product
f r ame w or k.
(perhaps in
the form
of user stories)
Beyond a basic view
 Vision, Roadmap and Releases

I A more
comprehensive view  Non-IT situations
would include:
 Project work
 Flow-based working
••••• Ego •••• •••
 A wider mind-set.
Agile
Frame
works
 Many frameworks are recognised as being agile
 Some are more common than others
 So me are only applicable to IT.

Scrum Kanban
Lean Lean Startup
XP SAFe DAD
DSDM/AgilePM
DevOps
FDD Crystal ASD
Agile behaviours, concepts and techniques
Along with the agile frameworks there are a variety of behaviours,

concepts and techniques that are seen as being part of the agile way
of working
Behaviours Being collaborative, Self-organizing, Customer Principles. Values. Mind-set.

focussed, Empowered, Trusting not blaming
Concepts Prioritising what is delivered, Working iteratively Fundamentals
and incrementally, Not delivering everything, Time
focussed, Inspect and adapt. Kaizen. Limiting WIP
Techniques Burn charts, User Stories, Retrospectives, Practices. Tools.

Timeboxing, Measuring flow
Starting up a Project and Initiating a Project
 What you may find:

— Up-front work — how much is done?
 emergence
 what constitutes 'enough'
— Visioning and chartering
— Sprint zero, discovery
— Starting with a backlog.
 What to do:
— Assess the level of uncertainty
 Cynefin
— Define things at the right level
 Outputs, Outcomes and Benefits
 Project Product Description
 High level requirements
— Define things in the right way
 To enable agile to work easier e.g. outcome focussed
— Set the project up in an appropriate manner
 Integrating with agile teams e.g. role names
 Impact of frequent releases of products to enable and provide
benefits.
— The use of workshops

How it might look
— More informal control and communication
Cynefin
 A decision making framework to help determine the level
of complexity
 It describes the relationship between 'cause and effect'
 It determines how complex an environment is

Complicated
The Cynefin Framework
Governing constraints
Tghtly coupled
sense-analyze- respond
Good Prat'
Complex  Five domains

Enabling constraints
Obvious Loosely coupled  Disorder is the fifth
Tightly Constrained Disorder probe -sense-respond
No degrees of freedom
sense-categorize-respond
Emergent Practice  Can be used to assess the output,
Best Practice
outcome or benefit
 Can be used to assess the project
9 environment
Chaotic
tacking constraint
Ii
 Collaboratively assessed to avoid
De-coupled
act-sense-respond people's natural tendencies.
Novel Practice
F.
Cynefin
 Projects will typically exist in the Complicated

or Complex domains
 If work exists in the Obvious domain it will probably be
handled as Business As Usual
 If work exists in the Chaotic domain it will probably be
unsuitable for existing processes.

Business Case general view of agile
 It may not exist in some agile environments as there may
be a focus on value assigned to features instead
 May be created at the beginning of a piece of work as part
of 'sprint zero' (or similar term).

Business Case - guidance
 The Business Case may be affected by the amount being delivered

 Early delivery of benefits will affect the Business Case
 The minimum viable product (MVP) will need to be clearly stated
 Project viability is not the same as the MVP
 Best-case, worst-case and expected-case will relate to the
amount of features delivered
 Where there is high uncertainty this may take very little time.
Defining value
 Can often be subjective

 Easier to assign relative values
 Value can be assessed in many ways
e.g. revenue, reducing costs, customer satisfaction
 There is a need to differentiate between output, outcome
and benefit
 Outcome and benefit need to be measurable
 The Business Case should be flexible to maximise the benefit
 Focussing on benefits is helped through Collaboration.
Requirements and User Stories
 They need to be well defined and prioritised so that they are
conducive to the agile way of working
 Many terms describe what a product does or how well it does it
e.g. Requirement, Product Description, User Story
 Definitions should be at the right level and decomposed at
the right time allowing then to evolve
 Boulders, rocks and gravel as a metaphor.

User Stories
 Similar to requirements
As a <role>, I want to <function>, so that <benefit>.

 Additional information would include:
— Acceptance Criteria
— Effort involved
— Value
 They are a starting point and not fully defined.

User Stories
#37 A good user story
AS A Stock controller
I WANT TO Know if my stock level

 Takes skill to create good User Stories:
is very low
— INVEST is used by many
SOTHAT don't run out arid foil to
fa' c customer's order
Eft
I — So is a definition of 'Ready'
2 PTO toe qua), (TteI
 Epics are a type of User Story that need to
'N • • .eilt ...IT:- 4.
be broken down
 Technical Stories can be used for Non-
A user stony of limited USerulriess
functional requirements e.g. performance or
speed.
AS A Store monoger
WANTTO I'danageastone
SO THAT The store is managed effectively

Requirements Prioritisation
 Two approaches frequently used are:
— MoSCoW
— Ordering (1,2,3,...,n)
 MoS CoW st ands for:
— Must have
— Should have
— Could have
— Wont have for now.
MoSCoW and ordering
 Is it really a Must? Must have

(ink refill)
— Will it work without it?
Won't have
(company logo)
— Is it worth delivering it, without it?
 Can it be decomposed?
 Ordering is appropriate when: . Should have (the barrel)
— There is little dependency between items
A
— Items do not naturally group together. Could have (the top)
\ If the fop is provided then the hole in the top
(to avoid choking) is a Must have
Using prioritisation
 Can be used on:

— Non-functional requirements
— Quality Criteria (Acceptance Criteria)
— Quality Review activities
 Prioritisation handles change but is it detail change or

baseline change?
 Detail change can be handled dynamically.
Change general view of agile
 Agile embraces change
 Agile responds to it, welcomes it
 Change to the detail is typically viewed as positive
 Change to the basel ine may not be.

Change - guidance
 PRINCE2 could be said to be more cautious
 Blending with agile controls significant change
 Allows responsive change at the detail level
 This typifies the marriage of the two
 It is important that baselines use the correct level of detail
 Starting-up a Project and Initiation a Project can create the correct
environment for this.

Change - guidance
 Requirement definition can be binary or like a spectrum
 Goo d ri sk manageme nt can lesse n t he i mpact o f change
 S o can go o d C o nf i gur ati o n Manage me nt
 Empowered self-organizing teams at the delivery level handle
change dynamically within defined tolerances.

The Feedback Loop
 Gather feedback as quickly as possible
 Ideally 'true' feedback from the end customer
 Many forms of feedback loop exist such as:
— OODA (Observe Orient(ate), Decide, Act)
— PDCA (Plan, Do, Check, Act)
— PDSA (Plan, Do, Study, Act)
— Build, Measure, Learn (Lean Start-up).

Organisation general view of agile
 Self-organizing
 Two common roles:
— S cr um Mas te r
— P r o duct Ow ne r
 Less prominence for:
— P r o je ct Manager/ T e am Manage r r o l e
— Requirements Engineer/Business Analyst (or similar) role.

Organisation - adjustments
 C o mmo n agi le co nce pt s may need t o be adj us t e d

 Agile teams prefer to be led and coached as oppo sed to managed
— Mapping the Team Manager roles needs to be handled
appropriately
 Co mmo n agile gui dance refer s t o a si ngle P ro duct Ow ner
 C o mmo n agi le gui dance doe s not have a P r o je ct Manage r r ol e
 The Team Manager role needs to integrate into an agile delivery
team.
Organisation
 How the Project Manager relates to the delivery team is key

 There are 3 options:
— Leave the delivery team roles as they are
— Leave the delivery team roles as they are but identify a single
point of contact for the Project Manager
— Create a Team Manager role in the delivery team

 The choice will be made according to the circumstances of the
project.
Organisation the delivery team
Usuall y re prese nted by s ome or all of t he f ollo wi ng:
 Some one t o le ad the te am

 Someone from the customer (or at least someone to represent the
customer)
 A team to create the product
 Someone to assure the quality of the product
 Someone to coach the team (which includes coaching them in agile)
 Multi-skilled 'generalising specialists'.
Organisation project structures
All roles need to be conversant with working in an agile way
Customer
representative (s)
Key
Customer
DeWeryteam
representative ®
ject
(Yager
Suppler
representative
SupOer
Customer subject
Customer subject
matter 6 CSME SSME 1
representative(s) e) cocertl Supplier CQA SSME 2
expert representative(s)
SQA
(SupOier
(Customer subject
subject meter
pert 2)
r
expert
Qudity assurance Customer

(Customer representative
representative
Coach
(project support)
Servant Leadership
 Usually seen as best practice for leading an agile team

 The best way to lead a team is to be its servant
 The focus is on:
— Empowerment
— Collaboration
— Facilitation
 How much this can be used depends on context
Incorporating a wider Customer view
 The simplicity of the Product Owner role has limitations in a project

context such as:
— Project size
— Size of the role

 The detailed view and the wider, higher level view needs to be
reflected
 A specialist role can be used to define requirements
 Senior User is ultimately responsible
 The Product Owner operates best from inside a delivery team.
Working Agreements
 Used to evolve the effectiveness of a team
 Typically they are made visible
 Collaboratively defined, built by consensus
 Need to be built with care.

 Generally there is relatively less prominence given to the
area of risk in agile
 Agile concepts mitigate many risks associated with
other approaches (e.g. waterfall)
 The level of formality should be appropriate
 Address risk during stand-up meetings
 Agile has risk areas of its own
Managing Product Delivery
W hat y o u may f i nd:

 A strong focus in this area
— Managing product delivery
— Product delivery practices
 Scrum manages pro duct deli very

What to do :
 Use Work Packages appropriately
• It is a vital interface/link to be managed
 Perhaps define tolerances on what is delivered at the Work Package

level
 Ensure that Product Descriptions are defined at the right level
 Agree and/or give guidance on such areas quality, releases and

risk.
How it might look
 Work Packages are collaboratively defined
 Reporting arrangements have an appropriate level of formality
and transparency
 The wider prof ect context is understood.

Work Packages
 A vital interface to blend to the project environment
 Collaboratively defined
 Agreed levels of detail and formality with respect to reporting,
tolerances, product descriptions and quality criteria
 Guidance on behaviours, risk and the frequency of releases
 Guidance on quality checking techniques.

Scrum what is it?
 A framework for developing and sustaining complex products
 A collection of roles, events, artifacts and rules
 Created by Schwaber and Sutherland (c. 1995)
 A way to assess the efficiency of your practices so that you
can improve.
Scrum theory
 Fo unde d o n e mpirical pro cess co ntr ol theory

 Decisions based on evidence
 Covers three areas:
— Transparency
— Inspection
— Adaptation.
The Scrum team
 Self-organising
 Cross-functional
 Flexible, creative, productive
 The Roles:
— The Product Owner
— T he D e ve l o p m e nt T e a m
— The S cr um Mas t er.

Scrum events
 Events are prescribed to create regularity
 Every event has a maximum duration
 The Sprint is at the heart of this concept
 Forces transparency
 Opportunities to inspect and adapt.

Scrum
SM
Product SpHnt
Backlog Backlog
ig .., The
*SprintManning Sprint
*Sprint Review
Meeting *Sprint
Retrospective
1161111
40prrre
rrt TNT
The S Scrum events
 The Sprint
 Sprint Planning Meeting
 Daily Scrum Meeting
 Sprint Review
SM
Product Sprint
 Sprint Retrospective. Backlog Backlog
*Sprint Planning *Sprint Review,

Meeting *sprint Retrospective
sm
1-celaprrent
Team
Scrum artifacts
 Product Backlog
 Sprint Backlog Drhyrwnint

Tram
 Increment.
shi
Pro duck Sprint
Backlog BacIdog
osi The Sprint

*Sprint Rrrirw
*Sprint Retrospect M
nr PQ
Demi print
Tenn
Plans general view
 Agile puts a lot of emphasis on planning

 Agile mostly uses Empiricism as opposed to Rationalism
 Planning style:
— Based on features
— A team-based exercise
— Plan at the last responsible moment
 Using a points scoring system to estimate is popular although there are other
ways.
Plans - guidance
 PRINCE2 supports any planning style

 A PRINCE2 project needs an end date
 Both agile and PRINCE2 accept the premise of planning horizons
 Higher level plans may more conventional but not necessarily
 Product-based planning can be used easily for any level of plan (see
Appendix D)
 Planning needs to consider dependencies and grouping similar
work items.
Estimation
 Using some form of points system is popular

 Estimating starts with relative estimates and is carried out as a
team
 Team member s e sti mates s hould no t be affe cte d by ot her s
 Differences are discussed
 The Fibonacci sequence or T -shirt sizing are very popular systems.

Progress general view
 Similar to plans in that it is of particular importance
 Burn charts and WIP boards are commonly used
 The bigger picture relates to key agile values (e.g. transparency).

Progress - guidance
 What is being delivered is of the most importance
 It may take several sprints to understand how things
are progressing
 In terms of 'how are things going?, it is a necessity to be in
control at all times
 Many agile techniques can be used at any level of a project
 The audience for any technique will need to be comfortable
with the format.

Burn charts
 A popular technique that comes in two forms:

— a burn-down chart
— a burn-up chart
 Displayed in the form of a graph with an x and y axis
 They show the current situation and the current rate of
progress
 Burn-down charts assume the amount of work doesn't change
 Burn-up charts should be used if the amount of work is likely
to change
 They f ocus o n w hat has bee n co mplete d.
Burn charts
Burn-down Burn-up
ractual
effort
i work
added
effort
remaining
total
time millinumilin""Ine
Information Radiators
 Creates visual information that can be accessed immediately
 Best created and maintained manually
 Contributes significantly to transparency
 Information is 'pushed' as opposed to 'pulled'
 Can display a wide variety of information
 Holding a daily stand-up meeting by a display enables it to
be updated immediately.
Quality general view of agile
 Prominent techniques such as the definition of 'Done'
and acceptance criteria address quality control
 Concepts such as 'test as you go' or 'test first' are used for
testing and quality checking
 Evolving the definition of 'Done' is commonly used
 In some agile environments there may not be a lot of emphasis
given to quality planning and quality management, during the
start of a project.
Quality - guidance
 Product Descriptions are flexible (e.g. they can be User Stories)

 The Project Product Description purpose would preferably
be defined as an outcome
 Quality management and quality planning includes:
— Which tools and approaches are to be used
— The role of the customer (an essential ingredient)
— Assessing and costing the resources
— Quality control considerations.

Quality how to test
 Care needed when transferring these concepts from the

software development domain
 Common agile terms include:
— Test-driven Development (TDD)
— Behaviour-driven Development (BDD)
— Definition of 'Done'
— Definition of 'Ready'
— Refactoring
— Technical debt.
Quality in relation to Scope
---
 Customer Quality Expectations are set

and this level needs to be maintained
 Quality is defined by
quality criteria
 Scope is defined by the
products themselves.
Frequent Releases focus area
 Frequent releases are important when using agile

 The advantages are:
— Early delivery of benefit
— Allows for feedback
— Reduces risk (e.g. of delivering the wrong product)
— Gives confidence of how the project is progressing
— Fosters stakeholder engagement
— Makes releasing easier
 Needs to be planned (Product -based Planning can be used)

 A release may not go into the operational environment.
Frequent releases
 Planned releases would show on Project and Stage Plans
— Showing when they will take place
— Sho win g wh at f eatu res a re to be relea sed

 Different views need to be taken into account when planning
releases
— The Project Board want to establish appropriate stage
boundaries
— Early benefits may need to fund later parts of the project
— Enabling a product to fail fast, if it is going to fail
— Products can be delivered too quickly (leading to disruption)

 Releasing into operational use is the ideal situation otherwise a
staging area needs to be used which compromises agile to a
degree.
Retrospectives
 Reviews the way of working (not what was produced)

 A significant technique when working in an agile way
 They need to be planned and structured (such as with a workshop)
 Covers what went well and what didn't go so well
 Improve little by little and little and often
 Keep them effective by introducing variety
 Feedback can come in the form of facts or feelings.
Directing a Project
What to do
 Manage by Exception with the emphasis on:
— Empowerment
— The amount being delivered
— Rich information flows
— Value being delivered.

Directing a Project
How it might look

 Pulling information rather than having it delivered
 Collaborative working
— Trusting
— Absence of a blame culture.

Agile contracts
 Contracts may need to be created in a way amenable to agile

 An issue with traditional contracts is that requirements change and
someone will need to allow for this
 Trust is important as it determines the amount of risk that is
shared
 Guidance on structure in order to create the right behaviours:
Focus on outcomes or throu h s ut in reference to out s uts.

Define the amount of customer involvement required in order to collaborate with the supplier in the best way.
Buy amounts of time relating to timeboxes with deliverables.
Allow for a premature end to the project.
Relate incentives to the amount delivered (value or throughput).
Avoid including detailed requirements.
Prioritize the requirements and identify a MVP.
Handle changing requirements by trading out the less important ones.
If preferred, build a contract up from the 'minimum' to start with.
Closing a Project
 Defined processes may only exist in mature agile

What you may find environments
I  Regular handovers have resulted in activities
becoming second nature.

Closing a Project
 Check against the original baseline

What to do
 Evaluate the use of agile on the project
 Ensure the formality of User Acceptance
is appropriate
 Finalise documentation that has been created
iteratively and incrementally.

Closing a Project
 A workshop is used
How it might look
 Benefits are already being delivered
 The majority of the information has already been
completed.
Rich communication focus area
Communication problems need to be proactively addressed

Effective communication is fundamental to agile
Communication takes place in many ways therefore people
should interact appropriately
Communication channels:
— The written word
— Visualisation
— Verbally by telephone
— Verbally face-to-face.
Rich communication
 Face-to-face should be favoured as a faster and clearer channel

 Technology and the level of formality needs to be assessed
 There is a role for the written word but is has disadvantages
 A Project Manager (or Team Manager) needs to be aware of how a team is
communicating
 C o mmuni cat i o n ne e ds t o be o r gani s e d and pl anne d.
Workshops
 Harnesses interactions and creativity

 Ideally run by a neutral facilitator who manages the workshop
 Preparation is essential
 Many tools and techniques exist
 Workshops can be used at any point on a project
 It is important to get the group dynamics right
 Correctly run workshops can create high quality outputs quickly
 This leads to clarity, consensus and ownership.
Kanban and the Kanban Method
 Kanban systems are visual management systems that limit the

number of work items in circulation
 Kanban should be seen as a way to increase agility through:
— Improved day-to-day decision making
— The deferral of commitment
— Reduce d le ad t i mes
 In PRINCE2 Agile it is applicable in a project context to time boxes.

The 6 general practices of the Kanban Method
1. Visualize W [P
— To show how work is progressing
— To show what is still to do
— To show what problems exist. li
Recdy Bvild (14) Test (3) Deploy
,;... rsiii
ti .,1 Ready Done
X El
ri.
Al
1
A
Pkeked
2. Limit 'Work in Progress' (WIP)

— A fundamental concept in Kanban that may
appear counterintuitive
— WIP limits underpin the 'pull' system WIP knits
— Kanban avoids scheduling work at specific times

— It pulls work when capacity exists , --, 1 r---' ---i.
Ready Bud {14) Test (3)
— Reduces the impact of task switching r
Deploy
and multitasking. L.',d i— - Ready Done
--- ,
it,
.m
iir
Fl.!117 • d , - ,
Te
ti=
Blocked
3. Manage the flow

— The team constantly looks at ways to maximise flow
— Waste is removed as quickly as possible.
4. Making policies explicit / WIP knits
— Boundaries need to be clearly defined about how a team

works Rea 1,
Build (4)
r
Test (3) Deploy
dy r
— Policies should evolve over time. i_jte ,_
,:-.-
--,
I
Ready , Done
. - 1-
ILiN:
Lo i:-
r
1
I
III_
Lf11- 1
a
II
Blocked
5. Implement feedback loops

— Ultimately, value being delivered is judged by the final
consumer
— Quantitatively assessing this will directly affect what will
subsequently be delivered.
6. Improve collaboratively, evolve experimentally

/ WIP knits
— The method builds on collaboration through
experimental improvement 1, r
Ready Test (3)
Build (4) Deploy
— Process improvement is everyone's business every day. r ___________ 7
ij te-, I
Ready , Done
.=..
 ,:-.--jLr i.
Lo i-:-
III,
21
01
Blocked
Kanban — further guidance
 Scrumban is the application of Kanban where the

underlying process is based on Scrum
 Policies may exist for similar work items as flow may be more
MP limits
predictable
 A team may look to improve how the system works by I, r

Ready Build (I-1) Test (3) Deploy
carrying out experiments in a controlled and objective -- ail

I
Ready
uI Done
=..
way. Li
° ,..
Lr
N. li
.
L!-,...--7
Blocked
Cumulative Flow Diagrams (CFDs)
Column Counts Cumulative Flaw Diagram (CFD)
Ready
 Cumulative Flow
Readyto 1 I Build
Day Ready Build Test
Deploy
Deployed Diagrams (CFDs) track
Test
2 4 4 1 0 work items and show the
8
-------q 4 5 0 3 I Ready to Deploy amount of work in each
10 3 3 5 1 3 column each day
3 4 3 3 30 Deployed
11 2
4 0
 In simple terms WIP is
12 4 3
13 ~3 2 5 1 8 25 the vertical difference
14 7 2 r 3 8 between the top and
20
15 7 2 4 0 13 bottom lines whereas the
4
16 7 2 5 0 1 13
15 horizontal difference
17 5 3 5 0 14 shows the lead time.
18 5 3 4 0 15
10
14 4 2 5 0 16
20 3 2 3 0 lq 5
--4
21 3 1 0 22 _.
0
q 10 11 12 13 141516 17181q 20 21
1
Kanban hints
 A timebox (e.g. a stage) can be run with or without sprints
 Kanban aims to reduce the cost of delay
 Change to existing processes should be gradual
 Little's Law (in simple terms):
 Little's Law is used for forecasting.
Average number of items in the system =

average arrival rate x average time an item spends in the system
Lean Start-up
 Core concepts are:

— Build, Measure, Learn
— Create a Minimum Viable Product (MVP)
— Fail fast
— Validated learning.
 Lean Start-up focusses on uncertainty, learning and handling change

 It refers to 'shortening or accelerating the feedback loop'
 Learning needs to be measurable.
Lean Start-up
 If you are going to fail, fail fast — the key point being 'the later you fail the later
you learn'
 A 'pivot' is a significant change in direction as a result of something
major surfacing that wasn't expected
 Minimum Viable Product (MVP) - 'version of the final product which allows
the maximum amount of validated learning with the least effort'.
 An MVP may not go into operational use and may be an experiment
 Releasing frequently can help with metrics.
Health Check (Appendix C)
 A checklist to assess how well a project is going from an agile

perspective
 The totality of answers will give a general indication
 Covers the following areas:
Environment Techniques
.‘,
Transitioning to Agile
 Agile is an enabler that helps solves problems and leverage

opportunities
 Create a baseline before starting the journey
 There are distinctly different types of success on a project:
— The success of the Business Case
— The success of the project
— The success of agile
 Investing in agile needs to be measured in order to gauge success.

Advice for a Project Manager using agile
 Covers the following areas:
— Collaboration and self-organisation
— Transparency, Communication and Exploration
— Environment
— Plan, Monitor and Control.

THANK YOU

Agile Development Student Handbook v4.2

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Agile Development Student Handbook v4.2

Uploaded by

Copyright:

Available Formats

Identify defects

2. The Project Life Cycle

3. Project Management Concepts and Methodologies

5. Initiation-The PM Role: Baselines

1Managing current business operations

 A chan ge is introdu ced by me ans of Projects

 A temporary organization that is created for the purpose of delivering

i/To keep control over the specialist

i/To manage the risks effectively Plan 11114.

Operations Management is an ongoing Projects are temporary and help the

For example when:

The goal of process management is to improve processes continually. Improving operational

Project Manager Operational Manager

Role ends with project Routine

Temporary team Stable organisation

Many different skills Specialist skills

Work not done before Work repeatable

Time, cost and scope constraints Annual planning cycle

Why Project Managers Need to Understand the

 Changes in the organization's mission and strategy

— Project managers must respond to changes with appropriate decisions about

— Project managers who understand their organization's strategy can become

 Mistakes caused by not understanding the role of projects in

— Focusing on problems or solutions with low strategic priority.

The Strategic Management Process:

— Requires strong links among mission, goals, objectives, strategy,

Project Portfolio Management Problems

A Portfolio Management System

 Design of a project portfolio system:

— Selection criteria depending upon classification

— Managing the portfolio of projects.

A Portfolio Management System

 Multi - Weighted Scoring Models

Nonfinancial Strategic Criteria

 To make it difficult for competitors to enter the market

 To develop core technology that will be used in next-generation products

 To reduce dependency on unreliable suppliers

 To prevent government intervention and regulation

Multi-Criteria Selection Models

 Multi - Weighted Scoring Model

Applying a Selection Model

 Helps identify proper goals for projects

 Helps everyone involved understand how

Managing the Portfolio

 Senior Management Input

— Decide how to balance available resources among current projects

 The Priority Team Responsibilities

— Publish the priority of every project

— Reassess the organization's goals and priorities

Project Portfolio Matrix Dimensions

Project management is the planning, organizing,

Project Life Cycle Overview

2. Complete project decomposition, resulting in the work breakdown structure. Project

9. Put together a stakeholder analysis and communication plan. When will

Life Cycle Phase IV: Project Control

It also involves keeping changes in the project to a minimum.

2. Redistributing resources that were assigned to the project.

3. Filing any administrative paperwork regarding the project's completion.

4. Preparing any stepping stones for the next project.

A process group is a logical grouping of activities, inputs, tools,

A framework that describes the activities performed at each stage of a

 Requirements — defines needed

 Test — check if all code modules

 Easy to understand, easy to use