2

In most of my projects, execution and testing goes pretty much in line, but as soon as client starts testing, we get delays in project and it gets delayed by almost 40% of entire project schedule. The major causes being

  1. Slow responses from client
  2. Small requests to make some modifications (If I prepare final list, clients keep adding to it indefinitely)
  3. Training and support

How do I make sure that the user acceptance completes as per the schedule and within the budgets

Improve this question
2
  • Slow response from the client, to what? what are you asking the clients at this stage? Also, training and support in respect of what? Training usually comes before UAT for the users that need it and support and detailed training of the user base usually comes after UAT...
    – Marv Mills
    Feb 5, 2015 at 12:49
  • Slow responses for any issue fixes or Modifications. Training to make sure that the end users understand the platform and are comfortable using it.
    – user2656082
    Feb 5, 2015 at 12:52

2 Answers 2

Reset to default
2

UAT can be tricky because you are asking users to spend some time away from their day job doing testing for you. Users don't tend to give this activity a very high priority and you will always struggle to get time from them. It is counter-intuitive to us as project deliverers, but it is natural to the users. The first thing you have to do is accept that is the norm and then devise ways to work around it:

  1. Plan the UAT as robustly as you would plan the system testing. Plan for test/fix/redeploy cycles and fix them in time and duration (as much as you are ever able to do this).

  2. Publish the plans to the users early and meet with them often to get and then then retain their commitment. Ensure you include in these commitments the people that arrange the working time for the users because they will listen to requests from them over and above any from you!

  3. Include in the plan some time to train the UAT testers on the system so that they know how to test it. That should happen before the actual testing.

  4. Agree test-exit criteria and ensure the users know that you will move out of testing on agreed dates if the number and type of UAT issues raised is below this level.

  5. Make sure that everyone knows that you cannot accept change requests at the UAT stage. Not now. Not ever. If users raise something that simply must be done then the project comes out of UAT and back into development. Users cannot test something to accept it for Live and simultaneously make go-live a condition of some new development. That is scope change control pure and simple.

  6. Arrange for user training to happen after the product has been signed off (and regression tested) and before it goes live. It should NOT go live at the point UAT signs off

  7. Plan for service and business-readiness throughout the project, not just at the end. You should know in advance what you need to do in terms of engaging and handing over to support well before UAT commences. Get everything ready and then follow the process, whilst admitting to yourself that the business and support have basic needs from you and the project before they can take on the live commitment. This is entirely natural and you need to make it happen.

Good luck!

Improve this answer
2
  • 1
    Exactly what I was looking for Mr. Mills. Thanks a lot! That helps
    – user2656082
    Feb 6, 2015 at 7:11
  • Thanks. Glad to be of help. The usual etiquette is to mark your favoured answer as "the" answer and/or upvote it. Thanks.
    – Marv Mills
    Feb 6, 2015 at 9:02
0

The easy way is to account for the risk of cost overruns due to things like this in the contract with your client. Some examples:

  • In a firm fixed price contract scenario cost for how long UAT/sign-off takes on the typical project.
  • In a time & materials contract you could bill by the calendar day or calendar week.

You can similarly dis-incent them from making modifications to scope by providing them with an estimate of revised cost and time if you were to proceed, and insist on a contract amendment before you do the work. This requires well defined scope up front, but having that is a best practice in any case

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.