2144 Manage Change Or IT Will Manage You

1
2144Manage Change Or IT Will Manage You

• Betty Luedke
• Principal Consultant
• Borland Software Corporation

2
Managing Change Or...

• Basic Truths
• Getting A Grip
• Exploring Proven Practices
• Moving To An Improved Change Control Process

3
Basic Truths

• Change happens...
• Change has an anatomy
• Request For Change / Requirement
• A tool is not a process
• Undisciplined change causes
• inadequate requirement/design
• artifacts

4
Change Happens...

• IGNORE IT
• Ad hoc
• Uncontrolled
• You are lucky if things work out
• REACT to IT
• Valiant effort
• Requests are looked at individually
• Every request is a requirement

• MANAGE IT
• Review request
• Assess request
• Decide whether to honor request
• If approved,
• Adjust schedules, funding, resources
• Add/modify/delete system artifacts
• Test modified system
• Deploy modified system

Acceptable Risk
5
Acceptable Risk...
6
Acceptable Risk...
7
Acceptable Risk...
8
Change Has An Anatomy
Demand
or
9
Request For Change Information
10
Request For Change Information
11
Bad News...Good News
?

• Bad News
• Lots of requests for change
• Good News
• Enhancements and defects follow the same basic
  change process ...
• propose gt review for understanding gt assess gt
  decide

?
12
Same Process...Differences

• Differences in...
• The assessors/decision makers
• What information is needed to be able to assess
• The tool(s) used to capture the information about
  a particular type of request for change
• The amount of time it takes to
• propose gt review for understanding gt assess gt
  decide
• (15 minutes....3 weeks!!)

13
Minimize Differences

• By having...
• An established change control process
• Change management tool (StarTeam with workflows )
  
• Agreed on decision criteria
• Standard information that is kept about a request
  
• Guidance on which decision makers need to be
  involved under what circumstances

14
Fatal Mistakes
Request For Change Requirement
PREFERENCE vs need
15
Avoiding Fatal Mistakes

• Use request for change instead of change
  request
• A request must be stated as a NEED
• One request may add/modify/delete one or more
  requirements or other system development
  artifacts
• Customers (internal or external) are free to make
  requests, but decisions will be made according to
  established criteria

NEED vs preference
16
Vendor Selling A Product

• If your company wants to be the industry leader,
  following a customer who is mired in an old set
  of 'possibilities' will lead you to a new 'old'
  approach.
• Your company must be satisfying part of your
  client base or you would not be in business. 
  Leverage your more global understanding  to
  position your company as a forward-thinking
  industry leader.
• Establish customer expectations that, even though
  they are free to request anything, your company
  reserves the right to decide the requirements for
  your product.
• Establish an exploratory relationship with your
  customer that will provide usage guidance and
  insights on new regulations, trends and returns
  on investment.

17
Organization With Multiple Divisions

• If all the divisions get some piece of the system
  to work the way they prefer, then you will mostly
  likely have a system 'put together by a
  committee'.  To avoid this inappropriate collage
• Focus on the business NEED NEED
• Encourage (and reward somehow) a global mindset
• Recognize/respect/accommodate the true
  differences in business NEED
• Determine decision criteria that will be used to
  determine the fate of a request no matter which
  division was its source.
• Choose another term (an agreed upon, well-chosen
  term) when a particular term, for whatever
  reason, is associated with a particular division.

18
A Tool Is Not A Process!
PROCESS/PEOPLE Effective TECHNOLOGY
Efficient
19
Undisciplined Change ... Inadequate System
Development Artifacts

• Is it an acceptable risk to ...
• Say yes to a request without knowing the
  ramifications?
• Have to go to code to determine what the system
  does?
• Establish...
• Requirements strategies
• Process for developing/managing requirements
• Process for managing change
• Tool support

20
Basic Truths

• Change happens...
• Change has an anatomy
• Request For Change / Requirement
• A tool is not a process
• Undisciplined change causes
• inadequate requirement/design
• artifacts

21
Managing Change Or...

• Basic Truths
• Getting A Grip
• Exploring Proven Practices
• Moving To An Improved Change Control Process

22
Getting A Grip

• The PAIN
• System development participants
• Attitudes and biases
• Organizational readiness/maturity

23
The PAIN

• Rework...rework...rework
• Missed schedules
• Over-budget costs
• Specificity needed for outsourcing

Motivates improvement
Gets attention
Causes a problem
24
System Development Participants

• Who can help us make a smart decision?
• Do we need a Change Control Board (CCB)?
• A vendor with multiple customers to satisfy
• A company with multiple divisions
• Outsourcing your development
• Working on a large project
• Is triage necessary?

25
Attitudes and Biases

• Things that can stand in the way...
• Existing procedures
• Decisions
• Priorities
• Accountability

