Change in IT projects' life cycle is inevitable. This points at the importance of establishing means to identify, control and document change in a formal approach. There will be changes in Technology, resources and organizational priorities. Equally important is change requests that initiates from the customer/user. In my experience with software development, these change requests comes in the form of additional features/functionalities, enhancements requests or bugs reported. In my current workplace, such change requests are very crucial since the products developed are very customer oriented. The need for an integrated change control system is very crucial in this case due to quick expected turn around times.
Added complexity is to manage change when changes happen (more than once) during the various phases of requirements analysis, design, coding, testing and post deployment - Questions asked could be : How do you manage change to code that already went to production system? How do you track the life cycle of a change request, since a change request usually lead to a sub-project for applying that change? How do you report status on these change requests to the stakeholders? What roles each project team member should play while dealing with various phases of change control process ? How well can we improve response times to change requests by using automated Change control systems? How do you integrate Version control system with the Change control system? and so on ...
All these questions points at importance of creating an integrated CCP whose motto is simple - identify, request, recommend alternative, approve/reject changes so that each phase is well tracked and in synch. with the version control system and that all change action status is reported to the stakeholders.
Additional suggestions for ICCP: However I may add that the CCB (Change Control Board)'s frequency of meetings will depend upon the organization's code release cycle policy. For eg: If the organization releases only one code change per quarter, then there is only need to have one CCB meeting per quarter (there are companies who still do this in the insurance sector). Whereas, in the case of a budding web-based application which is very customer oriented and uses prototype based development, then it is advisable to have at least 2 CCB meetings per week (so that code changes get promoted to production twice a week). Many companies follow this policy so that customer oriented change requests are well taken care of.
Added complexity is to manage change when changes happen (more than once) during the various phases of requirements analysis, design, coding, testing and post deployment - Questions asked could be : How do you manage change to code that already went to production system? How do you track the life cycle of a change request, since a change request usually lead to a sub-project for applying that change? How do you report status on these change requests to the stakeholders? What roles each project team member should play while dealing with various phases of change control process ? How well can we improve response times to change requests by using automated Change control systems? How do you integrate Version control system with the Change control system? and so on ...
All these questions points at importance of creating an integrated CCP whose motto is simple - identify, request, recommend alternative, approve/reject changes so that each phase is well tracked and in synch. with the version control system and that all change action status is reported to the stakeholders.
Additional suggestions for ICCP: However I may add that the CCB (Change Control Board)'s frequency of meetings will depend upon the organization's code release cycle policy. For eg: If the organization releases only one code change per quarter, then there is only need to have one CCB meeting per quarter (there are companies who still do this in the insurance sector). Whereas, in the case of a budding web-based application which is very customer oriented and uses prototype based development, then it is advisable to have at least 2 CCB meetings per week (so that code changes get promoted to production twice a week). Many companies follow this policy so that customer oriented change requests are well taken care of.