Hcfyk

My client wants to squeeze UAT into 6 working days from originally planned 10 working days. This is because they want to go live because of an impending business reason. As a risk mitigation strategy I have proposed for 4 weeks of hypercare instead of general 2 weeks. I have also proposed for complete execution of UAT scripts within first 3 days of UAT and then to retest the defects along with the second iteration of execution in remaining 3 days. How else can I mitigate this risk?

“It is a capital mistake to theorize before one has data. Insensibly one begins to twist facts to suit theories, instead of theories to suit facts. Sherlock Holmes

A logical corollary is that it is a capital mistake to devise risk mitigation strategies before stating a risk. There is no risk in your question. Your client wants to compress UAT. Before mitigating the risk, I would advise you precisely state the risk.

• What is it that you are uncertain about?


• What are the potential consequences (good or bad)?


• How likely is it that the consequences will happen? Do you have data to estimate? Can you get data?

Why is this important? Why am I being so rigid & formulaic about this? Because the client has a business need to go live faster than the schedule permits. My job as a PM is to advise the client - in order to do that, I need to know the relative value of the business need and the risk(s). I can't mitigate what I don't understand.

Based on the information you've presented, I would infer the presence of several risks.

Given that all code is buggy and we're compressing UAT

1. IF there exists an important bug THEN internal users will have a reduced user experience. It may take longer to complete the task, or increase frustration. This can be managed with additional support.




2. IF there is an important bug, THEN internal users may make errors in completing their task; this might cost the company money, clients, and completely undermine the business value of the advanced start.




3. IF there is an important bug that affects external users, THEN external users may be so dismayed that they will go elsewhere, irreversibly damaging the company's reputation and ability to attract customers.

There are a few more - based on information that isn't presented in the question. But breaking the risks down this way gives me more mitigation strategies

• Can I roll out the live site to a small set of cooperative/expert users first? Treat weak 1 as an extended UAT? Make sure the users have the knowledge and the contact information needed to quickly correct errors?




• Can I maintain both interfaces for a period of time and switch high value/high risk/ customers to the old, migrating the friendlier, more experienced users to the new?




• Can I maintain both for a period and run high risk interactions on the old, and low risk on the new?




• What is the failback strategy? If on day Live +1, I discover a bug that has a million dollar implication to the company, how quickly can I revert back to prevent a second million dollar loss?

SomeAdd questions that I'd want to research before talking to my client

• In UAT, historically, what % of the bugs are found in week 1, week 2, etc. Is it a long tail curve? What is the estimated probability that the compressed UAT period will actually uncover/resolve bugs? There is a big difference between a 1% chance of losing a million dollars of business and a 10% chance of losing a million dollars of business.

Addendum - thank you for this question - it has clarified some of my thoughts. I've suspected for a while that the value of risk management is more the discussion of risk than the actual measurement of risk. This question has enabled me to restate that idea

The better you understand the risk, the more options you have to respond to it profitably. Discussion of risk, formal statements, of risk, etc. These are all ways to better understand and share knowledge of risk.

There is not silver bullet to mitigate skimping on quality assurance. I don't know in what field you are in, but what you can do depends on what the cost is to deploy a new version to your users.

Generally speaking, you do the same post launch care you would do anyway. You must remember that mean time to recovery is your key metric and since you know that QA was shortened, you should plan for an above average defect rate. This means you need to have your engineers at the ready to get fixes out. So in your case, having more people available may be a better thing than a longer care period. (If that is even possible.)

Further, in my experience, the key determining factor in QA is the test - fix - retest loop and no mater of automation is going to reduce the manual step of analyzing and fixing the defect. You are primarily removing time to fix the defects, not reducing testing.

Mark provided a great answer, especially the lead in where he asks what is the risk? Reducing duration on an effort would signal a risk in most cases to most of us, I would suspect, but I think Mark's thinking is spot on because mitigation would be driven off the fact of your risk exposure caused by the reduction of days and where the original duration was when planned, i.e., did you estimate on the fat side of the curve for UAT originally.

That being said, assuming you've taken on additional risk exposure secondary to the reduction of duration, add UAT testers and developers to fix the findings if you can afford to pay for them. Else, you are in contingency mode. The extra weeks in hypercare are appropriate, increasing communications to leadership about the imminent number of defects that will be found after go live would be appropriate, a planned exit strategy where you can roll it back would be appropriate, communications to the user community about what they might see and what to do about it would be appropriate.

You might want to consider prioritising the features you test.

By restricting your testing to the most important features you may be able to get a more thorough test-fix-retest cycle in within the aloted time.

The chances of bugs reaching production will likely increase, but the likelihood of high impact bugs is hopefully reduced.