manage change or it will manage you

8/7/2019 Manage Change or It Will Manage You

1/31

Manage Change or It Will Manage You!

By:Betty Luedke

Abstract: Understanding the anatomy of change and the all-too-familiar surroundingcircumstances/dynamics help us use proven approaches effectively to manage requests for change and tofacilitate product evolution.

Betty Luedke is an accomplished project manager, requirements analyst, and facilitator with 22 years

experience in the software development industry. Her broad experience in the analysis, design, anddevelopment of object-oriented, relational, and hierarchical data systems for consumer finance, engineering,and medical functions has enabled her to effectively keep the user foremost when applying requirementsmanagement (RM) best practices in real product development situations. Betty is a principal consultant forBorland where she: instructs/mentors on CaliberRM and RM processes and techniques; is certified to teachthe Karl Wiegers' course, "In Search of Excellent Requirements"; develops requirement management andchange management processes; conducts process gap analysis making recommendations forimprovements; and, develops RM implementation strategies and mentors client implementation personnel.

Before joining Borland, Betty was a senior systems consultant for The Associates providing teammanagement for project development/business analysis, a senior data architect for Burlington NorthernRailroad providing data analysis/database implementation, and a computer systems specialist for ComputerSciences Corporation (CSC) providing enterprise functional/data analysis. Betty holds a Bachelor of Sciencedegree in Mathematics/Education from Florida State University in Tallahassee, Florida with additional

coursework in Computer Science.

[email protected]

Manage Change OrITWill Manage You!

Betty Luedke - Borland Software Corporation

Introduction

Basic Truths

Change Happens...

Change Has An Anatomy

Request For Change =/= Requirement

A Tool Is Not A Process

Undisciplined Change Causes Inadequate Requirements/DesignArtifacts

Getting A Grip
http://gp.embarcadero.com/authors/edit/1555.aspxhttp://gp.embarcadero.com/authors/edit/1555.aspxmailto:[email protected]:[email protected]://conferences.embarcadero.com/article/32191#Introduction%23Introductionhttp://conferences.embarcadero.com/article/32191#Basic%20Truths%23Basic%20Truthshttp://conferences.embarcadero.com/article/32191#Change%20Happens%23Change%20Happenshttp://conferences.embarcadero.com/article/32191#Change%20Has%20An%20Anatomy%23Change%20Has%20An%20Anatomyhttp://conferences.embarcadero.com/article/32191#Request%20For%20Change%20=/=%20Requirement%23Request%20For%20Change%20=/=%20Requirementhttp://conferences.embarcadero.com/article/32191#Request%20For%20Change%20=/=%20Requirement%23Request%20For%20Change%20=/=%20Requirementhttp://conferences.embarcadero.com/article/32191#Request%20For%20Change%20=/=%20Requirement%23Request%20For%20Change%20=/=%20Requirementhttp://conferences.embarcadero.com/article/32191#A%20Tool%20Is%20Not%20A%20Process%23A%20Tool%20Is%20Not%20A%20Processhttp://conferences.embarcadero.com/article/32191#Undisciplined%20Change%23Undisciplined%20Changehttp://conferences.embarcadero.com/article/32191#Undisciplined%20Change%23Undisciplined%20Changehttp://conferences.embarcadero.com/article/32191#Getting%20A%20Grip%23Getting%20A%20Griphttp://gp.embarcadero.com/authors/edit/1555.aspxmailto:[email protected]://conferences.embarcadero.com/article/32191#Introduction%23Introductionhttp://conferences.embarcadero.com/article/32191#Basic%20Truths%23Basic%20Truthshttp://conferences.embarcadero.com/article/32191#Change%20Happens%23Change%20Happenshttp://conferences.embarcadero.com/article/32191#Change%20Has%20An%20Anatomy%23Change%20Has%20An%20Anatomyhttp://conferences.embarcadero.com/article/32191#Request%20For%20Change%20=/=%20Requirement%23Request%20For%20Change%20=/=%20Requirementhttp://conferences.embarcadero.com/article/32191#A%20Tool%20Is%20Not%20A%20Process%23A%20Tool%20Is%20Not%20A%20Processhttp://conferences.embarcadero.com/article/32191#Undisciplined%20Change%23Undisciplined%20Changehttp://conferences.embarcadero.com/article/32191#Undisciplined%20Change%23Undisciplined%20Changehttp://conferences.embarcadero.com/article/32191#Getting%20A%20Grip%23Getting%20A%20Grip


2/31

The PAIN

System Development Participants

Attitudes and Biases

Organizational Readiness/Maturity

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

Moving To An Improved Change Process

Understanding...

Determining...

Implementing...

Monitoring...