Robust/inadequate? Followed/ignored?
Is it always Sure we can!? WHO is the decision
maker?
Does the loudest voice win? Does preference win
over NEED?
WHO is responsible? (not me) How can we make
things better?
26
Organizational Readiness/Maturity

• Using the Capability Maturity Model (CMM)s
  perspective on managing change as a measuring
  stick for determining
• Organizational Readiness
• Organizational Maturity

27
Capability Maturity Model (CMM)

• Level 2 REPEATABLE
• Key Practice Areas
• Requirements Management
• The software engineering group reviews the
  allocated requirements before they are
  incorporated into the software project
• Changes to the allocated requirements are
  reviewed and incorporated into the software
  project
• Software Project Planning
• The project's software development plan is
  developed accordingly
• Software Project Tracking and Oversight
• Software project commitments and changes to
  commitments made to individuals and groups
  external to the organization are reviewed with
  senior management according to a documented
  procedure

28
Capability Maturity Model (CMM)

• Level 2 REPEATABLE
• Key Practice Areas
• Software Subcontractor Management
• The contractual agreement between the prime
  contractor and the software subcontractor is used
  as the basis for managing the subcontract
• Changes to the software subcontractor's statement
  of work, subcontract terms and conditions and
  other commitments are resolved according to a
  documented procedure
• Software Configuration Management
• Change requests and problem reports for all
  configuration items/units are initiated,
  recorded, reviewed, approved and tracked
  according to a documented procedure
• Changes to baselines are controlled according to
  a documented procedure

29
Capability Maturity Model (CMM)

• Level 2 REPEATABLE
• Key Practice Areas
• Requirements Management
• Software Project Planning
• Software Project Tracking and Oversight
• Software Subcontractor Management
• Software Configuration Management

Commitments
Change to commitments
Change to commitments Negotiation
Related groups Renegotiation
Conditions for revisions All affected involved
Configuration item change requests Changes to
baselines
30
Capability Maturity Model (CMM)

• Level 5 OPTIMIZING
• Key Practice Areas
• Technology Change Management
• Develops/maintains a plan for technology change
  management.
• Works with software projects identifying areas of
  technology change.
• Informs software staff of new technologies.
• Systematically analyzes the organization's
  standard software process to identify areas for
  new technology.
• Technologies are selected and acquired.
• Conduct pilot efforts for improving technology.
• Incorporate appropriate new technologies into the
  organization's/projects standard software
  processes.

Change to technology
31
Capability Maturity Model (CMM)

• Level 5 OPTIMIZING
• Key Practice Areas
• Process Change Management
• Empower organization to improve the processes. 
• Coordinate the software process improvement
  activities.
• Develop/maintain a plan for software process
  improvement by a procedure.
• Perform software process improvement activities
  in accordance with software process improvement
  plan. 
• Improvement proposals are handled by a procedure.
• Organization actively participates developing
  process improvements.
• Pilot process improvements to determine benefits/
  effectiveness before introducing into normal
  practice.
• Implement an improvement by a procedure.
• Records of improvement activities are maintained.
• Staff receives feedback on improvement activities.

Change to process
32
Commitment...Ability To Perform

• Setting the stage...
• Provide an environment conducive to controlling
  change by providing
• Trained resources
• Requirements management process
• Change control process
• Follow the change control process
• Providing needed request for change information
• Reviewing a request for change  for understanding
  
• Assessing the impact of honoring a request for
  change and making a recommendation
• Agreeing to WHAT is to be changed
• Adjusting schedule/budget/resources for a request
  for change that is to be honored

33
For The Organization...
34
For The Individual...
35
Managing Change Or...

• Basic Truths
• Getting A Grip
• Exploring Proven Practices
• Moving To An Improved Change Control Process

36
Exploring Proven Practices

• Requirements Management
• Requirement Strategies
• Project Management
• Project Dimensions

• Change Management
• Change Control Process
• Impact Analysis
• Prioritization
• Decision Matrices
• Customer Input Filters
• Change Control Board
• Triage Officer
• Tool Support

37
Requirements Management...Requirements Strategies

• Requirement Type Strategy
• Requirement Trace Strategy
• Requirement Baseline Strategy

38
Project Management...Project Dimensions
Trade-offs
39
Change Management...Change Control Process
Receive request for change
Review request for understanding
Notify requestor of decision
Elicit/analyze/ specify/validate requirements
Determine disposition of the request
Adjust schedule/ resources/budget
Assess value/ impact/feasibility of request
Review request for understanding

Create/modify/ validate design
Place request on hold
Develop/modify system
Verify implementation of request
40
Change Management...Change Control Process
41
Change Management...Impact Analysis
BUSINESS
TESTS
USER
REQUIREMENTS
FUNCTIONAL
CODE
42
Change Management...Prioritization
X

