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