Improving...
http://conferences.embarcadero.com/article/32191#The%20PAIN%23The%20PAINhttp://conferences.embarcadero.com/article/32191#The%20PAIN%23The%20PAINhttp://conferences.embarcadero.com/article/32191#Attitudes%20and%20Biases%23Attitudes%20and%20Biaseshttp://conferences.embarcadero.com/article/32191#Organizational%20Readiness/Maturity%23Organizational%20Readiness/Maturityhttp://conferences.embarcadero.com/article/32191#Exploring%20Proven%20Practices%23Exploring%20Proven%20Practiceshttp://conferences.embarcadero.com/article/32191#Environment%23Environmenthttp://conferences.embarcadero.com/article/32191#Environment%23Environmenthttp://conferences.embarcadero.com/article/32191#Process%23Processhttp://conferences.embarcadero.com/article/32191#Project%20Dimensions%23Project%20Dimensionshttp://conferences.embarcadero.com/article/32191#Participation%23Participationhttp://conferences.embarcadero.com/article/32191#Change%20Control%20Process%23Change%20Control%20Processhttp://conferences.embarcadero.com/article/32191#Impact%20Analysis%23Impact%20Analysishttp://conferences.embarcadero.com/article/32191#Prioritization%23Prioritizationhttp://conferences.embarcadero.com/article/32191#Decision%20Matrices%23Decision%20Matriceshttp://conferences.embarcadero.com/article/32191#Customer%20Input%20Filters%23Customer%20Input%20Filtershttp://conferences.embarcadero.com/article/32191#Change%20Control%20Board%23Change%20Control%20Boardhttp://conferences.embarcadero.com/article/32191#Triage%20Officer%23Triage%20Officerhttp://conferences.embarcadero.com/article/32191#Tool%20Support%23Tool%20Supporthttp://conferences.embarcadero.com/article/32191#Moving%20To%20An%20Improved%20Change%20Process%23Moving%20To%20An%20Improved%20Change%20Processhttp://conferences.embarcadero.com/article/32191#Understanding...%23Understanding...http://conferences.embarcadero.com/article/32191#Determining...%23Determining...http://conferences.embarcadero.com/article/32191#Implementing...%23Implementing...http://conferences.embarcadero.com/article/32191#Monitoring...%23Monitoring...http://conferences.embarcadero.com/article/32191#Improving...%23Improving...http://conferences.embarcadero.com/article/32191#The%20PAIN%23The%20PAINhttp://conferences.embarcadero.com/article/32191#The%20PAIN%23The%20PAINhttp://conferences.embarcadero.com/article/32191#Attitudes%20and%20Biases%23Attitudes%20and%20Biaseshttp://conferences.embarcadero.com/article/32191#Organizational%20Readiness/Maturity%23Organizational%20Readiness/Maturityhttp://conferences.embarcadero.com/article/32191#Exploring%20Proven%20Practices%23Exploring%20Proven%20Practiceshttp://conferences.embarcadero.com/article/32191#Environment%23Environmenthttp://conferences.embarcadero.com/article/32191#Environment%23Environmenthttp://conferences.embarcadero.com/article/32191#Process%23Processhttp://conferences.embarcadero.com/article/32191#Project%20Dimensions%23Project%20Dimensionshttp://conferences.embarcadero.com/article/32191#Participation%23Participationhttp://conferences.embarcadero.com/article/32191#Change%20Control%20Process%23Change%20Control%20Processhttp://conferences.embarcadero.com/article/32191#Impact%20Analysis%23Impact%20Analysishttp://conferences.embarcadero.com/article/32191#Prioritization%23Prioritizationhttp://conferences.embarcadero.com/article/32191#Decision%20Matrices%23Decision%20Matriceshttp://conferences.embarcadero.com/article/32191#Customer%20Input%20Filters%23Customer%20Input%20Filtershttp://conferences.embarcadero.com/article/32191#Change%20Control%20Board%23Change%20Control%20Boardhttp://conferences.embarcadero.com/article/32191#Triage%20Officer%23Triage%20Officerhttp://conferences.embarcadero.com/article/32191#Tool%20Support%23Tool%20Supporthttp://conferences.embarcadero.com/article/32191#Moving%20To%20An%20Improved%20Change%20Process%23Moving%20To%20An%20Improved%20Change%20Processhttp://conferences.embarcadero.com/article/32191#Understanding...%23Understanding...http://conferences.embarcadero.com/article/32191#Determining...%23Determining...http://conferences.embarcadero.com/article/32191#Implementing...%23Implementing...http://conferences.embarcadero.com/article/32191#Monitoring...%23Monitoring...http://conferences.embarcadero.com/article/32191#Improving...%23Improving...


3/31

Summary

References

Introduction

The premise that you must proactively "manage change orITwill manage you" is borne

out time and time again as companies, large and small, with varied system developmentenvironments struggle to be productive. Understanding the anatomy of change and the

all too familiar surrounding circumstances/dynamics will help us use proven practiceseffectively to not only manage requests for change, but to also evolve a product into

something of real value. Recognizing the circumstances in which we must manage

