Introduction
This article is a follow up of the earlier one related to the project management processes for an automation tool. This tool is to be used for automating the processes of a maintenance project in a software company.
Rework
A rework can arise due to:
Change in scope
Quality of the deliverables not up to the mark
Change in requirements that is essentially a change in scope
Change in Scope
Rework arising due to change in scope means that the project baseline has to be modified and corresponding changes made to the project management plan, resource plan, schedule plan etc.
Any change in scope affects not only the schedule but the cost as well. So, a proper scope change mechanism would take into account the effect to the schedule as well as the costs associated in carrying out the same.
Considering the scenario where 20 percent of the rework has to be done in the context of the automation tool it means that:
New features have to be added to the tool
And new requirements have to be taken into account
There are two aspects of scope management. One is preventive in nature and the other is corrective actions. Rework due to the new requirements falls into the corrective category and a formal change request has to be raised that takes into account the various parameters like changes to the cost and the time.
Rework due to Quality
This is also known as defective repair. In the context of the automation tool, it would mean that the deliverables have not been found satisfactory during testing. The rework has to be fit into the existing schedule as the project charter specifies timely delivery and hence any change to the schedule would involve changes to the cost of the project.
Integrated Change Control
Any change requests should go in through an integrated change management system. All the corrective, preventive and defect repairs are covered here. Any change to the project management plan is covered here.
The following steps have to be taken to accommodate the 20 percent change in the scope
All the stakeholders have to be informed about how the change would affect the cost, time, risk and other project objectives including quality
All the change requests have to be categorized as corrective or preventive and suitable action recommended
Some of the changes can be rejected if found not feasible from a technical or a functional standpoint
The proposed changes have to fit within the reason the project was initiated. This means that the overall project objectives and the purpose cannot be lost because of some rework.
Do a root cause analysis and find out whether any further changes can be avoided
The project management plan has to be updated
The change control board has to be constituted and made functional
All the changes to the deliverables have to be reviewed
The configuration management should be followed in terms of using the correct versions of the components of the project management plan and are being updated in a controlled fashion
Update the project baselines
Update the project management plan
In addition, the project manager has to make sure that:
The final requirements are obtained as soon as possible
The risks are identified upfront
Institute a process to control changes
Roles and responsibilities of the team members are defined
The business case has to be re-evaluated if the changes are excessive
Allow only change control requests that are approved by the change control board
If the changes are excessive and would deviate from the overall project objectives, terminate the existing project and start a new one.
Conclusion
The one overriding priority is to ensure that the customer’s requests are met without compromising on the internal stakeholders needs. A fine balance has to be struck between the objectives of the internal and the external stakeholders.
