A Target Approach for who should Manage Change

[article]

personnel so that an appropriate level of impact analysis can occur prior to a change.  Assessment of impact may be incorrect if the incorrect level of personnel is performing the assessment.    

Combining the Attributes

Once you have identified the baseline stream in question and the target level within the organization, then a determination of who should be key CCB members can be considered.  It should be noted that there are numerous important members of a CCB and the table below attempts only to identify key CCB members.  Each CCB should have members that allow for a robust discussion of each change.  

What must be noted is that there may be more than one level of CCB for a baseline stream.  For example, there may exist a level-1 CCB that focuses on the specific set of requirements for a project and a level-2 CCB that focuses on all requirements across all projects that are related to an application.  This way the level-2 CCB assesses the impact of requirements that may affect several concurrent projects that are related to the application, while the level-2 CCB assess only the impact to that specific project.    

  • Below are some examples of assessing the baseline stream with a target level to identify the key CCB members.

Baseline Stream 

Target Level

Key CCB Members 

 

 

 

Requirements 

Project

Project Manager and key Project personnel.  If a requirements change may affect a different yet current project or subsequent projects, then chair of this CCB should raise awareness of these changes to the Application level CCB.     

Requirements

Application

Application Owner and Project Manager.  This CCB assesses changes to requirements on all related projects.  The Project Manager must ensure they communicate any requirements changes from the application level to their project level CCB (should one exist) if the requirements affect the project.    

Requirements

Applications (this may be a program or release package made up of several applications)

Release Manager (assuming there is someone assigned to manage the incoming project level release pieces from the different applications), Application Owners and Project Managers (for each project release that makes up the program release package).  This ensures all potential impacts of the change are considered across the program release).  Project Managers must ensure they communicate any requirements changes from the application level to their project level CCB (should one exist) if the requirements affect the project.  

Environment

Application

Environment Manager, Application Owner, Project Manager(s), SCM Manager, Test Manager.  Application Owner and Environment Manager should ensure they communicate the changes to all personnel working on the application prior to making the change.  

Environment

Applications

Environment Manager, Application Owners, Project Managers, SCM Manager(s), Test Manager(s).   Application Owners and Environment Manager should ensure they communicate the changes to all personnel working on the applications prior to making the change.  

Policy

Project  

Project Manager and key Project personnel. The change should be communicated to all project personnel working on the applications prior to making the change.

Policy

Application  

Application Owner and Project Manager(s).  The change should be communicated to all application personnel working on the applications prior to making the change. The Project Manager(s) should communicate any application level policy changes to their project personnel.  

Policy

Organization

Senior Management and Compliance (may involve several groups such as QA, Audit, etc.).  The change should be communicated to all organizational personnel prior to making the change and the change should be incorporated into the compliance and verification and validation processes.  

Production 

Project/Application

Application Owner, Project Manager and key Project personnel.  Since a project creates a set of deliverables that affect the running application

About the author

Mario  Moreira's picture Mario Moreira

<strong>Mario Moreira</strong> is a Columnist for the CM Journal, a writer for the Agile Journal, an Author, an Agile and CM expert for CA, and has worked in the CM field since 1986 and in the Agile field since 1998. He has experience with numerous CM technologies and processes and has implemented CM on over 150 applications/products, which include establishing global SCM infrastructures. He is a certified ScrumMaster in the Agile arena having implemented Scrum and XP practices. He holds an MA in Mass Communication with an emphasis on communication technologies. Mario also brings years of Project Management, Software Quality Assurance, Requirement Management, facilitation, and team building skills and experience. Mario is the author of a new book entitled “<strong><a href="http://www.amazon.com/dp/0470746637?tag=cmf06-20&amp;camp=213761&amp;cre... Configuration Management for Agile Teams</a></strong>” (via Wiley Publishing). It provides an Agile Primer and a CM Primer, and how to adapt CM practices for Agile Teams. Mario is also the author of the CM book entitled, “<strong><a href="http://www.amazon.com/Software-Configuration-Management-Implementation-R... Configuration Management Implementation Roadmap.</a></strong>” It includes step-by-step guidance for implementing SCM at the organization, application, and project level with numerous examples. Also consider visiting Mario’s blog on CM for Agile and Agile adoption at <a href="http://cmforagile.blogspot.com/">http://cmforagile.blogspot.com/</a>.
&nbsp;

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

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

Upcoming Events

Oct 12
Oct 15
Nov 09
Nov 09