1

This is a regular waterfall project. Due to some top management stack holders from both sides vendor and client (I am on vendor side), They both force on starting UAT as soon as possible, even with in complete tested work. By in complete, I mean: it is developed and unit testing/system testing is good. But the integration for some tasks is not completed to UAT server (around 50%). Why work is not completed: Mainly due missing one dependency access the client/us still working on and it is still delayed. This is blocking testing for those. So do you think starting with such situation is a risk? (Honestly I see it is). Even completed tasks can't be 100% verified, it is around 80% until we have this dependency server access.

So now I have to proposals on the table:

  1. start UAT with 50% quality, and by mid of UAT (UAT is 2 months), we should get the dependency ready. So remaining work will be done in parallel with UAT(it is an extra headache for team).
  2. Postpone UAT, for like 1 month and wait until it is completed.

I prefer 2nd option, but I would like to know your feedback, since stackholders, is really pushing on start and say that they understand, and we should not lose more time and try to make use of this period and close some work.and show top management some progress.

As a backup plan, internally, I started already to completed some of the work without this dependency access, but this came with a price of extra effort, but this we are doing to get more confidence about the results.

Improve this question

4 Answers 4

Reset to default
3

Since UAT is, by definition, a user and/or customer-driven process, you would have to work directly with the user(s) and/or customer(s) performing the UAT to understand the benefits and risks of performing a UAT with some desired work still incomplete.

The decision may depend on the architecture of the system. If the integration work is sufficiently isolated from the other functionality and it is possible to use the other functionality without the integrations in place, then perhaps the UAT can start on what is done. Even if, for some reason, it can't be a "formal" UAT, having an opportunity to start early can provide the development teams with additional feedback prior to the "formal" UAT when everything is finished.

If the work to be integrated and the "completed" work is more tightly coupled and it's likely that the "completed" work will need additional modification, then it's not likely that a "formal" UAT and acceptance can happen. However, the early feedback could be valuable. It could also be an opportunity for the people performing the UAT to get comfortable with the system and start to practice or dry run the UAT steps that they can complete so the actual UAT can be completed quickly and efficiently.

My preference would be to try to get the people performing the UAT involved earlier, even if that's practicing or dry running pieces of the UAT and giving feedback to the development teams.

Improve this answer
3
  • I see your point is more productive and I hope to go for this, but I have one more point I didn't mention, that I have lack of resources, and they are only 2 ppl working although they should be 4 at least. So to do some debt backlog from integration + do UAT, I am not sure the capacity will allow. However, long time ago, I worked with one PM who had similar situation, and he started UAT with only 60% completed, UAT turned to be 3 months rather than 1 month. Which I think it was a win. Because he did both backlog/new work at same time. But it was clear that he was not ready to start UAT.
    – amr007
    Oct 14, 2022 at 10:41
  • Cont . And customer was complaining off course, but he did! And on management side that were happy to complete their own KPIs.. but staff team who will use the product was in a nightmare.
    – amr007
    Oct 14, 2022 at 10:47
  • @amr007 Your people don't do UAT. If they are working on the backlog, they probably aren't representative users who can perform UAT.
    – Thomas Owens ♦
    Oct 14, 2022 at 22:26
1

Of course it is not going to be "waterfall", as your question indicates. Waterfall software development is virtually a myth because under modern conditions it is hard or impossible to achieve a predictive, strictly phased delivery with software of any complexity. It's even harder to justify such a thing in commercial terms.

My advice would be to start UAT as soon as possible. The fact that both vendor and client realise the phased waterfall-style delivery is not feasible is to everyone's advantage. The key thing is how you manage UAT. Make sure the priority finished things are tested and unfinished lesser priority things are not, and work on responding to defects and customer feedback. Assuming you will create a prioritised list (a backlog in other words) those backlog items will need to be worked in alongside the rest of development work. Iterative/continuous delivery, frequent customer collaboration and backlog prioritisation are essential to making that work.

Improve this answer
1
  • 1
    Waterfall software development is virtually a myth... and also a mistake!
    – Bogdan
    Oct 15, 2022 at 19:18
1

If you plan to arrange UATs for every meaningful increment, it means that your project is not a waterfall one anymore; it becomes an agile project.

UAT is the abbreviation of "User Acceptance Test". UAT's are for acceptance, not to come up with changes. Since uncompleted work can not be accepted, it is not possible to let the customers or other stakeholders do the UATs before the development is complete.

Improve this answer
0

In my view, if the client wishes to assume the risk of having a ton of additional UAT findings on defects that would have likely been mitigated if UAT was postponed, that's on your client; however, these defects and the extra, concurrent work you described will very likely increase your costs, as the vendor, to deliver. This, in my view, should require a change order so that those extra costs, plus fee, are paid.

Improve this answer
4
  • Agree. But top management speaking: on my side is fine with that( saying that it won't go that bad, and it should be finished more quickly than postponing) because if UAT will start on time, then some work should be closed from the backlog.
    – amr007
    Oct 12, 2022 at 19:38
  • Both sides are only interested in showing progress. And my management doesn't see huge extra effort. (Although it will be)
    – amr007
    Oct 12, 2022 at 19:39
  • That's too bad. Document the risks clearly and unemotionally as you see them and then execute as instructed.
    – David Espina
    Oct 12, 2022 at 19:50
  • I wouldn't say "extra effort" is necessarily the case. Delaying testing usually increases costs and the relationship is far from linear because of the "compound interest" effect of that debt of untested work. Also from a customer engagement point-of-view any kind of UAT is superior to none. It isn't real for the customer until they get their hands on it - only then will you hear what they truly think.
    – nvogel
    Oct 12, 2022 at 20:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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