Has anyone successfully crafted a project proposal / contract, whereby the testing timeframes are specifically limited?
For Lump Sum (FFP) proposal contracts, are you typically limiting the amount of time that a client has to test and accept a new software application? If so, what is a reasonable amount of time? Or are you managing this risk in other ways?
One client in particular is insisting that they should not be limited to a specific amount of time - that if they find a defect at any point after the software is delivered, that it should be our financial responsibility to address it. I'm looking for input on what is reasonable in the software development industry. Saving Changes...
It all depends on how you set up your contract and statement of work.
I usually start by building some functional testing into my scope to be completed by the project team before the software is provided to the client for acceptance testing.
You then have to discuss with the client if they will create their acceptance test cases or if they want to build them from yours. My preference is to let them do their own as it builds ownership as well as providing better testing coverage.
When it comes to acceptance testing, I usually go with at least two rounds of it. Each round includes acceptance testing by the client, testing support by the project team, and some allowance for rework. My first round is usually longer than the second.
The trick with client testing is to give them a period of time to do it in, for example 4 weeks. It is up to the client to recruit a sufficient amount of people to do the testing during that period. If the client decides to extend the duration of a testing round, you need to start talking change request with your client. Because your fixed price is based on a fixed scope, making the acceptance testing longer adds, at the very least, additional testing support.
In your scope statement, you should have negotiated what will represent completed acceptance testing. I usually do that by stating something like "all critical and important defects are fixed". The trick here is you need to define what critical and important means. Then you and the client review all defects and only assign them to the category if they meet the previously agreed definitions.
Now comes the hard part: providing support after going live. You have two choices. The first one - the one I prefer - is to make post-go live support time and material, rather than fixed price. The second one is to give your client a set number of support hours. For example, you can say that you will build in your project exactly 80 hours of post-go live support. The problem with this is that you need to have an operational agreement in place to pick up where your project ends.
Your contract or scope statement must clearly define each parties responsibilities beyond the project in terms of defects. You may wish to give them a set period guarantee beyond the project. Just make sure it's built into your price.
You should offer your client purchasable warranty or support options. If you do, be clear what are each other's responsibilities. For example, you allow a client to report a defect. You may do the triage to figure out if the problem is in your delivered product. If so, you may suggest that the fix will provided in the next product release. Of course, you can negotiate all kinds of permutations of responsibilities. Just make sure to price them accordingly. Saving Changes...
Normally UAT has 1-2 rounds from the client side. First should be to uncover any missed defects, 2nd to have final testing. The cost of this if lies on your side then it should be calculated in CoQ (cost of quality). Also, known risks should be updated for this to have proper cost to cover.
So, if you want to save the cost for client found defects and sign the contract then requirements and quality management should be done well. Saving Changes...
No. Eager to know how it works in product companies. Saving Changes...