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
Table of Contents
Get a FREE Trial for the BVOP Project Management Certification Exam
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.
Activity
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.
Here is my short sample Change Management Plan.
Changes on the part of the client.
The changes should be requested with a pre-set form, which should be filled in only by the client’s project manager. In the event of his impossibility, he has the right to authorize his direct deputy.
Only with his signature and validation is any change accepted and considered.
The form is sent entirely and exclusively by e-mail, and the e-mail does not have to be from the manager himself. It could be from the secretariat.
After receiving the form, it is forwarded to the project manager, who has 2 days to review it and forward it to the program manager. He, in turn, must provide it to a member of the committee or the director and the principal investor. The whole procedure should not take more than 3 working days.
Once the proposal is approved or rejected, it is returned by the same email. A confirmation response is expected within a maximum of 2 business days.
Only then can our teams start working on the relevant changes.
Team changes.
Changes are announced by email, which is reviewed by the project manager.
In case of small and non-striking changes, the project manager is authorized to decide at the moment. In case of medium and large changes, he consults with the program manager and assesses the situation. In the event of large-scale changes, a member of the committee or director is consulted and must discuss it with the client.
The procedure should not take more than 2 working days.
The same form is used.
Changes by the committee/board of directors.
The changes are discussed first with the project manager and then with the client.
Only then are the sponsors consulted.
The same form is used.
Program changes.
They are discussed between project and program managers. In case of large discrepancies, the director or a member of the committee shall also be consulted.
Another example from me:
Definition of change:
change the scope of the project. This includes changes related to the design, prototype, technical workmanship, software
out-of-scope change including product design, marketing activities, product-related design and printing, legal research
budget and time changes
How the project changes will be introduced
the accepted changes will be reflected electronically through the internal company system
Rights to request a change
the contracting authority will be the following members: project sponsor, project director, or project manager
the contractor will be the following members: the project director or the project manager
Rights to consider a request for change
only by the contractor – the project manager and the functional manager
Criticality criteria
Criteria for the impact of the request for change
related to the budget (increase in prices, losses; optimization, profit)
related to the team (demotivation; motivation; bonuses)
related to the schedule (delay, delay; improvement)
Criteria for the urgency of the request
depending on the impact of the request
potentially strong negative impact on the project
potentially strong positive impact on the project
related to the budget – when an immediate change is required, whether positive or negative
related to the main idea of the product – change of functionality, design, software
Criteria for evaluating the benefits of the request
increase profits
the strong motivation of employees
optimizing the working time of the teams
innovation
Change approval process
upon receipt of a request for change, it will first be considered by the Project Manager
upon his approval, the functional manager will be consulted
upon approval by the functional manager, the project manager will submit the request to the project director
upon approval by the project director according to the different scenarios, the request may be submitted to the project sponsor, it is possible to stop by the project director.
in case the request for change will not affect the scope of the project, the Request can be accepted by the functional manager and sometimes by the project manager
Planning
Depending on the impact of the request, as well as the members affected by it, the response time may take several hours or several weeks.
in the event of a heavy-duty request on the project, the teams carefully analyze the problem, test the solution and provide a response to the client when this request will have a positive impact.
upon request with great weight on the project and negative impact, the teams carefully analyze the problem, test solutions, and respond to the client. This can be either a denial of the requestor an offer of an intermediate/temporary/permanent/different solution to the problem.
upon acceptance of a change request, data on possible changes in the parameters of the Scope – the resources of the contracting authority must be provided.
after the contracting authority has approved the request with a possible decision on the changes, it is obliged to provide consent or disagreement with these changes.
in case of disagreement on the part of the assignor, he is obliged to submit another request for change in the project
with the consent of the contracting authority, the contractor proceeds to change the schedules, plans, teams, and everything related to the impact of the request.
Change approval process
A change request can be initiated by the Project Manager on the client’s side or the Project Manager on the contractor’s side.
In both cases, this is done formally.
When the request is initiated by the client, it should describe in detail the requested change in the scope of the project, the reason for the change, expected effect, priority and desired implementation period.
The project manager on the contractor’s side accepts the request and specifies with the client the possible response time, then evaluates the impact of the change and possible other alternatives using the Change Request Form approved for the purpose.
After a detailed description and discussion of the options with the team, the change request form is submitted for approval to the Project Steering Committee.
Escalation of key issues and implementation of approved changes/corrective and preventive measures.
Upon approval, the Project Manager re-plans the project (or the affected part of it) and the final description is formally confirmed by the Project Steering Committee. If necessary, the agreed changes are formalized with an annex to the contract with the client.