BVOP™ Certified Project Manager
BVOP is a modern organization that created the certification program for Project Manager, which follows its new management methodology.
Create an account on the BVOP.org platform to receive a promotional discount code. Certification exams are fully online.
The cost of the certification exam is $ 55 if you have a promo code. So hurry up and register on BVOP.org
Change Control and Configuration management is a very important activity in Project Management practices today.
The information presented in the article is validated against the PM.MBA requirements for transparency in project management academic publications.
When you have completed this chapter you should be able to demonstrate an understanding of the following:
- the reasons for change control and configuration management;
- change control procedures (from monitoring and controlling in project management practices):
- the role of the change control board;
- the generation, evaluation, and authorization of change requests;
- configuration management:
- purpose and procedures;
- the identification of configuration items;
- product baselines;
- the content and use of configuration management databases.
Introduction to Change control management in project management
Business changes have many implications outside the narrow confines of IT development, including their impact on an organisation’s staffing levels, skills and responsibilities. Change management is concerned with the smooth transition of the organization to the new system that a project delivers. The Water Holiday Company integration project will create new software, change existing software and expand IT infrastructure.
These are technical changes, but the integration project will also require changes to the way the merged business will be run.The particular focus in this chapter, however, is on the events during a project that result in alterations to project requirements. The project manager’s skill lies in controlling those changes so that minimal disruption is caused to the planned objectives of time, cost and quality. Change control management ensures that modifications to any aspect of the project are only accepted after a formal review of their impact upon the project and its environment. The procedures for managing change should be established at the beginning of the project.
The planned functionality to be implemented may be modified during the project as the needs of the users and the business are clarified. These changes need to be tracked through a change control system. If outside contractors are carrying out some of the work, the need for a change control system is even greater. New IT systems usually need to be integrated with existing operational systems, and this may require modifications to these legacy systems so that they can communicate with the new functionality created by the project. The changes to these existing systems need particular care to ensure existing operations are not degraded. Changes are part of the entire project life cycle in the project management area.
Allowances need to be made within the project plans for the possibility of additional work caused by requested changes. These allowances could be part of the tolerances delegated to the project manager. The project manager ensures that these allowances are not exceeded. Where they are exceeded, a new project plan would need to be drafted and approved by the project sponsors. Agile management practices have a different approach to change management. They focus on short-term periods and the risk in long-term initiatives is minimized. All stated practices here are related to waterfall project management processes.
Change control, at some level, should be applied to all changes, whether they arise from a change to user requirements or are due to design modifications. It requires participation by the users and the developers, guided by the project manager. The users must judge whether a change is essential, desirable or optional. This decision takes account of the possible impact of the change as well as of not making it. The project manager must assess the technical feasibility of the change, and identify its impact on costs, time and quality. Once account has been taken of users’ and developers’ advice, if it is decided to go ahead with the change, it is the responsibility of the project manager to implement the change.
DEFINITION OF CHANGE IN PROJECT MANAGEMENT
In Chapters 2 and 3, we introduced the idea of the project as a sequence of activities, each of which takes certain inputs and uses them to produce outputs. The outputs from one process may be inputs to others. Thus, a specification could be an input to a process that creates a system design (that is, the format of the user interfaces with the system) which will then be implemented as code.
During the process, the proposed interface designs may change rapidly as the designers try out different designs and the users give feedback on them. This does not need a formal change process. At some point, however, a decision needs to be taken that the design is now in a satisfactory state for constructing the system. At this point, the design will need to be frozen; in other words, the design is baselined. If changes are needed to the design after it has been baselined, then rigorous change control is needed because of their potential impact on the processes that use the design.
The idea of baselines was introduced in Chapter 3 with regard to project plans. A baseline plan may be regarded as an agreed plan against which variations will be measured. Any change to requirements could imply a potential change to the baselined plan. For projects, the baselines include the agreed scope and quality of work, schedule, and costs. Project Management Academy teaches these practices to be more optimized and shortened.
As noted in Chapter 3, these will tend to be interdependent. For example, if the scope of the work is expanded, then the cost will be increased. Similarly, cost or scheduled duration could be reduced by decreasing the functionality delivered. Variations on these baselines can be categorised as follows.
Changes of scope and Development changes
Changes of scope: These generally originate outside the project, usually by the users, managers or project sponsors changing the requirements, or by the cost or time constraints of the project changing. In the case of the Water Holiday Company integration scenario, the users may, for example, add a requirement that when booking a boat online the client should also be able to purchase holiday insurance. On the other hand, a reduction in the project budget may mean that some planned system features are dropped.
Development changes: These originate within the project and include changes that are routinely carried out as part of the normal process of developing and refining a product. Typically, this can be something as simple as an adjustment to a screen layout.
Faults: This type of variation also originates within the project and is caused by the project team making errors. For example, misunderstood requirements in coding detected by system tests could lead to additional corrective work. Some discretion will be exercised in accepting or rejecting scope and development changes but changes to correct design errors will normally be obligatory, since the system may not work satisfactorily unless they are corrected.
In order to encourage the UK boating holiday industry, the government decides that VAT on canal holiday bookings will be zero-rated with immediate effect. The management of the Water Holiday Company calculates that this could increase the demand for bookings by 30 percent. At the same time, the government introduces a special tax on holiday insurance that has to be accounted for separately on invoices. When considering the implications of changes, the project team realize that although holiday insurance was included in the original requirement, it has been missed out from the system design. What effect might these changes have on the project?
CHANGE CONTROL ROLES AND RESPONSIBILITIES
It is important to clarify the various roles and responsibilities in change control. We are going to use a very specific set of terms here to identify and explain the various roles and responsibilities. In a real project environment, it is very unlikely that these precise terms will be used. However, there should be people who carry out the following roles, whatever they may be called.
The project manager oversees the process and ensures that all requests for change (RFCs) are handled appropriately. In most cases, the project manager also has the role of the change manager. Project managers must ensure that user representatives approve any changes made to the project requirements. They also control the scope of the system to be developed: additional features will require more effort and increase costs. When the project sponsor agrees to additional features, adjustments may need to be made to the project’s contractual price. The certified project manager also needs to be on the lookout for informal changes made outside the process. Informal changes are often discovered during project reviews and a retrospective RFC form may need to be completed so that records remain accurate.
The change requestor recognizes a need for a change to the project
The change requestor recognizes a need for a change to the project and formally communicates this requirement to the change manager by completing the RFC form.
The change manager (who may be the project manager) is responsible for logging RFCs in the change register. They decide whether a feasibility study is required for the change. Where this is desirable, for example, because the extent of the impact of the change is uncertain, one or more people will be assigned to carry out the study.
The change feasibility group appointed above investigates the feasibility of a proposed change. It is responsible for researching how the change may be implemented and assessing the costs, benefits, and impact of each option. Its findings are documented in a feasibility study report.
The change control board (CCB)
The change control board (CCB) (often consists of business stakeholders) decides whether to accept or reject the RFC forwarded by the change manager. The CCB is responsible for:
- reviewing all RFCs forwarded by the change manager;
- approving or rejecting each RFC based on its merits;
- resolving change conflict, where several changes overlap;
- resolving problems that may arise from any change;
- approving the change implementation timetable.
A change implementation group carries out the change. It is usually made up of staff from the project team.
Sample short change management plan
Change management plan
Any change request must be recorded and submitted in the form of a written form, which is pre-set and approved.
The change request can be submitted by a project manager or a position that has a higher level of interest.
The criticality of the change request will be determined by how the request for change affects the already agreed budget, time for implementation of the whole project, scope, and most of all not to reduce the quality of the final product.
If a change has a direct impact and drastically changes the budget, the deadline, the scope, and the quality of the final result, then it cannot be considered as a change, but a revision of the project and its start from the beginning. However, if the change modifies one of the 4 points, this change request will be forwarded to the responsible departments, affecting the need for change for analysis and testing.
A change will be considered urgent if it is not specified in advance in the scope, the topic and is close to the pre-set parameters, but is not yet a legal analysis or action plan for such a case.
All changes must have physically visible or practically applicable benefits.
The approval of the change is done by the main sponsor of the project or the project director.
Planning for change can only be done after the departments affected by the change have performed the necessary tests and simulations. This process requires a certain amount of technical time and no immediate response can be given to the customer as to whether this change can be applied or not.
When all the necessary tests and simulations are completed. The client will receive an offer on how the change can be implemented, how much it will cost as a financial and time resource, only if the change can be implemented. However, before this response is sent to the client, the client will always be informed that his application has been accepted and is being considered by the necessary units.
Expected feedback from the customer must be returned within 7 working days.