2144
Manage Change Or IT Will Manage You
Betty LuedkePrincipal Consultant
Borland Software Corporation
– Basic Truths– Getting A Grip– Exploring Proven Practices– Moving To An Improved
Change Control Process
Managing Change Or...
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
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 requestIf approved,• Adjust schedules, funding,
resources• Add/modify/delete system
artifacts• Test modified system• Deploy modified systemAcceptable Risk
Acceptable Risk...
GOOD PRACTICES
APPROACH
Ignore React Manageoblivious>>>>>>>>>>reactive>>>>>>>>>>>managing
There is an established process for controlling change
No Probably informal
Yes
Review request for understanding
Not completely
Partially Yes
The request is appropriately assessed
No Partially Yes
Acceptable Risk...
GOOD PRACTICES
APPROACH
Ignore React Manageoblivious>>>>>>>>>>reactive>>>>>>>>>>managing
Decisions are based on pre-established criteria
No Probably not
Yes
If request is honored...
Adjust schedule, funding, resources
No Probably not
Yes
Modify requirement/ design/ test artifacts
No Probably not
Yes
Acceptable Risk...
GOOD PRACTICES
APPROACH
Ignore React Manageoblivious>>>>>>>>>>>>>>>>reactive>>>>>>>>>>>>>>>>managing
RESULTS • Dissatisfied customer
• Chaotic...unplanned
• Disorganized system
• Sometimes satisfied customer
• Probably focused on 'wants' not 'NEEDs'
• Band-aided system
• Satisfied customer
• Focused on 'NEEDs' not 'wants
• Evolved system
Change Has An Anatomy
Requirement
Design TestCode
Request For Change
Enhancement
Defect
Demand
or
Request For Change Information
Attribute Definition
Identifier This number uniquely identifies the request.Name This name briefly describes the request .Description This name fully describes the request .Status This code identifies the current state of request.Priority This code identifies the importance of the request.Source This name identifies the person or organization
from which the request came.Request Date This date is when the request was made.
Request For Change Information
Attribute Definition
Planned Release
This identifier indicates for which release this request for change is planned.
Actual Implementation Date
This date is when the request for change was implemented (coded).
Actual Verification Date
This date is when the request for change was verified (code was tested).
Actual Deployment Date
This date is when the request for change was deployed.
Bad News
– Lots of requests for change
Good News
– Enhancements and defects follow the same basic change process ...
propose > review for understanding > assess > decide
Bad News...Good News
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 > review for understanding > assess > decide (15 minutes....3 weeks!!)
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
Minimize Differences
Fatal Mistakes
Request For Change = Requirement
PREFERENCE vs need
– 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
Avoiding Fatal Mistakes
NEED vs preference
Request For Change == Requirement
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.
• 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.
Organization With Multiple Divisions
A Tool Is Not A Process!
PROCESS/PEOPLE … Effective
TECHNOLOGY … Efficient
PROCESS
TECHNOLOGYPEOPLE
Effective Efficient
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
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
– Basic Truths– Getting A Grip– Exploring Proven Practices– Moving To An Improved
Change Control Process
Managing Change Or...
Getting A Grip
– The PAIN
– System development participants
– Attitudes and biases
– Organizational readiness/maturity
Motivates improvement
Gets attention
The PAIN– Rework...rework...rework
– Missed schedules
– Over-budget costs
– Specificity needed for outsourcing
Causes a problem
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?
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?
Using the Capability Maturity Model (CMM)’s perspective on managing change as a ‘measuring stick’ for determining:
– Organizational Readiness– Organizational Maturity
Organizational Readiness/Maturity
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
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
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 commitmentsNegotiation
Related groupsRenegotiation
Conditions for revisionsAll affected involved
Configuration item change requests Changes to baselines
Change to commitments
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/project’s standard software processes.
Change to technology
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
Commitment...Ability To PerformSetting 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
For The Organization...
COMMITMENT is exemplified by... ABILITY is exemplified by...
• Establishing change control policy with :
• Tasks • Responsibilities
• Assessing what is needed (training, mentoring, tool,...)
• Assigning responsibilities • Providing training/mentoring and
tools • Focusing on positive accountability • Providing support/guidance in:
• Change control process improvement
• Tool support of established change control process
For The Individual...
COMMITMENT is exemplified by... ABILITY is exemplified by...
• Recognizing/insisting on a change control process
• Knowing responsibilities • Being prepared with appropriate
techniques ( prioritization model, decision criteria,...
• Documenting quality requests for change, decisions,...
• Making timely, informed decisions • Searching for a ‘more
effective/efficient way’
– Basic Truths– Getting A Grip– Exploring Proven Practices– Moving To An Improved
Change Control Process
Managing Change Or...
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
Requirements Management...Requirements Strategies
• Requirement Type Strategy• Requirement Trace Strategy• Requirement Baseline Strategy
Project Management...Project Dimensions
Project Dimensio
nDriver
(State Objective)Constraint(State Limit)
Degree Of Freedom
(State Range)
Cost Up to 20% overrun OK without review
Features All Release 1.0 features operational
Quality User acceptance test must pass (95%)
Schedule Release 1.0 delivered in 4 months
Staff 4.5 full-time staff available for duration
Trade-offs
Change Management...Change Control Process
Determine disposition of the
request
Receive request for change
Review request for understanding
Notify requestor of decision
Adjust schedule/ resources/budget
Assess value/ impact/feasibility of
request
Place request ‘on hold’
Verify implementation of
request
Review request for understanding
Elicit/analyze/ specify/validate
requirements
Create/modify/ validate design
Develop/modify system
CaliberRM
StarTeam
Change Management...Change Control Process
Received
Reviewed
Assessed
Approved
Rejected Cancelled
Implemented
Verified
Deferred
StarTeam Workflows
Change Management...Impact Analysis
BU
SIN
ESS
USE R
FUN
CTI
ON
AL
REQ
UIR
EMEN
TSTESTS
CO
DE
Change Management...Prioritization
Prioritization Scales
– HighMediumLow
– Must haveShould haveNice to have
XPrioritization based on...
– Benefit– Penalty– Cost– Risk
Karl Wiegers’ website... www.processimpact.com
Change Management...Prioritization
Feature Benefit PenaltyRelative
ValueVALUE
%Relative Cost
COST %
Relative Risk
RISK % PRIORITY
1 6 8 14
2 4 2 6
3 4 3 7
4 5 4 9
5 3 1 4
TOTAL 22 18 40
Change Management...Prioritization
Feature Benefit PenaltyRelative
ValueVALUE
%Relative Cost
COST %
Relative Risk
RISK % PRIORITY
1 6 8 14 35%
2 4 2 6 15%
3 4 3 7 18%
4 5 4 9 22%
5 3 1 4 10%
TOTAL 22 18 40 100%
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
Change Management...Prioritization
Feature Benefit PenaltyRelative
ValueVALUE
%Relative Cost
COST %
Relative Risk
RISK % PRIORITY
1 6 8 14 35% 3 15%
2 4 2 6 15% 7 35%
3 4 3 7 18% 5 25%
4 5 4 9 22% 1 5%
5 3 1 4 10% 4 20%
TOTAL 22 18 40 100% 20 100%
Change Management...Prioritization
Feature Benefit PenaltyRelative
ValueVALUE
%Relative Cost
COST %
Relative Risk
RISK % PRIORITY
1 6 8 14 35% 3 15% 2 12.5%
2 4 2 6 15% 7 35% 3 19%
3 4 3 7 18% 5 25% 3 19%
4 5 4 9 22% 1 5% 1 6%
5 3 1 4 10% 4 20% 7 43.5%
TOTAL 22 18 40 100% 20 100% 16 100%
Change Management...Prioritization
Feature Benefit PenaltyRelative
ValueVALUE
%Relative Cost
COST %
Relative Risk
RISK % PRIORITY
1 6 8 14 35% 3 15% 2 12.5% 1.27
2 4 2 6 15% 7 35% 3 19% 0.28
3 4 3 7 18% 5 25% 3 19% 0.41
4 5 4 9 22% 1 5% 1 6% 2.00
5 3 1 4 10% 4 20% 7 43.5% 0.16
TOTAL 22 18 40 100% 20 100% 18 100% -- VALUE % .(COST % + RISK %)
Change Management...Decision Matrices
Decision Criteria DecisionCan one do business without this change?
Does this functionality exist in XYZ System?
What is the effort required?
Action Description
N ProductionConstruction
HighMedium
Low
GO • Implement in current release.
N Planned HighMedium
Low
Investigate before
deciding
• We are not searching for these ‘opportunities’.• After brief investigation, the decision may be GO and
implement in current release (doubtful) or the decision may be WAIT and implement in a later release. The decision of which release may have to be decided later.
Y Production High WAIT • This may be a missed requirement or an unnecessary requirement.
• WAIT to decide whether or not to implement. Y Production Medium WAIT • This may be a missed or an unnecessary requirement.
• WAIT to decide whether or not to implement.
Y Production Low Investigate before
deciding
• This may be a missed requirement or an unnecessary requirement.
• We are not searching for these ‘opportunities’.• After brief investigation, the decision may be to GO forward
with implementation in current release (possible) or the decision may be to WAIT and implement in a later release.
Change Management...Decision Matrices
Decision Criteria DecisionCan one do business without this change?
Does this functionality exist in XYZ System?
What is the effort required?
Action Description
Y Construction High WAIT• We are not searching for these ‘opportunities’.• WAIT to decide whether or not to implement. If decision is to
implement, then decide which release.Y Construction Medium WAIT
• We are not searching for these ‘opportunities’.• WAIT to decide whether or not to implement at all. If decision
is to implement, then decide which release.Y Construction Low WAIT
• We are not searching for these ‘opportunities’.• WAIT to decide whether or not to implement. If decision is to
implement, then decide which release.Y Planned High
MediumLow
WAIT• We are not searching for these ‘opportunities’.• WAIT to decide whether or not to implement. If decision is to
implement, then decide which release.
Implement in current release. Investigate before deciding. Wait to decide.
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 product’s destiny
– Understand the company’s bottom-line (even if you are not very close to it)
– Strive for an ‘our’ environment
Vend
orC
ompa
ny
Mul
tiple
D
ivis
ions
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
– Will the change affect quality?– Is the change technically
feasible?– Will completed work be
discarded?– Does the change violate any
business rules?– Does the change affect any other
tasks or requests for change?
– Will the change affect quality?– Is the change technically
feasible?– Will completed work be
discarded?– Does the change violate any
business rules?– Does the change affect any other
tasks or requests for change?
A Change Control Board is charged to...
– Determine the system artifacts that could be affected
– Understand the implications of making the requested change
Change Management...Change Control Board
Adapted from Karl Wiegers’ In Search Of Excellent Requirements
– Estimate total labor hours (create/modify code, test, requirements; develop/evaluate prototype; review...rework...retest)
– Allocate resources– Sequence tasks– Determine if change is on
project’s critical path– Estimate schedule and cost
impact if change is implemented
– Estimate total labor hours (create/modify code, test, requirements; develop/evaluate prototype; review...rework...retest)
– Allocate resources– Sequence tasks– Determine if change is on
project’s critical path– Estimate schedule and cost
impact if change is implemented
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
Change Management...Change Control Board
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
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
– Basic Truths– Getting A Grip– Exploring Proven Practices– Moving To An Improved
Change Control Process
Managing Change Or...
Moving To An Improved Process
– Understanding...
– Determining...
– Implementing...
– Monitoring...
– Improving...
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
Moving To An Improved ProcessDetermining...
– 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,...)
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,...
Moving To An Improved Process
Monitoring...
– Gains in productivity/quality/... – The change control process/tool support for
needed improvements
Moving To An Improved Process
Improving...
– The change control process/tool support as needed
Quadrant Description
Plan • Define objectives and determine conditions and methods required to achieve these objectives
Do • Create conditions providing necessary training with a thorough understanding of the objectives and the plan
Check • Determine whether work is progressing according to plan
• Compare results to objectives and where different search for root cause
Act • If the 'check' reveals work is not being performed according to plan or the results are not what was anticipated, determine appropriate action
W.E.Deming’s quality circle adapted from W.E. Lewis, 2000, Software Testing and Continuous Improvement
Moving To An Improved Process
• A change process that is appropriate for 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
Determining...
Improving...• Improving the change control
process/tool support for needed improvements
Understanding...• Nature of change• Possible approaches to managing change• Your environment (its people, its practices, its biases, its
PAIN, its technology, its current metrics,...
Implementing...• The agreed to change control process with adequate
training and tool support• Information capture that will provide insight into
productivity, quality,...
Monitoring...• Gains in productivity/quality/...• The change control process/tool support for
needed improvements
Learning the basics:
– Change happens...
– Change has an anatomy
– Request =/= Requirement
– A tool is not a process
– Undisciplined change causes inadequate requirement/design artifacts
Getting a grip on:
– The PAIN
– System development participants
– Attitudes and biases
– Organizational readiness/ maturity
YOU Can Manage Change By...
YOU Can Manage Change By...Putting proven practices in motion:
– Requirements strategies
– Project dimensions
– Change control process
– Impact analysis
– Prioritization
– Decision Matrices
– Customer input filters
– Change control board
– ‘Triage’ officer
– Tool support
Req
uire
men
ts
Man
agem
ent
Proj
ect
Man
agem
ent
Cha
nge
Man
agem
ent
Manage Change Or IT Will Manage You
Questions?
Thank You
2144
Manage Change Or IT Will Manage You
Please fill out the speaker evaluation
You can contact me further at …[email protected]