change (in-house/outsourced development, management positions/attitudes, environment

dynamics, natural requirement maturation/requested alteration,...) will lead usto employing approaches (requirement strategies, project dimensions, impact analysis,

prioritization, change control board, triage officer, decision matrices, ...) in a way that

makes sense.

On that note, let us explore:

Some basic truths about change

What it takes to get a grip

Some proven approaches to managing change

What it takes to improve

Basic Truths

There are some basic truths about change and they include:

Change happens...

Change has an anatomy


A toolis not aprocess

Undisciplined change is a major cause of inadequacies inrequirement/design/test artifacts

Now, let us look at each of these basic truths in more detail to provide a foundation for effectively andproactively managing change.

Change Happens...

Change happens...

...but it is how we embrace ITthat will make the difference. Will you ignore IT? ...react to IT? ...manage IT?

Digging a little deeper brings us to the understanding that change not only happens, but ITdoes not goaway. We do not have control over this circumstance, but we do have control over how we react to IT.Approach examples abound and include:IGNORE IT

Changes happen in an ad hoc, uncontrolled way and you arelucky if things work out.

REACT to IT
http://conferences.embarcadero.com/article/32191#Summary%23Summaryhttp://conferences.embarcadero.com/article/32191#References%23Referenceshttp://conferences.embarcadero.com/article/32191#Summary%23Summaryhttp://conferences.embarcadero.com/article/32191#References%23References


4/31

A valiant attempt is made to accommodate the requestwithoutrealizing the full ramifications.

Each request for change is looked at individually butsometimes one request'undoes' what is requested in another.

Every request for change is considered a requirement.MANAGE IT

For each request for change :o Review requestfor understanding

o Assess requestas to:

Its business/technical value

What would have to changed/be added/bedeleted (requirements, design, code, tests,documentation,...)

What kind of effort and resources would thistake

The feasibility of the effort from theperspective of business/technical/resource/anotherrequest for change/...

o Decide whether or not to honor the request

(approved, deferred, rejected)

If approved,o Adjust schedules, funding, resources appropriately

o Make needed additions/modifications/deletions to

system artifacts (requirements, design, code, tests,documentation,...)o Test the modified system (system tests, integration

tests, user acceptance tests,...)o Deploy the modified system

So, let us look at a few good practices that might shed some light on the possible results of each. You mightuse another approach, but what is key is that you see how your approach stacks up with regards to goodpractices. It all comes down to that our approach to managing change must ensure an acceptable riskin thesituation at hand. Examining these good practices provides insight into what is acceptable risk. Forinstance, is it acceptable that the customer is not satisfied? Is it acceptable that there is not adequate time,funding, resources to complete the request? Is it acceptable that ...?


5/31

Change Has An Anatomy

Change has an anatomy

The structure of change helps us understand what we need to manage change while theprocess by which we control change guides us through the steps.

STRUCTURE

o A request for change is either an enhancementor a defect

(requirement, design, code, test, ...).

Note:


6/31

The term 'request for change'is intentionally used throughoutinstead of'change request'. In talking to many clients about

the topic of change, the term 'change request'was often given

a limited meaning in an organization, such as just defects orjust enhancements. We need to think about both, and simply

changing the words to 'request for change'catches the ear and

encourages a broader view of change.

o Sometimes the requestis really a demandwhich often

causes even an established change process to short circuit.

If we devise a process tomanage change, we soonrealize that this process will not

always be followed. Someonewith clout will mandate that anenhancement/modification bemade no matter what. Bringingattention to this reality is notintended to deter you fromestablishing a change controlprocess, but in fact quite theopposite. Plan for this realityby thinking about what you willdo when your well thoughtthrough process is notfollowed.

How will the potential

ramifications bemitigated?

How can you protectother develop activitycurrently in progress?

How can this type ofbehavior be avoided in the future?

Part of being prepared is not having to think through regrettable but predicable situations like this in the heatof the moment.

o A request for change can sound the death knell for a number of system

development artifacts.


7/31

When a defect is found in code,do you know the root cause?

Oops!...forgot to activate the button...correct the code

An error in the design caused an error in code...correct the code/design

An error in requirements caused an error in design which caused theerror in code...correct the code/design/requirements

If these errors in the design and requirements are not corrected, then these system development artifactswill slowly but surely 'die'. To effectively manage the evolution of a product or a particular work effort(project) to enhance/fix a product, we need 'living, breathing' artifacts which tell us WHAT the product does(requirements), HOW the product works (design) and HOW we will prove that the product works as needed(tests). 'Living, breathing' artifacts are important when development is done in-house, but these artifactsbecome a primary source of communication when development is outsourced.

o There is important information that should be kept about the request for

change itself as we try to move to an improved change approach (fromoblivious ... reactive ... managed). The following illustrates the type ofinformation1 that would be appropriate to keep, but it is also important that youknow how you will use this information.


