COURSE STRUCTURE

1. Introduction to Project Management, understanding

contracts & negotiation principles
5. Risk management

2. Project startup & scope management

6. Managing human resources

3. Schedule and cost management

7. Communications management

4. Managing quality
8. Project monitoring and control, role of the PMO &
managing troubled projects

1
INITIATE AND PLAN – ROLES AND RESPONSIBILITIES

▪ Engages the project planning and execution team ▪ Engages the Project Manager
▪ Scopes the project ▪ Supports the Project Manager in engaging the
▪ Performs project tailoring planning team
▪ Constructs the Estimate, Schedule and Project ▪ Reviews and approves the Project Management
Management Plan Plan
Project Account
▪ Sets up the project ready for execution
Manager Lead
▪ Identifies key risks and starts risk management
▪ Defines metrics to measure success
Solution / Technical
Lead*
▪ Collaborates with Project Manager on technical
items * As project progresses this role
transitions into the wider project team
▪ Helps Project Manager identify required members
of the planning team
▪ Provides insight on schedule and cost items
especially from a solution or technical perspective
START UP & PLANNING – PHASE DESCRIPTION
During the Sales lifecycle, a client presents an opportunity for work. The work is qualified and when the client’s needs are well
formulated the project is initially defined.
The Initiate and Plan Phase determines or refines the scope, the measures of success, and the desired outcome of the project.

The Start Up and Planning phases

Sales to Project Delivery Life Cycle consist of:
▪ Defining and/or refining the
high level scope and
Pursuit Project Delivery
requirements;
▪ Developing and baselining
Qualify Develop Negotiate &
Start Up
Closed
project management plans and
Propose & Execute
Opportunity Opportunity Close
Planning
own controls to satisfy those
requirements;
▪ Providing a commercially
Project Start Up & Planning sustainable journey.

Project planning activities are

iterative by nature
INITIATING THE PROJECT

Description

Pursuit Handover
Checklist
Statement of Work

Register
Project

Define Project

Initial Although there are some

Assessment Iterative
components of Start Up in
the Pursuit Phase, this
Start Up module focuses on the
Project Management processes after the deal has
Checklist Project
registration been signed
NOW YOU ARE ASSIGNED…
▪ Project Manager is assigned once a project request is
authorized by the Account team
▪ Project Managers should have an understanding of:
̶ Project scope and objectives
̶ Account organization
̶ Contract requirements
̶ Program and project management processes
̶ Rules of engagement
̶ Account Governance Model
▪ Project Manager takes part of the responsibility for
the Customer relationship
INITIAL ASSESSMENT

If you don’t know about it - you cannot deliver it! Work with sales and
solutioning to obtain necessary documentation

Pursuit handover
checklist -
LEARNING CHECKPOINT
Question 1: To understand the project scope and objectives, the
Project Manager should be familiar with:
A. Organization of the account
B. Company policies for project management
C. Rules of engagement
D. Governance Model
WHY IS IT IMPORTANT TO DEFINE THE
PROJECT?

▪ Describes/clarifies the project opportunity at a high level

̶ WHY — Background and objectives set the context of the
project
̶ WHAT — Scope of the work and deliverables
̶ HOW — Technical and management approach
̶ WHO — Key people, roles as well as client responsibilities
▪ Develops an understanding of the expected results
▪ Establishes a working relationship early
▪ Involves all parties to get commitment
▪ Surfaces and resolves issues early
▪ Aligns expectations — first step forward together

Note: This information should be in the Statement of Work

DEFINING THE PROJECT FACILITATES UNDERSTANDING AND AGREEMENT
▪ Defines the “work”
̶ Problem boundary = Scope
̶ Solution = Approach
Both are quantified
Scope and approach are
▪ Promotes understanding of how the “work” will be done
documented in the Statement
̶ Scope + approach ==> Work Breakdown Structure (WBS)
of Work
̶ Top-level WBS
o Hierarchical, product-oriented decomposition of the
scope
• Includes all the products and only the products that Supported by the processes
defines the solution documented in the
o Relates scope, approach, and deliverables to budget
▪ Defines the contractual baseline of the project Project Management Plan
CHECK SCOPE COMPLEXITY USING THE CHANGE IMPACT MAP
• People in the enterprise • Team structures
• Their culture • Organizational units
Initially done as part of the high level
• Their roles and capabilities • Support teams
corporate risk assessment to help
understand the complexity of the scope Organization
and impact on the client
Process Location
What change will the project introduce Organization
• Processes
into the client’s environment? • Countries or
regions
• Campuses
• Functions • Buildings
• Sites
Consider the extent to which the client’s • Operations Business
Process Location • Work locations
• Activities • Complexes
situation and opportunity can be
expressed by the change hexagon Technology
Data
Data Technology
Sanity check each impact area: Has this • Databases • Platforms
changed? Which? What? Where? How • Entities
Application
• Operating systems
many? • Attributes • Database technology
• Data migration • Networks
Application
Answers determine which parts of the • Data cleaning • Processors
client’s business are within or outside the • Systems • Screens

