Preventing deviation between requirement and implementation
Alok KumarDelivery Manager| Virtusa Consulting Pvt LtdMn, United States
My Dev team has mis-interpreted the requirement and now this has been found out in UAT phase.
1. What checks I can put in place to avoid such re-occurance in next project.
2. What corrective measure I can take now to mitigate impact on cost and schedule Saving Changes...
This is a very common issue - a variance between "what the customer wanted" and "what the team built".
By the book, if it is clear it is a miss on the dev team's part, then you can't charge the customer for fixing the issue and your team would have to absorb the impacts. However, if doing so means a critical deadline would be missed, you will want to come up with a recommendation that can still meet the date. This might mean crashing your schedule or other techniques to do "more" in the same amount of elapsed time.
As far as prevention goes, you need to look at your requirements management process as elicitation and analysis steps might not be appropriate for the nature of the project. This may also drive exploration of an adaptive lifecycle assuming close collaboration is possible with your customer.
Kiron Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
This is the holly grail. That´s is because some approaches has been created like Lean or Agile and some methods like Spiral, JAD, etc mainly in the field of software but extended to non-software products from long time ago. Additional to that the business analyst role has been created for that. So, my recommendation, is going to PMI´s Business Analysis for Practiotioners Guide where you can find lot of good practices and practical adavaices to do that. Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Hi Alok,
yes this is common.
Basically, reviewing the requirements by people outside the dev team can mitigate the risk. If you have a test team, or a quality control team they could do that. Similar to using XP. Customers mostly do not have the technical understanding to identify misinterpretations. In a project I used function points to review requirements with excellent results. If possible if you can develop incrementally, e.g. with Scrum, you will develop and verify requirements as they prioritized by the customer, if they are willing to participate as Kiron says.
Often the set of requirements is not consistent too, so the dev team identifies the gaps or contradictions late. In this case you may argue that it’s not only the fault of the dev team but by whoever compiled requirements. Prototyping can mitigate this.
There are many ways to adapt the dev process to mitigate the risk of faulty requirements. Saving Changes...
I have found that the involvement of a BA in the requirements gathering phase helps with these kinds of projects. They are good at interpreting various requirements "languages". Saving Changes...
Alok KumarDelivery Manager| Virtusa Consulting Pvt LtdMn, United States
Thanks everyone for your valuable input ! Saving Changes...
The best answer is not to do phased delivery; do iterative and continuous delivery. UAT should be done from the beginning and throughout.
...
1 reply by Adrian Carlogea
Mar 28, 2020 7:35 AM
Adrian Carlogea
...
Hi David,
This is not always possible.
When you are delivering/developing a brand new system or you are doing a major change to an existing one you must deploy into production all the work in a single go otherwise it would make no sense for the users. Completing all the functionality could take months or years.
The above is always true when you are migrating a legacy software to a newer one. You can't deploy the new software until all the functionality has been completed and the users can do with it at least everything they were able to do with the old one.
You could theoretically present to the users all the functionality you have developed so far on a regular basis at short time intervals but most of the times the customer may not have enough resources to commit for this exercise.
Also many users would want to be able to do a big chunk of their work while testing and not test just very small peaces of functionality.
In conclusion UAT is here to stay as it is for many cases and even if you want to change this your customer may not accept it.
The best answer is not to do phased delivery; do iterative and continuous delivery. UAT should be done from the beginning and throughout.
Hi David,
This is not always possible.
When you are delivering/developing a brand new system or you are doing a major change to an existing one you must deploy into production all the work in a single go otherwise it would make no sense for the users. Completing all the functionality could take months or years.
The above is always true when you are migrating a legacy software to a newer one. You can't deploy the new software until all the functionality has been completed and the users can do with it at least everything they were able to do with the old one.
You could theoretically present to the users all the functionality you have developed so far on a regular basis at short time intervals but most of the times the customer may not have enough resources to commit for this exercise.
Also many users would want to be able to do a big chunk of their work while testing and not test just very small peaces of functionality.
In conclusion UAT is here to stay as it is for many cases and even if you want to change this your customer may not accept it.
...
1 reply by David Portas
Mar 28, 2020 1:24 PM
David Portas
...
UAT is inherently an iterative process of testing, releasing and testing again. Brand new systems are usually best delivered iteratively in my experience but you are right to single out migrations as especially tricky in this respect. Nevertheless there are solutions. Automated testing plays a big part of course but the aim should always be to start UAT as early as possible. Earlier testing with a representative user group invariably means less testing, less disruption and potentially earlier go live. I don't believe there are any exceptions to this but anyway it's not a risk I would want to take.
When engaged in the right way, users are often more willing to help than they are given credit for by IT teams. The one thing guaranteed to lose their trust and support is a flawed "big bang" release that hurts their productivity.
When you are delivering/developing a brand new system or you are doing a major change to an existing one you must deploy into production all the work in a single go otherwise it would make no sense for the users. Completing all the functionality could take months or years.
The above is always true when you are migrating a legacy software to a newer one. You can't deploy the new software until all the functionality has been completed and the users can do with it at least everything they were able to do with the old one.
You could theoretically present to the users all the functionality you have developed so far on a regular basis at short time intervals but most of the times the customer may not have enough resources to commit for this exercise.
Also many users would want to be able to do a big chunk of their work while testing and not test just very small peaces of functionality.
In conclusion UAT is here to stay as it is for many cases and even if you want to change this your customer may not accept it.
UAT is inherently an iterative process of testing, releasing and testing again. Brand new systems are usually best delivered iteratively in my experience but you are right to single out migrations as especially tricky in this respect. Nevertheless there are solutions. Automated testing plays a big part of course but the aim should always be to start UAT as early as possible. Earlier testing with a representative user group invariably means less testing, less disruption and potentially earlier go live. I don't believe there are any exceptions to this but anyway it's not a risk I would want to take.
When engaged in the right way, users are often more willing to help than they are given credit for by IT teams. The one thing guaranteed to lose their trust and support is a flawed "big bang" release that hurts their productivity. Saving Changes...