8/31

PROCESS

The bad news is that we have lots of changes to deal with, but the good news is that the basic changecontrol process is the same whether you are dealing with an enhancement or defect (i.e.,propose> reviewfor understanding > assess > decide). Keep in mind that even though the change control process remainsvirtually the same, there will be differences as to:

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 ofrequest for change

The amount of time it takes topropose> review for understanding >assess > decide ( i.e., 15 minutes or 3 weeks)

The effect of having different decision makers, different information needed, different tools used, differentamounts of time needed to assess,... can be minimized by having:

An established change control process

Change management tool, such as StarTeam, which can enforce thechange management process from a workflow perspective

Agreed on decision criteria for various stages in the systemdevelopment life cycle

Standard information that is kept about a request for change andknowing how this information will be used

Guidance on which decision makers need to be involved under whatcircumstances


9/31


It is a fatal mistake to think that a request for change is something that must be done (i.e., a requirement).Just differentiating between the two will help since just one request for change can add/modify/delete one ormore requirements, design elements, modules, tests,... It is also important to note that some requests forchange are based on a preference and some are based on NEED. Can you tell the difference?

Automatically thinking that any request for change in your product necessitates a 'go forth and do' action,definitely puts you in a reactive mode that introduces risk hidden behind "I'm just trying to make thecustomer happy". As we have seen earlier a request for change is just that--a requestto fix something or toprovide some new functionality. We would not think of altering a house without checking on the buildingcode, structural soundness, intent of use,... Why then should altering a system be any different?

If you are in a culture where a request for change =requirement, then some adjustment in how all partiesthink about a request for change is key. Start with changing the term from 'change request'to 'request forchange'because this simple change in terminology catches a person's ear and clues them into the fact thatyou may be talking about something different than the status quo. Just differentiating between a request forchange and a requirementwill help those involved realize that a single request for change can be the reasonfor the addition/modification/deletion of one or more requirements, designelements, modules, tests,...

It is also important to note that some requests for change are based on a preference and some are basedon NEED. The requests based on a preferenceare often stated vehemently but fall short when the realbusiness NEED (or lack of one) is explored. Whether your organization is a vendor who sells a product orhas multiple divisions, you face similar challenges, namely dealing with a variety of perspectives to satisfyand a seemingly endless stream of requests to manage. So, getting our minds around this situation isimportant. The following are basic to facilitating the effective management of change:

A request for change must state the business NEED, not apreference, because all requirements for our product will be based onbusiness NEED, not preference.

Customers (internal or external) are free to make requests forchange, but decisions on whether or not to honor the request will bemade according to an established process and decision criteria.

It is important to understand that a stated business NEED and an established change control process formaking change decisions are both essential to making wise change decisions. There are additionalconsiderations, however, when your organization is a vendor selling a product or a large company with

multiple divisions.


10/31

ATool Is Not A Process

As Karl Wiegers clearly states3,a process is needed to manage change, but a tool is not a process! It isunderstanding how you will control change (with or without automated support) that is key. If you have atool such as StarTeam to help you manage change to system development artifacts, its configuration andworkflows should reflect your process for managing change.

Undisciplined Change Causes Inadequate Requirements/Design

ArtifactsParticularly in the case of defects, code is changed, but the root cause (incorrect/incomplete design orrequirement or test) is not fixed or even identified. This pattern of inaction causes once viable, living,breathing development artifacts to not be the representation of the product they once were. Oncerequirement or design documentation can not be trusted, we have a dying artifact on our hands. If a requestfor change is to be meaningfully assessed as to its value, impact and feasibility, it is the living, breathingrequirements, design, tests that make sound recommendations possible.


11/31

The detrimental consequences of undisciplined change are not always the result of action run amok. It isoften inaction that is the silent killer. Subtle for sure, but it is sabotaging none the less when code ischanged and the requirement/design/test artifacts are not. As the credibility of these non-code artifactsheads south, the assessment of the work involved in a requested change requires more time to evaluate orworse yet relies on someone's memory. Once again, it is all about acceptable risk.

Is it acceptable to say 'yes' to a request for change without reallyknowing the ramifications?

How will you know the ramifications unless you either have 'living,breathing' requirement/design artifacts OR you once again re-analyze what the

product does?

The real key here is to have a structured way to not only create, but to also manage your developmentartifacts. This way when a change is requested, you are ready to assess and to maintain 'living, breathing'artifacts for the next time. There are a few essentials that bear mentioning:

Establish requirements strategies for requirement types, requirementtraces, requirement baselines

Establish a process for developing/managing requirements becauserequirements should be the basis for design and test

Establish a process for managing change to the system that considersrequests, makes educated decisions and provides adequate time, funding andresources if the request for change is to be honored

Establish tool support (StarTeam, CaliberRM,...) to manageversions/configurations of all system development artifacts (single requirement,set ofrequirements, analysis models, design models, code modules,products,tests,...)