• Prioritization Scales
• High
• Medium
• Low
• Must have
• Should have
• Nice to have

• Prioritization based on...
• Benefit
• Penalty
• Cost
• Risk
• Karl Wiegers website...
• www.processimpact.com

43
Change Management...Prioritization
44
Change Management...Prioritization
45
Change Management...Prioritization

• Estimate the total effort to implement each
  feature
• Fully refine requirements and review them
• Design and review user interface, architecture,
  algorithms
• Build and evaluate a prototype
• Code, review code, rework, unit test, rework,
  document
• Integrate with rest of product, test, rework
• Develop and execute system tests, rework
• Program documentation
• Support activities (configuration management, QA,
  pubs)

Adapted from Karl Wiegers In Search Of Excellent
Requirements
46
Change Management...Prioritization
47
Change Management...Prioritization
48
Change Management...Prioritization
VALUE . (COST RISK )
49
Change Management...Decision Matrices
50
Change Management...Decision Matrices
51
Change Management...Customer Input Filters

• To facilitate effective change decisions...
• Start with the end in mind (Stephen Covey)
• Come to a global mindset focused on the business
  NEED
• State that input does not constitute a
  requirement
• Talk about trade-offs and making important
  decisions
• Be recognized as a forward-thinking company
• Stay in control of your products destiny
• Understand the companys bottom-line (even if you
  are not very close to it)
• Strive for an our environment

Vendor Company
Multiple Divisions
52
Change Management...Change Control Board

• To facilitate effective change decisions...
• Get the right people involved in the right
  way at the right time
• (one person...group representing multiple
  perspectives)
• Have the authority to make binding decisions
• Know what you are charged to do

53
Change Management...Change Control Board

• A Change Control Board is charged to...
• Determine the system artifacts that could be
  affected
• Understand the implications of making the
  requested change

Adapted from Karl Wiegers In Search Of Excellent
Requirements
54
Change Management...Change Control Board

• A Change Control Board is charged to...
• Determine the system artifacts that could be
  affected
• Understand the implications of making the
  requested change
• Identify the tasks needed to accomplish the
  requested change

55
Change Management...Triage Officer

• To facilitate effective change decisions...
• Triage the steady stream of request for change
  by doing
• Minimal research
• Facilitating routing
• Speed up the change control process at an
  acceptable risk

56
Change Management...Tool Support

• To facilitate effective change decisions...
• Remember a tool is not a process!
• Capture each request for change discretely
• Keep pertinent information about each request
• Relate each request for change to affected system
  development artifacts
• Capture discussions related to each request for
  change

57
Managing Change Or...

• Basic Truths
• Getting A Grip
• Exploring Proven Practices
• Moving To An Improved Change Control Process

58
Moving To An Improved Process

• Understanding...
• Determining...
• Implementing...
• Monitoring...
• Improving...

59
Moving To An Improved Process

• Understanding...
• The nature of change
• Possible approaches to managing change
• Your environment
• (its people, its practices, its biases, its
  PAIN,  its technology, its current metrics,...)
• Possible tool options and how well they fit the
  requirements for your change control process

60
Moving To An Improved Process

• Determining...
• A change process appropriate in your environment
• Participants in the change control process
• Criteria by which decisions will be made
• Accountability for successful management of
  change
• How the change control process will be introduced
  
• What tool support will be provided
• (StarTeam, CaliberRM,...)

61
Moving To An Improved Process

• Implementing...
• The agreed to change control process with
  adequate training and tool support
• Information capture that will provide insight
  into productivity, quality,...

62
Moving To An Improved Process

• Monitoring...
• Gains in productivity/quality/...
• The change control process/tool support for
  needed improvements

63
Moving To An Improved Process

• Improving...
• The change control process/tool support as needed

W.E.Demings quality circle adapted from W.E.
Lewis, 2000, Software Testing and Continuous
Improvement
64
Moving To An Improved Process
65
YOU Can Manage Change By...

• Getting a grip on
• The PAIN
• System development participants
• Attitudes and biases
• Organizational readiness/ maturity

• Learning the basics
• Change happens...
• Change has an anatomy
• Request / Requirement
• A tool is not a process
• Undisciplined change causes inadequate
  requirement/design artifacts

66
YOU Can Manage Change By...

• Putting proven practices in motion
• Requirements strategies
• Project dimensions
• Change control process
• Impact analysis
• Prioritization
• Decision Matrices

Requirements Management
Project Management
Change Management

• Customer input filters
• Change control board
• Triage officer
• Tool support

67
Questions?

• Manage Change Or IT Will Manage You

68
Thank You

• 2144
• Manage Change Or IT Will Manage You
• Please fill out the speaker evaluation
• You can contact me further at betty.luedke_at_borla
  nd.com