boundaries of the project • Subsystems • Reports

• Interfaces • Modules
RELATIONSHIP EXAMPLE BETWEEN THE CHANGE IMPACT AREAS

Location Organization Business Process Application Data Technology

HQ Order Order • Order Mgmt Customer

Birmingham, AL Processing to Cash • Inventory Items/Products
• Accounts Rec.
• Billing Sun
Server

Plants Production Plan • Demand Planning BOM

– AL Planning to Produce • Inventory Planning Routings
– OH • Enterprise Planning
– FL
– CA
PROJECT SCOPE
BUSINESS PROCESS CHANGE IMPACTS – EXAMPLE SCOPE STATEMENTS

In Scope
Analysis of the following Customer IT security processes are in scope:
▪ Technical vulnerability assessments
▪ Vulnerability alert management
▪ Network intrusion detection monitoring/Security event correlation
• Security compliance monitoring on critical, managed servers

Out of Scope

Analysis of any third party security organizations’ processes including:

▪ Antivirus infrastructure implementation
▪ Web content filtering
▪ Firewalls/VPN’s implementation

Any processes that are not identified as in scope are out of scope – but check assumptions!
 PROJECT SCOPE
ORGANIZATION CHANGE IMPACTS – EXAMPLE SCOPE STATEMENTS

In Scope
The following Organization Resources will participate in the Northeast Region OpCo Facility Infrastructure — OpCo Retrofit
▪ Distribution Operations Representatives (4)
▪ OpCo IT Representative (13)
Organizations that will be affected by OpCo Retrofit Results
▪ OpCo Logistics (includes Warehouse Ops)
Organizations to Participate in Design Review and Issue Resolution
▪ Distribution Services
▪ Corp IT
▪ Steering Committee (4)
▪ NE OpCo Presidents (14)

Out of Scope
▪ Corporate and Field organizations not specified as “in scope”
▪ All Organization outside the NE Region not specifically defined as “In Scope”

Any organizational components that are not identified as in scope are out of scope but check assumptions!
LEARNING CHECKPOINT
Question 2: Elements of the change impact map are:

A. Business Process, Organization, Risk, Technology, Infrastructure, Data

B. Business Process, Organization, Location, Technology, Application, Data
C. Business Process, Organization, Risk, Technology, Approach, Data
D. Business Process, Organization, Location, Technology, Contract, Data.
LEARNING CHECKPOINT
Question 3: Which is the best description of project scope?

A. All of the features and deliverables your project will deliver.

B. All of the products your project will make.
C. All of the people involved in your project.
D. All of the work you will do to build the product.
PLANNING

Start Up & Planning Description

▪ Engage Project Manager, Register Project and ▪ Plan the project by developing an appropriate work plan of activities and a management
Obtain Approval
plan for assigning, monitoring and controlling the work required.
▪ Define Project
Project
▪▪ Tailor
Tailor Project
Project Management
Checklist Create Work
Iterative
Breakdown
▪▪ Refine
Refine Requirements
Requirements (Tailored) Establish Project Structure
Planning
Environment
▪▪ Create
Create Estimate
Estimate Define and
Sequence Activities
Launch Project Estimate Project
▪▪ Create
Create Schedule
Schedule Planning Work and Costs Finalize Package and
Plan for Risks Project Secure
▪▪ Complete
Complete Management
ManagementComponents
Components Refine Create Project Financial Plan Approval
Requirements Schedule
Prepare Plan
Components
Key Outputs Conduct
SAP
Tailoring Project Repository
▪ Assigned Project Manager Identify and
Provision Tools
Project
▪ Project Tailored Management
Plan
▪ Project Budget Planning
▪ Project Schedule

▪ Project Management Plan

ESTABLISH PROJECT PLANNING ENVIRONMENT

▪ Ensure planning phase is funded and tracking is in place

▪ Create a phase plan if required
▪ Establish project information repository
̶ This might be using the establish account repository or creating a project
specific one in SharePoint
▪ Resource and engage project planning team
▪ Ensure equipment and facilities and system environment is in place for
planning
LAUNCH PROJECT PLANNING

▪ Conduct project kick-off meeting

̶ Clarify and communicate project goals, risks, assumptions,
milestones, deliverables, timelines, roles and responsibilities,
acceptance criteria and expectations
̶ Check who your stakeholders are – is everyone appropriately
included?
̶ Provide customer with an orientation on the approach
REFINE REQUIREMENTS
▪ The Pursuit Support Model has the solution source,
which captures the high-level requirement in the
Sales cycle
▪ Requirements need to be refined with the client to
ensure whatever we build meets those requirements
▪ They are captured in requirements documentation
for the project
▪ Check:
− Requirements make sense and do not contradict
each other
Remember, project scope flows from requirements, not
− Can be readily measured as met or not the other way around!
− Includes handover and operational use
requirements
− Are tied to scope that enables them – via the
requirements traceability matrix
CONDUCT ANY SOLUTION TAILORING

