Rework and Scope Management

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.