CM as Communication and Coordination Enabler

surprisingly common to find the same applications being changed by different projects looking to release together, and without the projects being aware of each other until late in the process. This then caused unexpected delays.

Coordinating Change Across the Organisation - Who is Responsible?

It is vital that for each service/application you have a definitive responsible owner who makes decisions about that service/application. If you don’t have a single owner, you generally have no owner! Involving service/application owners in changes is a simple coordination mechanism.

A simple table or spreadsheet such as the following is remarkably effective in communicating and coordinating change across the organisation:

ID

Title

Owner

Service

Status

Rel

Date

Project

12

Order Entry

John

Order Processing

Testing

R4

29/10/2009

PR-ABC

13

Order Amend

John

Order Processing

Tested

R4

29/10/2009

PR-ABC

14

Order Payment

Sarah

Payments

Live

R1

20/05/2009

PR-DEF

15

Order Delete

John

Order Processing

Live

R2

19/10/2009

PR-GHI

16

Stock Check

Anne

Stock Control

Live

R3

25/10/2009

PR-JKL

Geoff started pulling together this information and publishing it on their intranet. But although he took responsibility for pulling it together initially, he looked to make others (application owners) take appropriate responsibility for making decisions and coordinating changes across the organisation.

One mistake organisations make is to  confuse responsibility with documentation . Because CM people understand the principles, they often take it upon themselves to pull out the information and then communicate it (intranet/information radiators). But, just because the CM team have pulled the information together doesn’t make them responsible for changes, or deciding what to do. This is not at all the same thing.

Change in Status

While a simple table conveys lots of useful information, it becomes even more useful if you are able to easily show changes and updates:

ID

Title

Owner

Service

Status

Rel

Date

Project

12

Order Entry

John

Order Processing

Delayed

R4

29/10/2009

PR-ABC

13

Order Amend

John

Order Processing

Tested

R4

29/10/2009

PR-ABC

14

Order Payment

Sarah

Payments

Live

R1

20/05/2009

PR-DEF

15

Order Delete

John

Order Processing

Live

R2

19/10/2009

PR-GHI

16

Stock Check

Anne

Stock Control

Live

R3

25/10/2009

PR-JKL

17

Order Print

John

Order Processing

Dev

R5

15/01/2010

PR-AB2

You also need to be very clear as to where the definitive version of this document is, and what the process of changing it is (who has access rights, how will you detect concurrent updates etc). Wiki pages with version control can be very effective (don't fall in to the trap of using spreadsheets as they are often hard to compare and with emails it quickly becomes difficult to track status).

Once you have it, then it is vitally important to ensure that the information is maintained and kept up to date. If people start mistrusting it because of errors, or because the information is out of date, then it quickly loses value.

Don't go overboard with the information that is shown - if you start making it too onerous to update, then it will also become out of date and get ignored.

It is a variant of a simple dashboard which has become common with many tools in recent years. But you don't need to go overboard with the technology behind it to get great value and usefulness from it.

Geoff successfully used this within the bank, and some quotes from management included:

    • “I didn't know I owned all of those apps”
    • “That's not one of mine!”
    • “I'll get the developer to check”
    • “Great, just what I wanted for the next release”
    • “How do I trigger a change to the list?”

Custom Fields/Columns

Consider the requirements for your

About the author

Brad Appleton's picture
Brad Appleton

Brad Appleton is a software CM/ALM solution architect and lean/agile development champion at a large telecommunications company. Currently he helps projects and teams adopt and apply lean/agile development and CM/ALM practices and tools. He is coauthor of the bookSoftware Configuration Management Patterns, a columnist in The CM Journal and The Agile Journal at CMCrossroads.com, and a former section editor for The C++ Report. You can read Brad's blog at blog.bradapp.net.

About the author

Steve Berczuk's picture
Steve Berczuk

Steve Berczuk is an engineer and ScrumMaster at Humedica where he's helping to build next-generation SaaS-based clinical informatics applications. The author of Software Configuration Management Patterns: Effective Teamwork, Practical Integration, he is a recognized expert in software configuration management and agile software development. Steve is passionate about helping teams work effectively to produce quality software. He has an M.S. in operations research from Stanford University and an S.B. in Electrical Engineering from MIT, and is a certified, practicing ScrumMaster. Contact Steve at steve@berczuk.com or visit berczuk.com and follow his blog at blog.berczuk.com.

About the author

Robert Cowham's picture
Robert Cowham

Robert Cowham has long been interested in software configuration management while retaining the attitude of a generalist with experience and skills in many aspects of software development. A regular presenter at conferences, he authored the Agile SCM column within the CM Journal together with Brad Appleton and Steve Berczuk. His day job is as Services Director for Square Mile Systems whose main focus is on skills and techniques for infrastructure configuration management and DCIM (Data Center Infrastructure Management) - applying configuration management principles to hardware documentation and implementation as well as mapping ITIL services to the underlying layers.