Warranty periods
After any major change or release it's custom to have a period of warranty. This is a time of heightened support where any issues found in live (as opposed to minor issues found by QA and accepted into live) get fixed by the project team. Any costs are also absorbed by the project.
Just like a warranty on a product you might purchase, such as a TV for example, if anything goes wrong within a period of time after the purchase, the supplier guarantees it will be fixed at no charge.
Unlike a purchase warranty, the warranty period for a project change may only last two weeks. For that reason, you really need to kick the tyres before letting the project team move on to the next big thing. Will every scenario be played out in that period of time? e.g. a month-end processing run or the busiest day of the month.
Think ahead, and if the warranty period doesn't cover these days, ask for it to be included (within reasonable means of the project of course).
If you don't find any issues during the warranty period you risk finding them later (of course) but if they're not service impacting then they'll probably end up on a backlog behind all the other higher priority issues that you missed. So use the time wisely and make sure all your stakeholders have an input into the warranty process.
- Previous: Awesome Tools - PageSpeed Insights
- Next: Handovers