Getting A Grip

Getting a grip means understanding your situation so that you will make some wise choices in implementinga change approach. Knowing your environment and its dynamics includes identifying:

The PAIN... Have you experienced rework, missed schedules, over-budgetcosts, specificity needed for outsourcing,...?

The 'right' participants to help make smart decisions...What different

perspectives need to be considered? Attitudes/biases about:

o Existing procedures...Are they robust/inadequate, followed/ignored,...?

o Requests for change...Is the answer always Sure we can?...Who the

decision makers should be?o Priorities...Does the loudest voice win?...Does preference win over

need?o Accountability...Who is responsible?...How can we make things better?

Organization readiness/maturity...Capability Maturity Model is good measuringstick.

The PAIN

Organizational PAIN may manifest itself in rework, missed schedules, over-budget costs, specificity neededfor outsourcing,... Worse case, this PAIN causes problems that must be dealt with, but best case it is thatthis PAIN stimulates attention and motivates improvement. Improving the management of change usuallyinvolves a cultural change. Speak to those who need to change their behavior in terms of something that isbothering them (PAIN). This is one way to get their attention and to approach even the reluctant.


12/31

System development participants

Understanding who needs to be involved in a request for change decision comes from knowing not onlywhose artifacts will be impacted, but who will provide assistance in making a smart decision.

When various perspectives need to be considered, it is wise to have a group 'on call' to help make decisionsbased on benefit, penalty, cost and risk. In many organization this group is called a Change Control Board(CCB). Keep in mind that in one situation, the CCB may be one person and in another situation it may be anamed group of people who meet regularly to control the changes requested for a system. A more formalapproach to the CCB is advised when you are:

A vendor with multiple customers to satisfy

A company with multiple divisions to satisfy

Outsourcing your development

Working on a large project

As you might have guessed, a request for change may involve many system development artifacts or only afew. Would it be a smart thing to do to have someone 'triage' the requests...you know, have someoneinitially decide what artifact are involved and who needs to help make the decision? The concept of a 'triageofficer' who directs traffic might set the path for a requestto:

"Just change the code!"

(Nothing else but code is impacted.)

OR"Oops! We did not design/code this right because we did not understand the requirement. We needto revisit these requirements and talk with ..."

(Code/design/requirements/tests are impacted.)

Attitudes and Biases

Dealing with attitudes and biases of those who will make decisions is not an exact science. It crucial tofoster a view point larger than any one perspective. The things that can stand in the way are:

Existing procedures...Are they robust/inadequate, followed/ignored,...?

Decision about requests for change... Is the answer always Sure wecan?...Who the decision makers should be?

Priorities...Does the loudest voice win?...Does preference win overneed?

Accountability...Who is responsible? (not me)...How can we makethings better?

Here are some things to keep in mind:

Keep it factual...Stay away from "you", "us", "them",... Try "it is myunderstanding that..."

Ask for relative importance...Indicating benefit/penalty/cost/risk shouldhelp avoid the politics.

Focus on business NEED...Truly embracing the business NEED canfoster a global mindset.

Focus on the situation not the person...Saying "you" makes it personal.

If you are experiencing one or more of these hurdle, here is a technique3 for working through a stickysituation:

Define the problem

State the root cause(s)


13/31

State the impact

Brainstorm on possible solution(s)

Determine the barrier(s) to the possible solutions

Actually, it is the barriers that offer the most hope. Chip away at those things that are within your control andthe situation will change.

Organizational Readiness/Maturity

An organization's readiness to manage a change to what was planned is an indicator of the organization's

maturity. The Capability Maturity Model (CMM)2 is an effective measuring stick for how capable (mature) anorganization is in handling change. At the 'repeatable' maturity level, the effective management of changepermeates a number of CMM key process areas and the associated practices, namely:


14/31


15/31


16/31


17/31

It is interesting to note that CMM focuses not only on change to a product within a project (work effort), butalso on the process that the project (work effort) follows and the technology used. Our focus for this paper,however, will remain on managing changes to a product within a project (work effort).

As CMM points out, each practice must be approached with the commitment and ability to perform. So whatcan help us set the stage. Consider the following:

Provide an environment conducive to controlling change by providing:o Trained resources

o Requirements management process

o Change control process

Follow the change control process:o Providing needed request for change information with version

controlo Reviewing a request for change for understanding

o Assessing the impact of honoring a request for change and

making a recommendationo Agreeing to WHAT is to be changed

o Adjusting schedule/budget/resources for a request for change

that is to be honored

Looking at the commitment and ability to do the above, we must ask what that really means from anorganization's perspective and from an individual's perspective.

n

Exploring Proven Practices


18/31

As you explore setting up an environment that is conducive to the effective management of change,consider the following proven practices summarized below:


Establish a strategy for requirement types, requirement traces andrequirement baselines

