We have all been struggling in eliciting requirements that stay invariant from users and if not in all in most cases, we have had a variety of mechaisms from DFDs to Use Cases for the user to verify that the requirements have been captured accurately and completely. However, there is always a gap is what is in the users mind and what is put on paper. We expect the user to sign off hundreds of pages requirements and carve them in stone. IMHO getting requirements down is like writing an instruction manual on how to swim or bicycle or walk. We know how to do it but we cannot describe it so that a person by following the description will be able to swim, ride a bicycle or walk. A user makes a decision, after experience, during a business process automatically, he does not refer to a procedure manual which tells him the exact way a decision is to be made with a long nested if then else. If the user is unaware on how to make a decision as a new situation has come, he just asks a more experienced person who is around. I think we have unreasonable expectations that the user should be able to speak out all the possible permutations and combinations which is required to create a system and hold a Change Request against his head.
We need to accept that getting 100 percent of requirements down to the minutest detail is not paossible and stop holding Cahnge Requests on the Users Temple
Subscribe to:
Post Comments (Atom)
3 comments:
RL:"...I think we have unreasonable expectations that the user should be able to speak out all the possible permutations and combinations which is required to create a system..."
...but don't we have business analysts and domain experts for that? Of course we CANNOT expect the user to provide anything more than their basic requirement in the first interaction.
As a Business Analyst or a Consultant i'd make sure that the client expectations are set appropriately regarding what has been mutually understood regarding their basic requirement in the first meeting(s) with the client's Operations Heads.
The clients Technical team also plays significant role especially when it comes to Business Intelligence and Data Warehousing.
What follows is a cycle of iterative communications of feedbacks from the development team and the client's Operations team.
The most important thing here is to actually conduct these sessions on priority basis on both sides and to "document" our understandings, identified business cases and parameters - a simple spreadsheet will suffice for the documentation - documenting is important.
During this phase it is expected from the clients that not only their Operations' Heads but also their experienced core users are involved in putting forth their analysis requirements - this is crucial for avoiding change requests.
And during this phase it is expected from the vendor's team comprising of BAs, Consultants, DBAs and Technical Experts to work in unison and put forth their valuable views about the "Design" of the system.
Of course the domain experts can add tremendous value to these discussions and the system as a whole which also conveys to the client that we understand them.
Such focussed preparation led by experts on both sides will definitely direct the efforts in the right direction.
And ofcourse we know that a strong motivator in both teams is a must for sustainance of such exercises.
So both sides are now ready for the exchange of views during the feedback sessions in the wake of the communication cycle.
These sessions must be conducted prior to the development - and also during mid-project reviews.
These two "iterative" phases of "Discovery"(25%) and "Design"(25%) comprise 50% of the system creation.
Development, lead by and supported by skilled experts, would comprise the next 25% *** and "Deployment", following a pre-planned deployment strategy, would comprise the next 25%.
Again, "Communication" is the key for the success of the system.
Thank you for reading.
Regards,
-Harshad M.K.
RL:"...I think we have unreasonable expectations that the user should be able to speak out all the possible permutations and combinations which is required to create a system..."
...but don't we have business analysts and domain experts for that? Of course we CANNOT expect the user to provide anything more than their basic requirement in the first interaction.
As a Business Analyst or a Consultant i'd make sure that the client expectations are set appropriately regarding what has been mutually understood regarding their basic requirement in the first meeting(s) with the client's Operations Heads.
The clients Technical team also plays significant role especially when it comes to Business Intelligence and Data Warehousing.
What follows is a cycle of iterative communications of feedbacks from the development team and the client's Operations team.
The most important thing here is to actually conduct these sessions on priority basis on both sides and to "document" our understandings, identified business cases and parameters - a simple spreadsheet will suffice for the documentation - documenting is important.
During this phase it is expected from the clients that not only their Operations' Heads but also their experienced core users are involved in putting forth their analysis requirements - this is crucial for avoiding change requests.
And during this phase it is expected from the vendor's team comprising of BAs, Consultants, DBAs and Technical Experts to work in unison and put forth their valuable views about the "Design" of the system.
Of course the domain experts can add tremendous value to these discussions and the system as a whole which also conveys to the client that we understand them.
Such focussed preparation led by experts on both sides will definitely direct the efforts in the right direction.
And ofcourse we know that a strong motivator in both teams is a must for sustainance of such exercises.
So both sides are now ready for the exchange of views during the feedback sessions in the wake of the communication cycle.
These sessions must be conducted prior to the development - and also during mid-project reviews.
These two "iterative" phases of "Discovery"(25%) and "Design"(25%) comprise 50% of the system creation.
Development, lead by and supported by skilled experts, would comprise the next 25% *** and "Deployment", following a pre-planned deployment strategy, would comprise the next 25%.
Again, "Communication" is the key for the success of the system.
Thank you for reading.
Regards,
-Harshad M.K.
RL:"...I think we have unreasonable expectations that the user should be able to speak out all the possible permutations and combinations which is required to create a system..."
...but don't we have business analysts and domain experts for that? Of course we CANNOT expect the user to provide anything more than their basic requirement in the first interaction.
As a Business Analyst or a Consultant i'd make sure that the client expectations are set appropriately regarding what has been mutually understood regarding their basic requirement in the first meeting(s) with the client's Operations Heads.
The clients Technical team also plays significant role especially when it comes to Business Intelligence and Data Warehousing.
What follows is a cycle of iterative communications of feedbacks from the development team and the client's Operations team.
The most important thing here is to actually conduct these sessions on priority basis on both sides and to "document" our understandings, identified business cases and parameters - a simple spreadsheet will suffice for the documentation - documenting is important.
During this phase it is expected from the clients that not only their Operations' Heads but also their experienced core users are involved in putting forth their analysis requirements - this is crucial for avoiding change requests.
And during this phase it is expected from the vendor's team comprising of BAs, Consultants, DBAs and Technical Experts to work in unison and put forth their valuable views about the "Design" of the system.
Of course the domain experts can add tremendous value to these discussions and the system as a whole which also conveys to the client that we understand them.
Such focussed preparation led by experts on both sides will definitely direct the efforts in the right direction.
And ofcourse we know that a strong motivator in both teams is a must for sustainance of such exercises.
So both sides are now ready for the exchange of views during the feedback sessions in the wake of the communication cycle.
These sessions must be conducted prior to the development - and also during mid-project reviews.
These two "iterative" phases of "Discovery"(25%) and "Design"(25%) comprise 50% of the system creation.
Development, lead by and supported by skilled experts, would comprise the next 25% *** and "Deployment", following a pre-planned deployment strategy, would comprise the next 25%.
Again, "Communication" is the key for the success of the system.
Thank you for reading.
Regards,
-Harshad M.K.
Post a Comment