Offering Delivery Kit / Solutioning

Playbook
Integrate and tailor for client
solution Dependant on the scale of
project some solutions will
WBS & Offering Deliverables Defined WBS & Solution Deliverables already have delivery kits,
Scope where this is already done this
for you (you still need to
Offering Cost Model The Approach Cost Model sanity check this of course)
Template (Estimates)

Refined
Offering Schedule Solution This enables you to accelerate
Requirements
Template Schedule your project planning
CREATE THE WORK BREAKDOWN STRUCTURE (WBS)

Requirements
Work Breakdown Structure

Project

1.0 Requirements 2.0 Architecture 3.0 Analysis 4.0 Testing 5.0 Deployment

Scope
1.1 Capture 2.1 Define/ Prototype 3.1 Conduct Data 4.1 Execute Integration
Solution Architecture 5.1 Train and Deploy
IN SCOPE OUT OF SCOPE Requirements Analysis Testing

1.1.1 Capture 2.1.1 Define

Business Organization 4.1.2 Execute System
Requirements Architecture Testing
Approach
4.1.2.1 System Testing
1.1.2 Stakeholder 2.1.2 Define Data Cycle A
Matrix Architecture

4.1.2.2 System Testing

Cycle B

Define and Sequence Activities

CONTACT CENTER WBS EXAMPLE
SERVICE CLOUD DEPLOYMENT WBS EXAMPLE
CREATE SCHEDULE
We’ll be covering this in depth in the schedule management module of
this course

▪ Prepared in conjunction with the Work Breakdown Structure, to

define and sequence tasks (HOW we will deliver the scope)
▪ Allocate resources to tasks
▪ Establish successor — predecessor relationships
▪ Identify cross-project dependencies
▪ Make sure all tasks have resources assigned and levelled
▪ Work with Project Management Office to integrate into any
external account dependencies
▪ Schedule must be approved by:
̶ Account Lead
̶ Customer (only approves macro schedule)
CREATE ESTIMATE

▪ Use the Scope and Work Breakdown Structure as starting point Project
Scope

▪ A bottom-up estimate is recommended, to ensure that we can deliver our

remits within sold scope, time and budget, and to the right quality
▪ Estimates, schedule, and scope are created iteratively as they affect each
other (e.g. more scope, means more work which must be budgeted and
scheduled for)
▪ Estimates must include labor costs and expenses
▪ Review estimate with an Estimating Specialist/ Independent Reviewer
for reasonability
Project Project
▪ Estimates must be approved by the Account Team (Account PMO) Schedule Estimate
PLAN FOR RISKS
We’ll be covering this in depth in the risk management module of this course

▪ Scope, schedules and estimates are all about certainty – risk management
is about managing the uncertainty
▪ Identify threats and opportunities within the project delivery
▪ Determine how they will be managed and watched for changes
▪ Safeguard the project against threats becoming issues
▪ Guide opportunities (as appropriate) to do better than planned
▪ Risk management approaches must be approved by:
̶ Account Lead
̶ Customer (only approves macro schedule)
THE STRUCTURE OF THE PROJECT MANAGEMENT PLAN

The set of ‘rules’ that guide our delivery and governance of the project

Project Management Plan

1.0 Introduction 5.0 Schedule Management 9.0 Risk Management 13.0 Procurement Management

6.0 Project Team Organization, Roles

2.0 Project Overview 10.0 Communications Management 14.0 Internal Sections
and Responsibilities

11.0 Quality and Performance

3.0 Scope and Approach 7.0 Requirements Management
Measurement Management

4.0 Deliverable Acceptance and Typically additional to SOW Template

8.0 Change Management 12.0 Configuration Management
Project Closure
Typically covered by SOW Template

Caution must be taken so the Project Management Plan does not conflict with or duplicate the Statement
of Work or Project Charter
FINALIZE FINANCIAL PLAN
We’ll be covering this in depth in the financial management module of
this course

▪ Determine the cost and pricing of delivering the project

▪ Making sure we are able to deliver to revenue, cost and margin ‘as sold’
▪ Ensure it is clear ‘who pays for what’ and in alignment with the
contract
▪ Understanding when we can invoice and what we need to provide to the
client, along with the invoice for payment
▪ Financial plan must be approved by:
̶ Account Project Leader (APL)
̶ Customer (only approves budget for project)
PACKAGE AND SECURE APPROVAL
▪ Perform Internal Review
▪ Approve Project Management Plan and related project controls
(schedule, budget, risk register, etc.)
▪ Obtain Account Team/Account PMO approval
̶ Once all Account Team approvals have been obtained, the Project Management
Plan is delivered to the client for approval.
▪ Obtain Client approval
̶ At a minimum the Statement of Work, Macro Schedule and the Priced Estimate
must be approved by the client
̶ Depending upon account and contract requirements, some or all of the products
within the Project Management Plan may need to be approved by the client
̶ The Project Management Plan must be maintained throughout the project’s
lifecycle and that the project team should be kept informed of changes to the
Project Management Plan.
̶ Remember to remove the internal portion before sending the plan to the
customer
INITIATE AND PLAN

