Month: May 2022

Project change control

It is very rare to define the entire project up front. There might be outside forces that affect the project during it lifetime. Therefore, change is part of the project. It is important to have a process in place that is agreed upon by the client.

Change control is the management of anything that was not in the original scope, requirements, schedule or cost estimates of the project. It involves updating and maintaining the project documents and the resulting changes to quality, risk, cost, schedule etc.
It includes: adding new requirements based on new functionality that is needed. Deleting requirements of features that have been canceled. Schedule changes, fixing errors in the baseline documents.
This can affect the project cost, schedule, requirements documents, risk management, quality management etc.

Submitting a change is done using the ‘Change request’ form. It could be done on paper, digital document or using a software form, that is part of the control management system.

A change request should follow a mini-requirements creating process and go through the stages that were described earlier.

The change request should contain the complete snapshot of the change. It should include the description of the change, the reason for the change, and an explanation of the benefits to be received from the change.

The change request should be sent to the development team for analysis, time and cost estimation and design. It should also be passed to all other stakeholder that might be impacted by this change.

When the process is done, it is very important to update the requirements documents with the changes and notify the teams about the change.

The change-control process
A change-control process lets the project’s leaders make informed business decisions that will provide the greatest customer and business value while controlling the product’s life cycle costs. The process lets you track the status of all proposed changes, and it helps ensure that suggested changes aren’t lost or overlooked. Once you have baselined your requirements, follow this process for all proposed changes to that baseline.

• All requirements changes should follow the process. If a change request is not submitted in accordance with the process, it won’t be considered.
• On design or implementation work shall be performed on unapproved changes.
• Simply requesting a change doesn’t guarantee that it will be made. The project change control board will decide which changes to implement.
• The contents of change database shall be visible to all project stakeholders.
• The original text of a change should not be modified or deleted.
• Impact analysis should be performed for every change.
• Every incorporated requirement change shall be traceable to an approved change request.

There should be a defined team that is responsible to review and approve or decline change requests.
A change request passes through a defined life cycle, having a different status at each stage in its life.

There should be a procedure, known to all, on how to submit a change request.
Once a change request has been submitted, it is evaluated for technical feasibility and alignment with the project’s business requirements and resource constraints.
The appropriate decision makers approve or reject the request change. Once approved, the change request is assigned with a priority level and target date. It is added to the work schedule and assigned to a developer. They approval team notifies the team members who might be involved or needed to modify work products. Affected work products could include the requirements documentation, design description and models, user interface components, code, test documentation, help screens, and user manuals.
Change request form
• Change origin – the person who asked for the change.
• Change request ID
• Change type: defect, enhancement, feature, requirement change.
• Date submitted
• Date updated
• Description – description of the change being requested.
• Priority – the priority in which the change should be implemented. Determined by the change board: low, medium, high, critical.
• Assigned to – the person who is mainly responsible for implementing the change.
• Originator priority – the relative importance of making the change from the originator point of view: low, medium, high, critical.
• Planned release – product release for which an approved change is scheduled.
• Project/product – name of the project in which the change is being requested.
• Feature – name of the feature for which the change is being requested.
• Response – free text of responses made to the change request. Multiple responses could be made overtime (message board).
• Title – the one line summary of the change.
• Status – the current status of the change request.
• Verifier – the name of the person who is responsible for determining whether the change was made correctly (test).

The requirements, documentation process. Isn’t just about writing and recording information. You also have to review the requirements. Anytime someone other than the author of a software requirements, document examines the product for problems. A peer review takes place. Reviewing requirements. Documents is a powerful technique for identifying ambiguous or unverifiable requirements. You can also detect bugs in the design. During the review process, before they’re developed, it costs five times more to fix a bug at the development stage than in the requirement stage.
There are both formal and informal types of reviews. The informal types include a peer desk check where you ask a colleague to look over your work product, a pass around where you invite several coworkers to look at the document at the same time and a walkthrough where you describe the document and ask for comments on it.
A formal peer review on the other hand follows a well defined process. A formal review produces a report that identifies the material, the reviewers in the review team’s judgment as to whether the product is acceptable. The review produces a summary of the defects found and the members of a formal review share responsibility for the quality of the review.
Digging deeper into the review process gets us to the inspection process. Any software work product can be inspected, including requirements and design documents, source code, test documentation, and project plans. Inspection is a well defined multi-stage process that involves a small team of trained participants who carefully examine a work product for defects and improvements. Participants in the inspection should represent four objectives. The author of the work product, the author of any predecessor work product or specification for the item being inspected. The people who are responsible for work products that interface with the item being inspected. And finally, the people who do work based on the item being inspected, such as a developer, a tester or a project manager, we recommend limiting the team to no more than six participants.
There are four major roles in the inspection process. The author creates or maintains the work product being inspected. The moderator serves as the inspection leader, planning the inspection with the author, coordinating activities and running the inspection meetings. The reader paraphrases the SRS one requirement at a time with the other participants then pointing out potential defects and issues by stating the requirements in her own words, the reader provides an interpretation that might differ from that held by the other inspectors. The final role is the recorder who uses an issue tracking software to document the issue raised. And the defects found during inspection meetings.
The inspection happens in stages, starting with the planning phase, when the author and moderator plan the inspection together, deciding who should participate, what materials the inspectors will need to receive before the inspection meeting and how many meetings they’ll need to cover the material.
The next stage is the overview meeting in which the author describes the background of the material that will be inspected.
The preparation stage happens prior to the inspection meeting and it involves each inspector examining the product to identify possible defects and issues that should be raised up to 75% of defects are found during this phase. So keep a sharp eye.
Then it’s time for the inspection meeting. During this meeting, the reader leads the other inspectors through the SRS, describing one requirement at a time in his own words, the inspectors bring a possible defects and the other issues while the recorder captures them on a form that becomes the action item list for the author. The purpose of the meeting is to identify as many major defects in the document as possible. The meeting shouldn’t last more than two hours, but if you need more time, schedule another meeting at the end of the meeting, the team will decide whether to accept the requirements document as is accept the minor revisions or indicate that major revisions are needed.
The rework stage is where the author spends time reworking the requirements after the inspection meeting and follow up is the final step in which the moderator works with the author to ensure that all open issues have been resolved and errors have been corrected. The entire process ends when all of the issues raised during the inspection have been addressed or any changes in the document have been correctly made, or when the document has been checked into the project’s configuration management system
To help inspectors look for typical kinds of errors in the products that they inspect, develop a defect checklist for each type of requirements, document. This draws the inspector’s attention to historically frequent problems.
There are a lot of challenges associated with requirements review, and fortunately our program will help make the process much easier. There are a few tips we’d like to pass along to you though, to help you with other aspects of the process. For instance, we know that large requirements documents like a several hundred page SRS document can be seriously daunting. So to avoid overwhelming the inspection team, try performing incremental reviews throughout the requirements development, identify high risk areas that need a careful look and use informal reviews for less risky material, definitely consider using several small teams to inspect different portions of the material. Also establish several small teams to inspect the SRS in parallel and combine their defect lists.
And even if you have a long list of potential participants for requirements inspections, try not to let your inspection team get too large because that complicates things like scheduling meetings and reaching agreement on issues. Make certain that every participant is there to find defects, not to be educated or to protect a political position. Also, we recommend that you decline the participation of people who duplicate a perspective that’s already covered.