Elicit/analyze/specify/verify/validate discrete requirements organizingthem using requirement type strategy, relating them using the requirement tracestrategy and agreeing to them using the requirement baseline strategy

Project Management

Understand the project dimensions (features, quality, cost, staff,schedule)

Change Management

Establish a change control process which:o Reviews request for change for understanding (both by the

reviewers of the requestand by the project team implementing therequest)o Assesses impact and feasibility to include:

Identifying what artifacts would have to change

Using a prioritization model that ensures importanceis looked at from multiple perspectives

Using decision matrices based on the project'sposition in system development life cycle

Using customer input filters to help vendors andorganizations with multiple divisions stay in control of theirproducts

o Makes timely, informed request for change decisions

o Ensures that appropriate modifications to schedule, budget

and resources are made if the request for change is to be honored

Ensure appropriate participation in the change control process by:o Establishing a change control board to make decisions that

require multiple perspectiveso Establishing a triage officer to route a request for change

appropriately

Let us explore each of these areas to see more specifically the practices available to help us managechange effectively.


The effective development and management of requirements lays the foundation for effective changecontrol. It is important to plan:

How requirements will be organized? (requirementtype strategy)

How various types of requirements are related?(requirement trace strategy)

How/when agreements about requirements will berecorded? (requirement baseline strategy)

It is equally important to actually use these strategies to help stabilize your project by:

Eliciting/analyzing/specifying/validating discrete requirements


19/31

Organizing them using requirement types

Relating them using the requirement traces

Agreeing to a set of requirements and documenting thisagreement using a requirement baseline

Requirement Strategies1

The Requirements Roadmap below graphically illustrates a suggested:

Requirement type strategy

Requirement trace strategy

Requirement baseline strategy

Project Management

Truly understanding a project's situation is multi-dimensional. We need to understand whether each of thefollowing project dimensions is a driver, constraint or offers a degree of freedom:

Features

Quality

Cost

Staff

Schedule


20/31

Project Dimensions3

Every project situation is different, but filling out a chart like the example below can provide insight not onlyto project direction, but also to decisions regarding change.

There will always be trade-offs when making decisions about requirements, design and the changesrequestedto WHAT (requirements) is being built or HOW (design) the system will support the user. It will beimportant to factor in the project dimensions into decisions about requests for change.

Change Management

Effective management of change requires a process, techniques and tool support. To gain a betterunderstanding of exactly what it takes to be effective here, we will look at:

Change control process

Impact analysis

Prioritization

Decision matrices

Customer input filters

Change control board

'Triage' officer

Tool support

Change Control Process

The change control process below is an example of the steps needed to manage change. It will, however,only be a effective as the techniques used, the person(s) performing the task and the tool support provided.The practices and techniques discussed in the sections below are aimed at doing a good job of assessing


21/31

impact/value/feasibility of honoring a particularrequest for change. As indicated in the change controlprocess below the Borland ALM Suite offers excellent coverage.

A request for change has a number of states. It is helpful to define these states and use a state transitiondiagram (example below) to show how these states are related. StarTeam workflows can help manage thetransition from one state to another.


22/31

Impact Analysis

The whole point of doing an impact analysis is to facilitate effective change decisions so that your projectteam or your customer will not be sorry later about a change that was made or not made. Knowing whatartifacts (code, design, requirements, test,...) will need to be developed/modified (if this request for change ishonored) is important information in making smart change decisions. If you have established andmaintained a trace strategy not only for requirements but for those artifacts related to requirements (design,code, tests,...), you will have tremendous insight into what artifacts could be affected. Just determining whatartifacts might be affected (important as that is) is not enough. Just because you know how to comply with a

request for change does not mean your team should do it. As we look at prioritization, we will focus onbenefits, penalties, cost and risk--all of which help us determine whether or not a requested feature is whatwe want to recommend.

Prioritization


23/31

The whole point of prioritization is to facilitate effective change decisions so that your project team or yourcustomer will not be sorry later about a change that was made or not made. Prioritization is all aboutdetermining relative importance when considering multiple perspectives. No matter what prioritizationmethod you use, you want it to based on something more than preference. Often times a scale of 'high','medium', 'low' is used, but this scale is of little or no help when everything is 'high' (or worse yet 'higherthan high' or 'highest of the highs'). A scale like 'must have', 'should have', 'nice to have' is clearer and canhelp distinguish between real NEEDs and wants/preferences.

Since there are so many things to consider when deciding what is most important, let us explore yet another

way to state relative importance. The prioritization model3 presented below considers the value

(benefit/penalty), cost and risk for each feature. This technique should be used initially during requirementsdevelopment, but this information will come in very handy when making decisions about requested changes.

The benefit, penalty, cost and risk are each rated on a relative scale of 1-9. Then formulae are used todetermine the VALUE %, COST% and RISK% and ultimately the PRIORITY. Let us take this one step at atime. For each feature:

