The phrase "Requirements change" is sometimes abused by IT people. What we are describing is indeed change of requirements but this may be because one or more of the following (I don't know enough about these cases, so the following may or may not apply):
1) Management's ambition to make the end user happy as quickly as possible and show quick progress.
2) Lack of detailed analysis. Remember that Analysts need to ask questions about why not only what. The analysts needs to "think" with the end user about a "solution" not only take orders.
3) Lack of a formal process for requirements verification and confirmation, followed by approval.
4) Asking the incorrect person to perform one or more roles they are not necessarily trained for such as Business Analyst or Systems Analyst roles.
5) Limited prototyping.
6) Client not clear about the technicalities and its limitation. They expect to get all whether the thing is technically feasible or not. This cause long discussion sessions which cause change in requirement and the project to delay.
Client should have technical team or atleast a technical person to analyse requirements before delivering this to their vendors.
6) The assumption/fear that it has to be done quickly and if not its IT to blame.
Unless one addresses all of the above properly, the relationship between IT and the business/end user will be stressful. These does not imply that the above point are conclusive. There are other factors also that leads to stressful situations.
1) Management's ambition to make the end user happy as quickly as possible and show quick progress.
2) Lack of detailed analysis. Remember that Analysts need to ask questions about why not only what. The analysts needs to "think" with the end user about a "solution" not only take orders.
3) Lack of a formal process for requirements verification and confirmation, followed by approval.
4) Asking the incorrect person to perform one or more roles they are not necessarily trained for such as Business Analyst or Systems Analyst roles.
5) Limited prototyping.
6) Client not clear about the technicalities and its limitation. They expect to get all whether the thing is technically feasible or not. This cause long discussion sessions which cause change in requirement and the project to delay.
Client should have technical team or atleast a technical person to analyse requirements before delivering this to their vendors.
6) The assumption/fear that it has to be done quickly and if not its IT to blame.
Unless one addresses all of the above properly, the relationship between IT and the business/end user will be stressful. These does not imply that the above point are conclusive. There are other factors also that leads to stressful situations.
No comments:
Post a Comment