4

What is the best way to handle changes to product requirements or scope during or after User Acceptance Testing (UAT)? How dangerous is it to make those changes, and how can the danger be mitigated?

Improve this question
7
  • 2
    When you build a house, and you're almost finished, adding an extra powersocket requires you to break walls, redo the plaster and probably some more things. People understand that. Why won't they understand that changing software is often the same thing. Commented Jul 27, 2012 at 17:23
  • 2
    @PieterB - because they can't see the dust. Commented Jul 27, 2012 at 17:40
  • 2
    Nice rant... asking for a list of resources does not constitute an actual question for this site. If you have a legitimate question about the effects of last minute scope changes on a project then please post back. Commented Jul 27, 2012 at 17:53
  • I guess I should have been more clear. Sometimes having articles or numbers to quantify this helps people understand what seems to be common sense. Even if you get them to agree to another QA and UAT cycle, experience tells me that the testing teams rush through it because they are already frustrated and just want to get this over with. There must be some study on this. Commented Jul 27, 2012 at 23:56
  • @HackITMngr - I'm unclear on whether it's considered on-topic for the site to ask for references. I believe in general you have to simply ask the question directly, so I edited accordingly to get the question re-opened. I'm fairly sure it's O.K. to add something saying you would appreciate scientific studies, and you could edit again to add that. Though most people will probably read your comment anyway. Commented Jul 28, 2012 at 0:08

2 Answers 2

Reset to default
3

The scope can be changed at anytime, provided those changing accept the required changes to budget and schedule. You can't stop people from continually trying to change the scope until they realize it costs money, providing a few estimates of the cost for requested changes from higher-ups will help them make that connection. Doing this is unlikely to stop them from requesting changes, but it is likely to stop them from complaining when you deny those changes, and will help you identify the changes you need to make when they understand the cost of that change.

Improve this answer
10

I think the best way to deal with these change requests is to present a revised schedule including the change. And if it's after UAT, then the new schedule includes a second run through UAT.

When they go 'but we don't need that' you can ask why not? Doesn't the product need to be accepted by the user? If they haven't seen it, they can't accept it, right?

Improve this answer
2
  • I totally agree. Think 'backbone'. Commented Jul 27, 2012 at 17:16
  • +1 for "Doesn't the product need to be accepted by the user? If they haven't seen it, they can't accept it, right?" Commented Jul 27, 2012 at 17:46

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.