Introduction
With technological projects comes the trouble of inability to predict end requirements, time, cost, and understand what stakeholders truly desire. It is hard to predict end requirements, time, and cost because we have learned over the years that project management requires change throughout the life cycle because all the variation that happens throughout the process. This includes new technology being introduced, unforeseen problems, updated requirements, and more. This also requires constant back and forth communication with stakeholders as it can be difficult for the stakeholders to tell developers what they want in a product, or they see a prototype and realize new opportunities they have not thought of before. With all this unpredictability project teams must find a way to combat this and to make effective changes through the project life cycle.
As mentioned with software and technology, in general, it can be very hard or in most cases impossible to see what the final product will entail and what will change from the original project plan. This means that project teams needed to find a way to make changes in a quick, yet reliable, systematic fashion becoming what we call the change control system. A change control system is “formal, documented process that describes when and how official project documents may be changed” (Schwable). This offers a professional way to make decisions of change and implement them. The primary use of a change control system is to make sure that changes are not made on whim or not thought out. It makes sure that changes are carefully considered before being enacted. This allows for project teams to make corrections and adapt along the project process without make unnecessary changes that lead them astray and waste time and resources. Another great part of the change control system is how it is kept as documentation that can be later referenced whether it be on the same project if a conflict comes up or a later project to help decide the best course of action. It is common for these decisions to be made by a group of key stakeholders and experts in specific subject area.
Change Control Board
The group is commonly known as a change control board that works to make the decision of accepting or rejecting change for a project. The decision of the change control board is decided in two overarching steps. Those being, reviewing the proposed changes and the impact of that change, and then actually making the decision of accepting or rejecting the changes. Board meetings typically have a set schedule that works to the scope of the project whether that being something like each week or once a month. Many also offer the ability for a quicker response for smaller decisions, such as 48 hours. This allows for projects not to just have downtime where they are getting behind schedule since no decision has been made. These decisions are a major part of the success and efficiency of a project, and they should be documented as such, just like all parts of a project.
Documentation
The importance of documentation to projects is represented in change control with configuration management. Configuration management is used to identify and document the functional and physical characteristics of the product, the changes made, and make sure the product conforms to the requirements in place. This makes sure the project is on track with the requirements and the changes made to requirements. It also makes sure that the changes are documented, so the company and other stakeholders have it in writing about what the requirements are and they can be referenced as needed. This is typically a job specifically addressed to an individual that this is their main job reinforcing the importance of the job.
Importance
So now that we understand more about change control and the parts that are within it, what does all this mean? What is the benefit? As there are many moving parts in a project and many different groups of people interacting, communication is a major part of if the final product of a project is what is intended by stakeholders and the developers. Part of communication is identifying and making decisions on change between these stakeholders and developers. As we talked about before change is a necessity and because of this we need to work to make effective decisions on what changes to make to a project that will improve the final product. Change is something that people do not usually want to make, but with technological projects, such as software, it is something that must happen as there can be such variation from the beginning of the project to the end of the project. This includes everything from requirements from stakeholders, technology changing, changing needs, ignored requirements, and more. This means that as a team they must be able to adapt to these changes effectively and efficiently. This is where change control comes into play as it sets guidelines and a board of individuals to make these change decisions. Another important part is documentation as all projects need well written, professional documentation to have on record for project team members and stakeholders to have available. Having documentation of not only the original requirements, but also the change to the project allows for all team members to stay up-to-date or refresh their memory on what is expected from them throughout the project. In all the ability for a project team to make corrections with the help of change control is meant to reinforce the teams understanding and direct effort in the best way to accomplish what becomes the final product.
Agile
Change Management is traditionally used by waterfall approaches, but it can be used effectively within agile to help a project's success. The organization of change management is something that fits the style of waterfall better, but a team can work to adapt change management to fit their agile approach. Using change management within agile promotes consistent communication, both within the development team and the stakeholders and engagement of senior leaders. Change is something that is typical and often in agile meaning that the use of a change control board could have an adverse affect if not implemented well, but having a set, prompt response time can alleviate these issues.
References:
Schwalbe, K. (2019). Information technology project management (9th ed.). Cengage.
Why do my requirements keep changing? Requirements Experts | © 2009–2019, Requirements Experts, Inc. All Rights Reserved. (2016, April 5). Retrieved September 17, 2021, from https://reqexperts.com/2013/03/26/why-do-my-requirements-keep-changing/.
Change management meets agile, how does that work? and Change. (2021, July 8). Retrieved October 27, 2021, from https://www.andchange.com/themes/change-management-meets-agile/.
Comments