Start Up & Planning Outcome

▪ Engage Project Manager, Register Project and ▪ Baselined and authorized project ready for execution
Obtain Approval
▪ Sustainable management processes to support project requirements
▪ Define Project

▪ Tailor Project

▪ Refine Requirements

▪ Create Estimate

▪ Create Schedule
Key Outputs
▪ Complete Management Components
▪ Assigned Project Manager

▪ Project Tailored

▪ Project Budget Once the budget, schedule and related plans are approved by the account team
and client, they cannot be changed without using the change control process
▪ Project Schedule

▪ Project Management Plan

SEEING THE WHOLE PICTURE – THE INITIATE AND PLAN PHASE

Project
Management
Pursuit Handover Checklist Create Work
Iterative
Checklist Breakdown
Establish Project Structure
(Tailored)
Statement of Work Planning
Environment
Define and
Sequence Activities
Launch Project Estimate Project
Planning Work and Costs Finalize Package and
Project
Register
Plan for Risks Project Secure
Financial Plan Approval
Baselined
Refine Create Project
Project
Requirements Schedule
Prepare Plan
PM Define Project Components
engaged Conduct
SAP
Initial Tailoring Project Repository
Identify and
Assessment Iterative Provision Tools
Project
Management
Plan

Start Up Planning
Project Management
Checklist Registered
project
LEARNING CHECKPOINT
Question 4: Which of these statements are true?

A. Project Management Plan defines the contractual requirements for the project.
B. Scope and approach are documented in the Statement of Work.
C. Work Breakdown Structure is the result of schedule definition.
D. Project Management Plan documents our delivery and governance processes that will be used for this project.
KEY-TAKEAWAYS

✓ The Start Up and Planning phase consists of:

▪ Defining and/or refining the high level scope and requirements;
▪ Developing and baselining project management plans and controls to satisfy those
requirements;
▪ Providing a commercially sustainable journey
✓ Project planning activities are iterative in nature.

✓ Remember to revisit your Project Management Plans once the changes occur.

✓ Clearly define the boundaries of your project and ensure that you and your stakeholders
share the understanding of them.
 Deepak Hemadri

SCOPE MANAGEMENT
AGENDA

Managing requirements
Scope definition
Work Breakdown Structures
Verification
Control
PROJECT SCOPE MANAGEMENT
Processes required to ensure that the project includes all the work
required and only the work required to complete the project
successfully

Product Project
scope scope
❑Contractual basis of work
❑Basis for defining project effort
❑Identify deliverables at a level comprehensible by both vendor and Client

❑Failure to define scope results in

▪ Profitability impact
▪ Increased risk of non-acceptance of deliverables
SCOPE MANAGEMENT PROCESSES

Collect
Define scope Create WBS
requirements

Control
Verify scope
scope
 COLLECT
REQUIREMENTS
COLLECT REQUIREMENTS
❑Key customer needs include:
… is the process of defining and documenting • Stated Functionality
stakeholders' needs to meet the project objectives • Acceptable Quality
• Affordable Cost
• Vendor Stability
Inputs Tools & Outputs
Techniques
❑Project Managers are responsible
• Project charter • Interviews • Requirements for delivery of functionality within
• Stakeholder • Focus groups documentation budget and desired level of quality.
register • Facilitated • Requirements
workshops management
• Group plan
creativity • Requirements ❑Proper requirements development
techniques traceability and requirements management
• Group decision matrix helps managers address customer
making needs.
techniques
• Questionnaires
and surveys
• Observations
• Prototypes
WHAT ARE REQUIREMENTS?
• Requirement :
- A necessary attribute of a system,
- a statement that identifies a capability,
- characteristic or quality factor of a system in order for it to have value
and utility to the user

• Requirements Engineering
- Process of establishing what the customer requires from a system
‘Don’t assume that all your project stakeholders share a common
notion of what requirements are. Establish definitions up front
so you’re all talking about the same things’

Why is Requirements Engineering Important?

TYPES OF REQUIREMENTS
Business Requirements

• Describe high level business objectives of the organization and the vision of WHAT the system
will do
• Describe WHY the organization undertakes the project
• Document it in vision and scope document

User Requirements (general, system requirements is specific )

• Describe the TASKS that users must be able to perform with the product
• Document it in user requirement specification

Systems and Software Requirements

• Contractual Requirements

• Functional Requirements
• Describe specific SOFTWARE FUNCTIONS that the system should do or must be
implemented to enable users to perform their tasks
• Document it in SA&D report