1. Assign Benefit and Penalty using a range from 1-9.Add across for Relative Value (e.g., Feature 1 Relative Valueis 14) and down for Relative Value TOTAL (i.e. Feature 1Relative Value TOTAL is 40).

2. Calculate the VALUE % by dividing the Relative Valueby the Relative Value TOTAL and converting to a percentage(e.g., divide the Feature 1's Relative Value of 14 by theRelative Value TOTAL of 40 and convert to a percentageobtaining 35%).

3. Assign the Relative Cost and Relative Risk using a range from 1-9.


24/31

When assigning Relative Cost consider the time it takes to:

o Fully refine requirements and review them

o Design and review user interface, architecture, algorithms,...

o Build and evaluate a prototype

o Code, review code, rework, unit test, rework, document

o Integrate with rest of product, test, rework

o Develop and execute system tests, rework

o Provide program documentation

o Conduct support activities (configuration management, quality assurance, publications,...)

o ...

4. Calculate the COST % by dividing the Relative Cost by the Relative Cost TOTAL (e.g., divide theFeature 1's Relative Cost of 3 by the Relative Cost TOTAL of 20 and convert to a percentage obtaining15%).

5. Calculate the RISK % by dividing the Relative Risk by the Relative Risk TOTAL (e.g., divide theFeature 1's Relative Risk of 2 by the Relative Risk TOTAL of 18 and convert to a percentage obtaining13%). .

6. Calculate the PRIORITYby dividing the VALUE % by the sum of the COST % plus the RISK %

(e.g., VALUE % which is for Feature 1 35 = 1.25)(COST % + RISK %) (15 + 13)

Now, sort the features by their PRIORITY. This should not only tell you what to work on first, but it shouldalso help in making change decisions.

Decision Matrices

The whole point of using decision matrices is to facilitate effective change decisions so that your projectteam or your customer will not be sorry later about a change that was made or not made. As a project team


25/31

moves through the phase of system development, change will be requested. The criteria by which changedecision should be made will be different depending on the phase in which the project is currently. Forinstance, if a project team is just beginning to gather requirements and a new requirement comes to light, itis 'no big deal'. If that same new requirement came to light at the beginning of system testing, it would be 'aBIG deal'. This is all very confusing to the customer who wonders why you say 'yes' sometimes and 'no'other times. If you establish decision criteria for the various stages in your project life cycle, the criteriashould guide choices and help you set customer expectations appropriately. Why not talk to your customerup front about the very predicable decisions that will be made just because of where your project is in the lifecycle.

The decision matrix below is an example of simple criteria used to guide decisions for a project that isreplacing an existing system and is in the early stages of integration testing. Note that the WAIT does notmean 'wait to implement', it means 'wait to even look at the request'!


26/31


27/31

Customer Input Filters

The whole point of using input filters is to facilitate effective change decisions so that your project team oryour customer will not be sorry later about a change that was made or not made. Let us 'start with the endin mind'. If we want a product that will meet the needs of multiple groups (vendor selling industry-leadingsoftware, company with multiple division,...), then we need a 'global mindset'--one that focuses on thebusiness NEED not the preference of a particular group. So, how do you get people to think that

way? Setting expectations is at least part of the answer. When a focus group is formed to explore new (orold) territory, make sure that the participants know that their input does not constitute requirements, theirinput will be taken under advisement as a request for change. If you share the goals of your product(whether it is to be sold commercially or it is to be used by different divisions), and provide this as thecontext for receiving information from your customers, then their comments/requests will be more alignedwith your purpose. From the beginning, talk about trade-offs (difficult decisions) that will predictably have tobe made and the value of their input in making these important decisions.

If you are a vendor company, you might appeal to selected customers by asking them to invest in the 'nextstep' for their industry. The payoff for them is being recognized as forward-thinking company that is settingthe pace for the industry (using your product, of course). A vendor company, however, must remain incontrol of its product's destiny for we all know what happens to products owned by a 'committee'.

If you are a large company with many divisions all trying to work together, you might use the company's

bottom-line reason for existence (profit, customer service,...). Usually most employees in a large companyare not very close to the bottom-line. Therefore it is vital to make them aware that the inconsistency betweendivisions causes redundant work, say in Accounting, and that extra work (and foul ups) cost the company,and these costs reduce profits on which bonuses are paid or research is funded. The real payoff though isnot the extra bonus that might come, but the shift from an 'us vs. them' environment to an 'our' environment.

Change Control Board

The whole point of using a change control board is to facilitate effective change decisions so that yourproject team or your customer will not be sorry later about a change that was made or not made. Thisapproach involves getting the right people involved in the right way at the right time. On smaller projects,

the change control board (CCB) may be the project manager who takes the responsibility for:

Understanding a request for change

Assessing its value/impact/feasibility by drawing on the expertise of others where necessary

Making a timely decision

Ensuring that schedules/budget/resources are modified appropriately if the requestis to behonored

On larger projects, a group of people who represent different perspectives needs to be identified and madepositively accountable for decisions regarding requests for change. The members of this group mightrepresent development, customer, project management, testing, and any other group that will be key inmaking smart decisions. Now, the challenge is to not have 'casts of thousands'. One approach is to chooseparticipants wisely having multiple perspectives represented by one person. The trick here is to find thosewho can credibly represent these perspectives. It may not be as difficult as you might think if the people inyour organization are somewhat mobile. Remember that the members do not need to be totallyknowledgeable about everything, but they do need to know when to seek expert advice.

For a CCB to be successful, they need to have the authority to make binding decisions and be establishedby a CCB charter stating the group's purpose, scope of authority, membership, decision making process,...

The CCB is charged3 to:

Determine the system artifacts that could be affected (Here is where the trace information will bevery helpful.)


28/31

Understand the implications of making the requested changeo Will the change affect quality attributes (performance,...)?

o Is the change technically feasible? ...feasible with regards to schedule, cost, resources?

o Will the change overload computer resources for development, test or host environment?

o Will completed work have to be discarded?

o Does the change violate any business rules?

o Does the change affect other tasks orrequests for change?

Identify tasks needed to accomplish the requested change and then:o Estimate total labor hours for all tasks to:

Create/modify design, code, tests, user interface, database, reports,... Develop/evaluate prototype

Review...rework

Retesto Allocate resources to the identified tasks

o Sequence tasks identifying predecessors

o Determine if the change is on the project's critical path

o Estimate the schedule and cost impact for this request for change to be implemented

n

n n

'Triage' Officer

The whole point of using a 'triage' officer is to facilitate effective change decisions so that your project teamor your customer will not be sorry later about a change that was made or not made. One of the things thatwill sabotage a well-intentioned CCB effort is having all these highly sought after people (with other jobs ontheir plates) meet routinely to talk about trivial requests for change. So, how can this be avoided? Havesomeone to review and route the requests for change appropriately. In other words, 'triage' the steadystream ofrequests for change. Defects that only involve something that was not coded correctly can godirectly to the developer if there are not design or requirement implications. A request for change whichenhances the system and affects a number of business areas as well as requires data from several sourcesshould go to the CCB. A 'triage' officer does minimal research to facilitate the routing of a request forchange to the developer for action or to the CCB for consideration. A 'triage' officer can, at an acceptable

risk, speed up your process by appropriately routing requests for change.

Tool Support

Once again, a tool is nota process! At best, a tool to help manage request for changes will make youefficient, but it is the change control process and the people performing this process that will make youeffective. Whether you use Excel or a configuration management tool such as StarTeam, yourimplementation will only be as good as the process you implement and the discipline you have to follow theprocess. In your tool selection, it is important to insist on the ability to:

Capture each request for change discretely and keeppertinent information about the request(status, source,...)

Relate each request for change to affected artifacts(anotherrequest for change, requirements, design, code,tests,...)

Support a collaborative environment in which related'discussions' and related information can be recorded


29/31

Moving To An Improved Change Process

Moving to an improved change process means:

Understanding...

The nature of change

Possible approaches to managing change

Your environment (its people, its practices, its biases, its PAIN, itstechnology, its current metrics,...)

Possible tool options and how well they fit the requirements for yourchange control process

Determining...

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 (StarTeam, CaliberRM,...)

Implementing...

The agreed to change control process with adequate training and toolsupport (StarTeam, CaliberRM,...)

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

Getting started is the hardest part. Let us look at W. E. Deming's quality circle4 as a model for improvement.


30/31

Now, let us see how our understanding, determining, implementing, monitoring and improving fit withDeming's respected and proven model for improvement.

Summary


31/31

'Managing change so ITdoes not manage you' is about:

Learning some basicso Change happens...

o Change has an anatomy

o Request For Change =/= Requirement

o A tool is not a process

o Undisciplined change causes inadequate requirement/design artifacts

Getting a grip on:o The PAIN

o System development participants (business, analysts, development,

testing,...)o Attitudes and biases

o Organizational readiness/maturity

Putting some proven practices in motion, such as:o Requirement strategies for requirement types, requirement traces,

requirement baselineso Project dimensions of features, quality, cost, schedule, resources seen

as a driver, constraint or a degree of freedomo Change control process/request for change states

o Impact analysis

o Prioritization

o Decision matrices

o Customer input filterso Change control board

o 'Triage' officer

o Tool support

Being prepared to improve byo Understanding the nature of change and the possible approaches for

managing change in your environmento Determining a change control process/tool support and sticking with it

o Implementing an agreed to change control process/tool

o Monitoring execution of the change control process to identify problem

areas

Doing IT!o Improving by modifying the change control process as needed

manage change or it will manage you

Documents