From the outset, let me make clear that I am not talking about a development process which is Agile or Scrum based (in the Scrum based methodology, features are taken up on the basis of a Sprint cycle, which means that features are taken up from cycle to cycle). Let us take the typical case on which a number of teams work, the Waterfall based development methodology. In this methodology, teams follow a sequential process whereby they start out with a requirements process, which is followed by a design process, which in turn is followed by a coding process mixed with a testing process. The process ensures that a phase is only started once the previous phase has been completed. So, if you consider this entire methodology, the requirements phase needs to come to an end before the design phase starts.
The direct implication of this is that once the requirements phase is completed, it is not expected that there will be a change in requirements. This is now considered to be a weakness in those situations where the requirements are in flux, but if you consider the industry where a software organization does projects for clients, the completion of the requirements phase is a critical stage. The clients typically use the entire requirements phase as a milestone which certifies that their business workflows have been captured accurately and increases the confidence level in the clients that the software mapping their business requirements will be designed accurately.
Now, look at software projects, and consider the case where after the completion of the requirements phase, there is a modification in some requirements or a new requirement that has been added. This new requirement could come in because some change in business workflows has happened, or a customer has added some new feature that is critical for success, or any other valid reason. Once such a change needs to happen, there needs to be a process to be followed to ensure that the team does not increase the level of risk beyond what has already been incurring. Typically, with a change in requirements, there is a risk of the schedule slipping, or the quality level suffering. It is better to take a hard look at the impact of such a change rather than do such a change under pressure, and then find that the software team comes under pressure later.
So what needs to be done ? Well, the group should do an impact analysis of the change before going ahead with the change. This is a process by itself that the team needs to do:
- Have a team of requirements folks to do a review of the change and estimate the change to the requirements already in place
- Work out the design changes or new design needed for this change / addition and the effort estimate
- Do the same estimation for the development or testing phase
Once you have these estimation in total, you know the approximate change to the schedule because of this change. Based on this estimation, the team needs to figure out whether there needs to be a reduction in the feature set to accommodate this change, or whether the number of resources deployed in the team need to be increased for taking this change. However, keep in mind that there will be a point in the schedule where such a change cannot be take just by increasing the number of resources; there will be an impact on the schedule.
The direct implication of this is that once the requirements phase is completed, it is not expected that there will be a change in requirements. This is now considered to be a weakness in those situations where the requirements are in flux, but if you consider the industry where a software organization does projects for clients, the completion of the requirements phase is a critical stage. The clients typically use the entire requirements phase as a milestone which certifies that their business workflows have been captured accurately and increases the confidence level in the clients that the software mapping their business requirements will be designed accurately.
Now, look at software projects, and consider the case where after the completion of the requirements phase, there is a modification in some requirements or a new requirement that has been added. This new requirement could come in because some change in business workflows has happened, or a customer has added some new feature that is critical for success, or any other valid reason. Once such a change needs to happen, there needs to be a process to be followed to ensure that the team does not increase the level of risk beyond what has already been incurring. Typically, with a change in requirements, there is a risk of the schedule slipping, or the quality level suffering. It is better to take a hard look at the impact of such a change rather than do such a change under pressure, and then find that the software team comes under pressure later.
So what needs to be done ? Well, the group should do an impact analysis of the change before going ahead with the change. This is a process by itself that the team needs to do:
- Have a team of requirements folks to do a review of the change and estimate the change to the requirements already in place
- Work out the design changes or new design needed for this change / addition and the effort estimate
- Do the same estimation for the development or testing phase
Once you have these estimation in total, you know the approximate change to the schedule because of this change. Based on this estimation, the team needs to figure out whether there needs to be a reduction in the feature set to accommodate this change, or whether the number of resources deployed in the team need to be increased for taking this change. However, keep in mind that there will be a point in the schedule where such a change cannot be take just by increasing the number of resources; there will be an impact on the schedule.
No comments:
Post a Comment