1. Introduction
This article provides an overview of the importance of maintaining a change log in project management. Embraces a discussion of an important kind of requirement related to this philosophy: the Change Log. During the project changes, it is known that 50% to 60% of the effort would be spent on changes. Thus, the management of the project relies heavily on the support of change-tracking mechanisms. In fact, the change-tracking system can be seen as a tool for synchronizing knowledge between developers. A change log is a record made of all changes that are performed in a project. This log can be informative about the events and discussions in the development effort. It can also be used as a data source to infer some strategies and training for a project or software activity in general. With the change log, it is possible to understand and reason about the changes. The change log is considered an important requirement, although it usually is not described in the usual project documents. The purpose of this paper is to increase the awareness of the need to register and retrieve changes in the project by dealing with some aspects that are usually not considered during the project specification phase. (Chetty et al.2020)
2. Importance of Change Logs in Project Management
The reasons for changes in the project can be from the oversight entities, the project staff, or the unexpected. Changes from the oversight entities come from their recommendations, adjustment in project scope, redirected project objective, and temporary or permanent exclusion of a project staff member from the project. The latter case is always associated with a creative effort on solutions to the problem or with communication among the involved parties.
Records on project changes become important in project management, particularly in the implementation phase. Records on project changes are usually called a change log, or sometimes called the change register. Records on changes become important when the project’s content, the time to complete the project, the project cost, or the relationship among these three become uncertain. Frequently, a project is implemented to solve a long-term problem. The approach to the problem set by the project manager may be subjected to change along the direction since progress toward solving the problem is often unclear. Oversight entities such as a steering committee, project sponsor, clients, vendors, and the project staff may request or make changes in the project. When the changes are not made, oversight entities or the project staff may need to update their expectations from the project. (Love & Ika, 2022)
3. Components of an Effective Change Log
Indication of type: Reference ‘Coders Complete’ document discerning the general type of type: 1 – Feature; 2 – Bug Fix; 3 – Organizational Role Change (i.e., change to mail, phone number, extension list, etc.); 4 – Minor Change (added alerts, changed output, refusing, etc.); 5 – Fallback Mechanism (there is no public interface change for the change, but it is a sensible area to add a rollback to); 6 – Reverse Action (i.e. Data purging); 7 – Trigger Static Data Change.
System reference: Changes to the same system are often connected in some way, either as mutual preconditions, or relationships from programming connections or conflicts to client reliance upon code logic. The math still needs consideration of all such relationships.
Task or reference: An identifier or reference in the system area Change is submitted to, this is necessary for anything the change opposes or revises. It may include an itemized list of change-specific functional requirements or test cases.
Data column: This includes the date change was made, assignees, status, descriptions, and an area for comments.
Getting all of the details necessary for an effective change log requires coordination between project management and quality-independent testing. Here are some important components of an effective change log. Not all will be obvious from the start, but this is a good starting list. (Shastri et al., 2021)(Tidd & Bessant, 2020)
4. Best Practices for Maintaining a Change Log
First and foremost, high discipline is required to capture all changes regardless of impact – cost, value, time, and defect. In fact, including the cost of the change is sometimes the sole justification for including it because of the project manager’s constant struggle to capture all changes. The change log is regularly used by the project manager to control creeping scope and cost. Claims for missed requirements and gold-plating that cannot be shown to relate to items in the change log represent extra scope that should be managed by the project manager through the change-approval process.
If you want to capture changes consistently and make your project history useful, here are some best practices to follow. These best practices are generally described from the viewpoint of the project manager but apply to anyone managing parts of the project as well. They should be applied to the change log, risk log, and any other place you are recording changes and their impact on the project as well.
5. Tools and Technologies for Automated Change Log Management
A final issue relates to how the change log may be expanded to capture changes representative of the other four views – the high-level requirements specification, low-level design, detailed code, and test artifacts. For all five views, we want to identify artifacts that require explanations, the specific issues that need to be captured to help stakeholders manage changes, and a way to identify changes that require inclusion in the log. While these questions require further research, the generated change log needs to be consistent with the other views to support a consistent and integrated change management and traceability capabilities.
The change log presented in this research is based on the manual summarization of changes of interest to the project. An interesting venue for further research is to either partially automate the identification of changes of interest and/or the summarization of the detailed changes into higher level, change log entries. Automated techniques would be particularly useful for projects that are stored in version control systems that allow automated gathering of the repository history to locate specific changes. Current systems have limited understanding of the scope and depth of each change, relying on the commit message and the change itself to identify what types of changes occurred in the code. Also, the overly sparse use of version control systems leaves regular deliverables out of reach for these techniques. At a minimum, an analyst would have to be able to infer requirements deliverables from other sources, as was done in the manual change log generation described in this chapter. (Bhandari et al.2020)
References:
- Chetty, R., Friedman, J. N., Hendren, N., Stepner, M., & The Opportunity Insights Team. (2020). How did COVID-19 and stabilization policies affect spending and employment? A new real-time economic tracker based on private sector data (Vol. 91, pp. 1689-1699). Cambridge, MA: National Bureau of Economic Research. includere.co
- Love, P. E. D. & Ika, L. A. (2022). Making sense of hospital project misperformance: Over budget, late, time and time again—Why? And what can be done about it?. Engineering. sciencedirect.com
- Shastri, Y., Hoda, R., & Amor, R. (2021). The role of the project manager in agile software development projects. Journal of Systems and Software. [HTML]
- Tidd, J. & Bessant, J. R. (2020). Managing innovation: integrating technological, market and organizational change. [HTML]
- Bhandari, M., Gour, P., Ashfaq, A., Liu, P., & Neubig, G. (2020). Re-evaluating evaluation in text summarization. arXiv preprint arXiv:2010.07100. [PDF]
