Reducing Project Risk through Managing and Measuring Requirements

1
Reducing Project Risk through Managing and
Measuring Requirements

• Jenny Liu
• Borland?????????

2
Borland Process Optimization Background

• Global Leader in process improvement services
• Recognized (Measurement, CMM/CMMI authors,
  Gartner)
• Innovative (AD Improvement Roadmap, Business
  Process Maturity approach)
• Experienced (consultants average 20 years in
  software/systems management)
• Connected (Strong, broad, global alliances)
• Proven (Successful helping clients at all levels
  of maturity, all industries)
• Focused (Process improvement is our primary
  business)
• Open (related modelsPMBOK, ISO 90012000, COBiT,
  ITIL, and others)
• Services
• Appraisals
• Business Process
• Application Development
• HR, PMO
• Advisory Services
• How to get started
• Process improvement/implementation
• Training
• 30 Courses

3
The Triad of Success
Undisciplined
Inefficient
Software Delivery Optimization solutions for
all three components of successful
development ? Technology powerful tools ?
Process coordination and discipline ?
People ability to execute
Amateur
4
IT Project Managers Universe A Complex Risk
Arena
Reducing Project Risk through Managing and
Measuring Requirements
5
Project Results are Poor
Source THE STANDISH GROUP 2003
6
Impact of Requirements on Projects
Reasons Challenged

Reasons Canceled

Lack of User Involvement
13
Incomplete Requirements
13
Incomplete Requirements
12
Lack of User Involvement
12
Changing Requirements
12
Lack of Resources
11
Lack of Executive Support
8
Unrealistic Expectations
10
Technological Incompetence
7
Lack of Executive Support
9
Lack of Resources
6
Changing Requirements
9
Unrealistic Expectations
6
Lack of Planning
8
Unclear Objectives
5
Did not need any Longer
6
Unrealistic Timeframes
4
Lack of IT Management
6
New Technology
4
Technology Illiteracy
4
Other
23
Other
10
Source Standish Group
7
Rework Costs are High Even for Successful
Projects!
Application development organizations typically
spend about 40 of their development effort on
rework
8
Compounding Requirements Costs
Under-scoped requirements and effort
Rushed product platforms
Unsatisfied requirements
rework
Excessive In-service rework
value adding work
rework
value work
9
Defect Repair Costs

• The cost of repairing a defect goes up
  substantially when it crosses a phase boundary
  requirements defects are costly!

Customer XYZ Defect Repair Costs September 2004
10
Requirements Issues Impact Outsourcing
Reasons Why Outsourcing Did Not Meet Expectations
11
Managing Risks
12
Todays IT Risk Environment

• Fundamental shift underway in risk perception and
  management
• Traditional risk management
• Managed in silos
• Disconnected from business goals
• Viewed as a cost of business, a burden to
  overcome
• Focus on controls, limiting growth and innovation
• New risk management
• Approach risk holistically, cross-enterprise
• Balance risk management with risk taking
• Leverage risk for competitive advantage
• Enable risk taking to create new revenue
  opportunities and operational differentiation
• Focus on enabling revenue streams and continuing
  business operations

13
Todays IT Risk Environment

• Competitive demands increase risk exposure
  creates new risk profile
• Cost pressures
• Requirement to perform faster and cheaper on
  fewer resources
• Corporate scandals create unprecedented legal
  risk, control and governance
• Sarbanes-Oxley
• Basel II
• Risk can be a competitive advantage
• Managed risk taking leads to innovation and
  market advantage
• Leverage risk for new products, new services, new
  business models, new forms of competition

14
Three Forms of Risk Management

• Loss and Cost Control
• Traditional aspect of risk management
• Focus on ensuring minimal loss and minimal cost
  of loss
• Innovation and Entrepreneurship
• Focus on balancing innovation and risk
• Increase competitiveness without impacting
  business performance
• Stewardship and Responsibility
• Governance
• Focus on upholding local and international law
• Strong overlap with shareholder issues

15
Risk Management Process
Conduct broad review of potential risk
sources Identify project risks
Assess
Determine potential impact and probability of
occurrence Prioritize risks in order of exposure
Analyze

• Apply proper risk management solutions
• Proactive deterrence ? Manage project at risk
• Prepared resolution

Address
Regularly monitor and update risk scenarios Take
contingency action if identified problems arise
Manage
Learn
Capture ongoing program information Track
historical success to improve future execution
16
Risk Management Process
Conduct broad review of potential risk
sources Identify project risks
Assess
Determine potential impact and probability of
occurrence Prioritize risks in order of exposure
Analyze

• Apply proper risk management solutions
• Proactive deterrence ? Manage project at risk
• Prepared resolution