• Non-functional Requirements
• Defines a constraint on the design of the system (performance, security, implementation and so
on).
• Equally critical as functional requirements
• Classified as product, organizational and external requirements
REQUIREMENTS ANALYST
Soft Skills
• The role as played by:
• Analysts in responding to RFP • Listening
• Transition Managers in large engagements • Interviewing and
• Project Managers and Tech Leads in ongoing questioning
development • Analysis
• Facilitation
• Primary responsibilities • Observation
• Gather, analyze, document and validate • Writing
customer’s needs • Organizing
• Bridge the gap between customer’s state • Modeling
requirements and clear specifications • Team Building
• Creativity
• Tasks • Other skills includes
• Define Business Needs Modeling
• Identify Project Stakeholder
• Elicit Requirements
• Analyze Requirements Others
• Write Specifications • Domain and Business
• Model the Requirements • Task Knowledge
• Other tasks: Facilitate, Prioritize, Lead • Qualification
Validation, Manage Change
REQUIREMENTS PHASES

Elicitation Analysis Specification Verification Management

REQUIREMENTS ELICITATION

Requirements Elicitation is the process of Interviews with users

discovering the requirements for a system The system’s environment

by communication with: Business objectives

Marketing requirements
Contractual obligations
- customers,
- system users Working in user environment
- and others who have a stake in the system Analogous or existing systems
development. Change suggestions, problem reports
User modifications
User group meetings
Workshops
Prototypes
Studies
Innovation work
Questionnaires
Consultants & Trainers
Observation/Fieldwork
WRITING A REQUIREMENTS SPECIFICATION
Elements of an RS
Purpose of Good Requirements Specification • User goals
• Set Project Scope • Context Description
• Represent different viewpoints
• Get stakeholders agreement • Functional Requirements
• Basis for design and progress review • Non-functional Requirements
• Delivery acceptance • Constraints
• Assumptions

Guidelines
What to write?
- Separate functionality from implementation.
- Define the environment and its interaction

What to ensure?
- Use standards
- Must be extensible and tolerant of incompleteness
- Format and content should be relevant to the problem

What to avoid?
-Technical details
GUIDELINES FOR WRITING REQUIREMENTS
❑Use active voice, e.g. ‘The system shall do something’
❑Use terms consistently as defined in the glossary.
❑Encourage the use of the word ‘shall’, instead of ‘should’, ‘may’ or ‘might’ that don’t
clarify whether the function is required.
❑Read it from the developer’s perspective to see if a requirement statement is sufficiently
well defined.
❑Avoid long narrative paragraphs that contain multiple requirements.
❑When stating a requirement in the form, “The user shall….”, identify the specific actor
whenever possible.
❑Use lists, figures, graphs, and tables to present information visually.
❑Avoid using vague and ambiguous terms, such as ‘adequate’, ‘acceptable’, ‘fast’, ‘several’,
‘user-friendly’, ‘simple’, ‘easy’, etc.
❑Emphasize the most important bits of information. Techniques include sequence, use of
visual contrast, such as shading.
STRUCTURING A REQUIREMENT
• Distinct Elements of a Requirements Statement
• The User – who needs this requirement
• The Result – what the user is looking for
• The Object – that this requirement addresses
• The Qualifier – measure of how the requirement is delivered.

• Example : Incomplete requirement :

“The system must include the products”
What’s missing?
a) Who (user) needs this requirement?
b) What are the users trying to achieve (result)?
c) What products (object) are being addressed?
d) When (qualifier) is this required?

Example re-written:
“The sales agent must review all the new products, one day prior to the
product launch.
EXAMPLES OF POORLY WRITTEN REQUIREMENTS
• Example#1: “The XML Editor shall switch between displaying and hiding
non-printing characters instantaneously”
Better way to write: “The user shall be able to toggle between displaying and hiding all
XML tags in the document being edited with the activation of a specific triggering
mechanism. The display shall change in 0.1 second or less.”

Example#2: “Charge numbers should be validated on line against the master

corporate charge number list, if possible.”
Better way to write: “At the time the requester enters a charge number, the system shall
validate the charge number against the master corporate charge number list. If the
charge number is not found on the list, the system shall display an error message and
shall not accept the order.”

Example#3: “The new solution must satisfy all the requirements that the
existing system satisfies.”
This requirement is not clear and will never be able to be traced. Go through the
application and capture all the detailed requirements of the current system.
USE CASE
❑Defines the expected behavior of the system, using scenarios
from the user’s point of view

❑Consists of different attributes which describes the details or

level of abstraction

❑Provides a step-by-step instruction with concrete end results and

is easy to understand

❑Can be modeled with the use of tools and integrated with the
other phase of development.

❑Supports capturing data requirements

MISUSE CASE
❑Negative form of Use case

❑Helps in identifying, managing and mitigating threats

❑Useful in identifying missing function, exceptions and safety

