2144 Manage Change Or IT Will Manage You Betty Luedke Principal Consultant Borland Software Corporation

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



– Request For Change =/= Requirement






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


– 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


– 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’




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


Notify requestor of decision

Adjust schedule/ resources/budget

Assess value/ impact/feasibility of

request

Place request ‘on hold’

Verify implementation of

request


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

http://www.processimpact.com/


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



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%


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



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%



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%



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


– 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


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...‘Triage’ Officer


– ‘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


– 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




Moving To An Improved Process

– Understanding...

– Determining...

– Implementing...

– Monitoring...

– Improving...


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,...)


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


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


• 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:



– Request =/= Requirement



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


Questions?

Thank You

2144


Please fill out the speaker evaluation

You can contact me further at …[email protected]

Documents

2144 Manage Change Or IT Will Manage You Betty Luedke Principal Consultant Borland Software Corporation