Address
Regularly monitor and update risk scenarios Take
contingency action if identified problems arise
Manage
Learn
Capture ongoing program information Track
historical success to improve future execution
17
Control in a Risky Environment
18
IT Project Managers Universe Sources of
Requirements Risks
Operations
Business
PM
Application Development
19
Techniques for Identifying Risks

• Brainstorming
• Review possible sources of risk and brainstorm
  specific risks they could create for your project
• Review potential adverse outcomes for your
  project and brainstorm how they might arise

Outcomes
Sources
Risks
Structured approach based on risk knowledge base
20
Another Approach Using Project Risk Factors

• Sources of Project Risk
• Ongoing team activities
• Individual and team
• Risk Factors
• Capture corporate learning
• Use Risk Cues help determine whether risk is
  high/medium/low
• Improve historical team risk management

21
Risk Factor Table Format
Risk Factor
Low Risk Cue
Medium Risk Cue
High Risk Cue
some of project's requirements are documented
(such as the functional requirements), at least
on an informal basis help is available to
project members responsible for managing
requirements when they need it tools are
available for managing important aspects of the
requirements
all of the project's requirements are well
documented and available to support project
planning members of the project development
group and other affected groups are trained to
perform their requirements management
activities appropriate tools are provided for
managing requirements.
Documented Requirements Requirements
Management Training Requirements Management
Tools
requirements are not documented, are out of date,
or are only in the minds of some of the
stakeholders there is little or no support or
training for those responsible for managing a
project's requirements there is little or no
tool support for managing the requirements
22
Reviewing Risk Factors

• Select an appropriate set of factors (e.g.,
  Requirements-related)
• Examine each risk factor and rate its relevance
• High - suggests a potentially high threat risk
• Medium - may suggest a risk to the project
• Low - no apparent risk to project from this
• NA - factor is not applicable to project
• NI - need more information check with experts
• TBD - need to have project proceed further
  revisit later

23
Factors Help You Focus
All risks thousands Risks indicated by
Factor Tables - hundreds Risks rated High -
dozens Risks to be managed - ten or so
24
Requirements Risk Exercise Application
Development Risks

• Focus on risks specifically within IT Application
  Development
• Evaluate each risk factor and mark High, Medium
  or Low in relation to your project or a strategic
  project within your organization.

25
Requirements Risk Exercise Application
Development Risks - 1
26
Requirements Risk Exercise Application
Development Risks - 2
27
Requirements Risk Exercise Application
Development Risks - 3
28
Requirements Risk Exercise Debrief Application
Development Risks

• Additional Comments
• Industry standards provide AD best practices for
  evaluating risks
• CMMI
• COBIT
• PMBOK/PRINCE 2
• Identified risks can be used to adjust projects
  AD approach
• Life Cycle (e.g., Agile vs. non-Agile)
• Technology Support (e.g., Traceability)
• Staffing Mix (e.g., Requirements Analysts)
• Project Plans/Schedules
• Together with measurement history, can help
  predict/adjust projects outcome

29
CMMI Requirements Process Areas

• Requirements Development
• Goals, and Practices
• SG 1 Develop Customer Requirements
• Stakeholder needs, expectations, constraints, and
  interfaces are collected and translated into
  customer requirements.
• SG 2 Develop Product Requirements
• Customer requirements are refined and elaborated
  to develop product and product component
  requirements.
• SG 3 Analyze and Validate Requirements
• The requirements are analyzed and validated, and
  a definition of required functionality is
  developed.

• Requirements Management
• Goals, and Practices
• SG 1 Manage Requirements
• Requirements are managed, and inconsistencies
  with project plans and work products are
  identified
• SP 1.1 Obtain an Understanding of Requirements
• SP 1.2 Obtain Commitment to Requirements
• SP 1.3 Manage Requirements Changes
• SP 1.4 Maintain Bi-directional Traceability of
  Requirements
• SP 1.5 Identify Inconsistencies Between Project
  Work and Requirements

30
Requirements Risk Exercise 2 Business-Related
Project Risks

• Business refers to organization looking to use
  technology to enhance/evolve its process
• Business processes directly impacts the quality
  and reliability of the requirements of the
  business
• March 2005 American Productivity and Quality
  Center (APQC) Study
• Borland partnered to understand Emerging
  Practices in Business Process Management
• Identified critical success factors for success
  transformation of business processes
• Additional goal validate BPMM Concepts

Business
31
APQC Borland Study

• Sponsoring Organizations
• American Express Co.
• Aramco Services Co.
• Caterpillar Inc.
• Cemex, S.A. de C.V.
• ChevronTexaco Corp.
• ConocoPhillips
• ExxonMobil Corp.
• Gartner Inc.
• Halliburton Energy Services Group
• IBM Corp.
• International Truck and Engine Corp.
• Johnson Johnson
• LifeWay Christian Resources
• MetLife Inc.
• Northrop Grumman Integrated Systems
• Petroleo Brasileiro S.A. (Petrobras)
• Ricoh Corp.
• Sears, Roebuck and Co.

