Change Management Is Essential to the Building Processes


In his CM: the Next Generation series, Joe Farah gives us a glimpse into the trends that CM experts will need to tackle and master based upon industry trends and future technology challenges.

Change requests are quite different from changes and should not be used as a change container. A change request might be implemented in several changes across several releases. Or multiple change requests might be addressed by a change. The originator, or requestor, of a change request communicates the request to the product team, which ensures that it has a proper understanding of the request. Once this handoff occurs and the product team accepts the change request, it is treated as a requirement. The originator will want to know when the request will be/has been implemented and when it will be delivered. The originator is responsible for closing the request (i.e., indicating that the implementation meets the criteria of the request).

Builds as the Key Reference Points
Where does the build come into play? It must be possible to take any build and identify which requests of a particular originator (or group of originators) have been met by that build. On the flip side, that leaves the set that is outstanding. If your CM traceability cannot give you this information, you need to improve your data and processes. Ideally, this information should be available at the click of a button (or at least a simple report request panel).

When this loop is closed, your builds are more than just a set of executables. They become the key reference points for communicating with your customers:

·         What release is the customer running?

·         What requests are still outstanding for that customer?

·         What requests are addressed by the next release that weren't previously addressed?

·         What problems have been fixed in the new release that were not fixed in the customer's current release?

About the author

Joe Farah's picture Joe Farah

Joe Farah is the President and CEO of Neuma Technology and is a regular contributor to the CM Journal. Prior to co-founding Neuma in 1990 and directing the development of CM+, Joe was Director of Software Architecture and Technology at Mitel, and in the 1970s a Development Manager at Nortel (Bell-Northern Research) where he developed the Program Library System (PLS) still heavily in use by Nortel's largest projects. A software developer since the late 1960s, Joe holds a B.A.Sc. degree in Engineering Science from the University of Toronto. You can contact Joe at

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!