requirement.

❑Can result in new Use case

SCOPING & PRIORITIZATION OF REQUIREMENTS
Criticality Meanings
High A mission critical requirement; required for next release
Medium Supports necessary system operations; required eventually but
could wait until a later release
Low A functional or quality enhancement; would be nice to have
someday, if resources permit

Priority Meanings
Essential / The product is not acceptable unless these requirements are
Mandatory satisfied
Conditional / Would enhance the product, but the product is not
Desirable unacceptable if absent
Optional Functions that may or may not be worthwhile
REQUIREMENTS APPROVAL
• To ensure that ALL stakeholders agree on the scope.
• Steps include:
• Identify approver list
• Distribute RS document
• Solicit feedback and document the same
• Incorporate suggestions that do not affect other stakeholders.
• Process involves:
• Reviewers (SMEs & QA) review content and scope.
• Approvers (Project Sponsors, Sr. Management & Project Manager) approve
the scope and allocate resources.
• Project Team (Architect & Programmers) accepts the document as problem
definition statement.
• Results in a Baselined RS
REQUIREMENTS BASELINING
❑Baseline is sponsor’s approval for what they want and project team’s
agreement on what to deliver.
❑Forms the basis of all future work - the operational Bible
❑Identifies expected capability and limits application boundary.
❑Established when requirements are reviewed and approved
❑Changes to baseline reviewed through impact on baseline (and cost and
schedule) and formally approved
❑Failure leads to scope creep and unstable phase exists.
❑A baseline is dynamic.
REQUIREMENTS TRACEABILITY
❑It is the ability to follow the life of the requirements in forward and backward
directions:
❑Vertical traceability is tracing requirements to deliverables in other phases
❑Horizontal traceability is mapping the relation between different requirements
in the same phase
❑Primarily helps assessing the impact of requirements change
❑Helps verify against scope creep
❑Helps trace design rationale later.
❑Focuses on baselined requirements
❑Provides audit/process visibility
❑Uses automated tools.
VALIDATING REQUIREMENTS
Correctness Completeness and consistency
of the
requirements Clarity
collected
Conflicts

Feasibility

Compatible Verifiable
Traceable
Modifiable
Conformance to standards
Stated once
Understandable
REQUIREMENTS BEST PRACTICES
Identify sources of requirements
Elicitation
Separate “Needs” from “Wants”.

Define a Requirements Development Plan

Get extensive User Involvement Validate the requirements with the users.

Identify ‘Product Champions’

Gather different types of requirements

Create a Collaborate partnership between the

users and the development team

Focus elicitation discussions on User Tasks,

rather than features and functionalities
REQUIREMENTS BEST PRACTICES (CONT’D)
Model the requirements
Analysis
Create prototypes

Prioritize requirements as early as possible

Adopt templates to write specifications

Specification Uniquely label each requirement
Maintain project glossary
Capture requirements using Use Cases
Baseline the requirements
Manage Changes to requirements
Use tools for managing requirements
Maintain Requirements Traceability

Inspect requirement documents

Verification

Test the requirements

PITFALLS TO AVOID
Trap Symptoms Solution
Confusion over Means different to different people Understand levels and types of
‘Requirements’ requirements. Define them first.
Inadequate Customer Busy users, surrogate users Get user commitment early and agree
Involvement responsibility, identify user classes and
product champions
Vague and Ambiguous Developers are guessing what is intended. Avoid subjective terms, ‘etc’, develop
Requirements prototypes and review understanding.
Un-prioritized Users insists all requirements are equally Prioritize requirements
Requirements important and all are high
Building Functionality Observed functionalities that doesn’t Prepare backward traceability
No One Uses achieve business goals
Analysis Paralysis Unable to baseline due to requirements Develop set of requirements that permits
changes development at acceptable risks, sign off
and identify decision makers for this set.
Scope Creep Changes requested in the current plan and Document and agree on scope, establish
staffing, or through informal process and follow change control process.
GROUP ACTIVITY
Your team has been tasked with the planning, design, implementation and rollout of a software platform to manage Welingkar’s
recruitment process. Using the framework discussed, document 10 requirements for this system.

Group activity -
Requirements
DEFINE SCOPE
DEFINE SCOPE

…is the process of developing a detailed description of the project and

product (PMBOK)

Inputs Tools & Outputs

Techniques

• Project charter • Expert • Project scope

• Requirements judgment document
documentation • Product • Project
• Organizational analysis document
process assets • Alternatives updates
identification
• Facilitated
workshops
TOOLS AND TECHNIQUES: DEFINE SCOPE

Expert Product Alternatives Facilitated

judgment analysis identification workshops
• Groups or • High level • Different • Joint
individuals product approaches to Application
with descriptions project Development
specialized into execution • Quality
training deliverables Function
• Expertise • Methodology Deployment
within and specific by • Voice of the
outside the application Customer
client area
organization
OUTPUTS: DEFINE SCOPE