• Best Practice Partners
• Air Products and Chemical Inc.
• Coors Brewing Co.
• Deere Co.
• Northrop Grumman Space Technology
• Operations Management International, Inc.

32
Requirements Risk Exercise Business-Related
Project Risks
33
Requirements Risk Exercise Business-Related
Project Risks
34
Requirements Risk Exercise Business-Related
Project Risks
35
Standard-Tailored Process Example New Credit
Card Accounts
36
Business Process Maturity Model
Level
Objectives
Benefits
37
BPMM Level 2 Stabilize Work Units
Work Unit Group or entity that performs part of
a business process
Process
To enable end-to-end business process
improvement, work units must be able to manage
38
BPMM Level 3 Mature End-to-End Process
Define standard end-to-end process and acceptable
tailoring
Process
To support Standard and Tailored Processes, the
organization must proactively manage
39
Requirements Risk Exercise Operations-Related
Project Risks

• Operations refers to organizations providing
  applications deployment and support
• ITIL - Information Technology Infrastructure
  Library is becoming industry best practice
  standard
• Supports risk identification
• Requirements for IT service management
• Vendor independent

40
Requirements Risk Exercise Operations-Related
Project Risks
Reference ITIL Best Practices for Application
Management
41
Requirements Risk Exercise Operations-Related
Project Risks
Reference ITIL Best Practices for Application
Management
42
Requirements Risk Exercise Operations-Related
Project Risks
Reference ITIL Best Practices for Application
Management
43
Risk Assessment De-Brief

• Which area carries the highest risk?
• Application Development
• Business
• Operations
• How many high risks did you identify? Medium?
• Can you envision adding risk factors?
• Address rest of lifecycle
• Lessons learned

44
Risk Management Process
Conduct broad review of potential risk
sources Identify project risks
Assess
Determine potential impact and probability of
occurrence Prioritize risks in order of exposure
Analyze

• Apply proper risk management solutions
• Proactive deterrence ? Manage project at risk
• Prepared resolution

Address
Regularly monitor and update risk scenarios Take
contingency action if identified problems arise
Manage
Learn
Capture ongoing program information Track
historical success to improve future execution
45
Physics of Risk Management

• Trade-offs are a reality
• Fixed budget, fixed schedule, fixed set of
  capabilities
• Proactively manage and communicate trade-offs
• Risk represents a competitive advantage
• Most companies fail to properly manage risk
• Small risk management gains can bring significant
  value
• Risk is your ongoing senior management issue
• Engage senior management about strategic value of
  risk management
• Proactively engage management team on value of
  managing program and project trade-offs

46
Measurement, Requirements and Risk

• How can we use measurement to reduce our project
  risk?

47
Measurement, Requirements and Risk

• Software Engineering Institute studies show that
  even immature organizations can benefit greatly
  by using measurement.
• Capture 4 basic measures
• Size (e.g., requirements)
• Effort
• Schedule
• Quality
• Can derive measures from these, e.g.,
  productivity, defect density
• By capturing basic measures, we can identify and
  monitor requirements related risks throughout the
  life cycle.

48
Measurement Process
49
Requirements-Specific Measures

• Requirements change must be measured and
  monitored. We need to understand if were doing
  what we said we would do.
• Provides insight into growth and stability
• Provide status on progress
• Useful measures
• number of requirements (growth over time)
• number of new requirements, changed or deleted
  requirements (stability/volatility)
• requirements status (approved, tested,
  implemented)
• Counting requirements is often an issue
• how to count a requirement consistently, since
  size and difficulty vary
• traceability/lack of requirements tool use
• change requests

50
Requirements Growth
51
Requirements Change Impact
52
Requirements Status (Test)
53
Integrated Measurement Sources
54
Sample Reports (Caliber and StarTeam)

55
Repository Enables Support for Changing Needs
Example requirements changes under control, may
want to focus more on time to implement change.
56
Measurement and Risk

• Requirements measures help you diagnose issues
  quickly
• Together with repository data and risk analysis,
  we can understand when were getting off-track
  and steer toward acceptable outcomes.

57
Borland and Risk Management

• Borland helps advance successful risk management
  strategies using the best combination of people,
  process and technology
• Ensure your teams skills are best matched to
  their roles and technologies
• Establish a best practice risk management process
  for your organization
• Deliver a software delivery platform that
  increases visibility and control, facilitating
  risk management planning and execution
• Borland Process Optimization Practice
• Comprehensive process engagement from strategic
  planning to full implementation
• Leverages industry leading certified process
  consultants
• Unparalleled process expertise from original CMM
  authors and recognized strategists
• Customized strategy and implementation leveraging
  domain and market expertise

58
Online Assessment
59
Thank You

• Managing Risk Self-Assessment
• www.borland.com/assess-risk