Project scope statement Project document updates

• Progressive elaboration • Requirements

of product, service or documentation
result (as defined in • Requirements
project charter and traceability matrix
requirements documents • Stakeholder register
• Acceptance criteria
• Deliverables
• Exclusions
• Constraints
• Assumptions
WORK BREAKDOWN
STRUCTURE
WHAT IS A WBS?

Structure to identify all deliverables required to

complete the project
Organizes the deliverables to facilitate schedule
development, planning and control
Considered complete when each work package can
be identified in terms of nature, quality and quantity

Clarifies project scope PMBOK definition: …is a deliverable-oriented

hierarchical decomposition of the work to be
Ensures buy-in; reflects inputs of all team members
executed by the project team to accomplish the
Baseline for subsequent change control project objectives and create the required
deliverables, with each descending level of the
Primary input to project management processes
WBS representing an increasingly detailed
Ensures correlation with RACI and Organization Breakdown Structures definition of the project work.
WBS CONCEPTS
Levels: From the highest level (Level 0) of project or program to the lowest level
(with greater detail)
WBS elements: Deliverables that are broken down into more WBS elements or
into work packages
Work package: Deliverable at the lowest level of WBS

Code of accounts: Numbering system to define each WBS element and work
package
WBS dictionary: Location where all details for each work package is maintained
WBS QUALITY
• Quality principle 1: A quality WBS is a WBS created in such a way that it satisfies all the
requirements for its use in a project.

• •

characteristics
Core characteristics

Use related
Deliverable oriented and hierarchical Sufficient level of decomposition
• Defines scope • Sufficient detail for communication of work
• Clarifies and communicates scope • Appropriate for tracking and control
• Contains 100% of work defined by scope • Contains specific WBS elements as needed for
• Captures internal, external and interim project
deliverables • Enables assignment of accountability
• Each level of decomposition contains 100% of • Succinct, clear and logically organized
work at parent level structure to meet project management
Contains work packages that help identify tasks requirements
to deliver work package
• Coding scheme
• Constructed from technical input; and created
by those who perform the work
• Progressive elaboration of scope; and baselined

Quality principle 2: WBS quality characteristics apply at all levels of scope definition
CREATE WBS

Tools &
Inputs Outputs
Techniques
• Project scope • Decomposition • WBS
statement • WBS
• Requirements dictionary
documentation • Scope baseline
• Organizational • Project
process assets document
updates
TOOLS & TECHNIQUES: CREATE WBS

Decompose upper level

Identify and analyze Develop and assign Verify degree of
Structuring and organizing elements to lower level
deliverables and related identification codes to decomposition is necessary
the WBS elements and work
work WBS components and sufficient
packages
WBS DEVELOPMENT TOOLS

Bottom-up
Org standards
and top-down
for WBS
strategies

Fishbone &
WBS
brainstorming
templates
techniques
WBS CREATION METHODS
WBS – ESSENTIAL JUDGMENTS

Logic of
Type of WBS
Level of detail decomposition
elements
(organization driven)
Necessity of WBS Organization structure
Scope and work package
detail
elements types by projects along functional lines –
– not all are required WBS decomposition by
deliverables that each
organization contributes
“Project management” as
Resources and risks a level 2 WBS element –
all projects need this
Sequential process steps –
WBS decomposition by
“Quality assurance” product lifecycle phases
Costs and timing
applicable to all projects
GROUP ACTIVITY
Your team has been tasked with the planning, design, implementation and rollout of a software platform to manage Welingkar’s
recruitment process. Build a WBS structure for this project up to 3 levels.

Group activity
template
SCOPE VERIFICATION
AND CONTROL
VERIFY SCOPE

…is the process of formalizing acceptance of completed project

deliverables (PMBOK)

Inputs Tools & Outputs

Techniques

• Project • Inspection • Accepted

management deliverables
plan • Change
• Requirements requests
documentation • Project
• Requirements document
traceability updates
matrix
• Validated
deliverables
CONTROL SCOPE

… is the process of monitoring the status of the project and product scope and managing
changes to the scope baseline
(PMBOK)

Inputs Tools & Techniques Outputs

• Project • Inspection • Work

management performance
plan measurements
• Requirements • Organizational
documentation process assets
• Work updates
performance • Change requests
information • Project
• Requirements management
traceability plan updates
matrix • Project
• Organizational document
process assets updates
CHANGE MANAGEMENT

Customers

Funding
Project team
changes

Where does
change
come from?

Product
Government
obsolescence

Environment
ASSESS CHANGE

Evaluate effect on
▪ Triple constraint
▪ Functional areas
▪ Team
▪ Project
▪ Politics
▪ Organization
CHANGE MANAGEMENT – KEY MESSAGES
❑ Sources of change can be
▪ verbal/written,
▪ direct/indirect,
▪ external/internal,
▪ legally mandated/optional
❑ Change control is the responsibility of the project manager
❑ Project manager should assess impact
❑ PM uses requirements baselines, WBS, schedule, budgets to control change
❑ All change requests must be documented
THANK YOU
BACKUP
REQUIREMENT SPECIFICATION - CHARACTERISTICS

Complete - nothing Consistent - does not Feasible - can be

Correct - accurately
is missing (no ‘To Be conflict with other implemented within
states a customer need
Determined’) requirements known constraints

Modifiable - can be
Necessary - Prioritized - ranked
easily changed, with Singular - contains
documents something as to importance of
history, when only one point
customers really need inclusion in product
necessary

Testable - tests can Traceable - linked to Understandable -

Unambiguous - has
be devised to system requirements, should be easy to
only one possible
demonstrate correct designs, code and understand by all
meaning
implementation tests stakeholders

Usable - can be used

Identifiable - should in later phases;
be unique describes what and
not how
USING ELICITATION TECHNIQUES

Characteristics

Electronic Modeling
Role Data (Use
Interviews Workshop Playing Prototyping Collection Cases)
All Stakeholders physical availability
for meeting
Availability of Requirements
facilitator
Less Time available
Requirements available from
multiple stakeholders
Clarity of requirements
Version of system exists
Suitable
No dependency
Not Suitable / unnecessary
REQUIREMENTS ANALYSIS
❑To ensure that you have well formed and agreed requirements.
❑Uses User Requirements or current baseline for deeper analysis
of established need.
❑Business or User Requirements does not consider the systems
perspective.
❑Covers the proposed project's scope, objectives, proposal and
schedule, and review the current system (if one exists) to
determine the level of effort required.
❑Results in:
• User documentation & training requirements
• Reveals weaknesses in the concepts & provides solutions to these
deficiencies.
• Check feasibility of the project.
• PM accountable for completing this phase
• Systems and Software Requirement Specifications
CHALLENGES OF REQUIREMENTS ELICITATION
• The “Yes, But” syndrome stems from human nature and the users
inability to experience the software as they might a physical
device.

• The Undiscovered Ruins, the more you find, the more you
realize still remain.

• “User and Developer” syndrome reflects the profound

differences between the two, making communication difficult.

• “The sins of your predecessors” syndrome where marketing

(user) and developers do not trust each other based on previous
interactions, so marketing wants everything and developers
commit to nothing.
EXPECTATION MANAGEMENT
❑Sales Pitch: Under Promise and Over deliver for high customer satisfaction

❑Practice: Set fair expectations with customers and exceed them

❑Corollary: Provide continuous feedback on progress made and provide early

alerts in case of missing expectation
REQUIREMENTS CHANGE MANAGEMENT
❑Definition - Effectively manage changes to baselined configurable Items
❑Changes are inevitable; permit changes in manageable increments at predictable
cost.
❑Triggered by changes to scope, baseline or plans, priorities
❑Change Request are basis for the process
❑Key drivers to success are - proper impact analysis and change tracking
❑Key Steps
• Problem analysis
• Change analysis and costing
• Change implementation
❑Benefits
• Provide mechanism for accepting changes
• Facilitate changes through formal process
LIFE CYCLE AND PROCESS CHANGES
❑Requirements engineering tasks can be scattered around the development
process depending on its model.

❑It is the inter-relationship of these tasks which is important to the overall process
- not its exact location in the software development life-cycle.

❑Waterfall – First phase, followed by Design

❑Iterative – First phase of each cycle, followed by Design

❑Incremental – First phase for all modules, followed by detailed execution of

each modules in sequence
CHOOSING A WBS CREATION METHOD

WBS standards and

Top down Bottom up
templates
• PM / PM team has • Project’s products • Availability of
little experience in and services well templates for project
developing WBS understood type under
• Nature of project’s • Nature of lifecycle is consideration
products and clear and familiar • Similar projects
services not well • WBS templates are being executed
understood available
• Nature of project’s
lifecycle is not
familiar
• No templates are
available
REQUIREMENTS ELICITATION TECHNIQUES
Technique Benefits Suitability
Interviewing and questionnaires Gets factual (not actual) data from Very large user group. Basic set of
a number of people specifications is available for
users to review and criticize.
Requirements workshops (JAD / Facilitate idea generation, Good facilitator available and less
brainstorming) clarifying and deciding. time available
Models (Use Cases, DFD,..) Focus on scenarios and simple Ability to specify detailed
functional requirements
Role Playing Gets the feeling of the customer. Earlier version of system exists
and users available
Prototyping Tests new ideas, feedback loop, To check feasibility and drive
- Storyboards early working system available requirements

Electronic Data Collection (e- Easy to collect and document Geographically separated user
mail, www, SPP based surveys) base
CHANGE MANAGEMENT PROCESS

Identify and
submit change Screen request Assess impact
request

Implement Inform Get customer

and document stakeholders approval

Distribute