Ding! Project Manager Advances to Next Level
It was an extra-long mentoring session. The project manager (PM) had some genuine concerns she wanted to explore.
“Based on my experience with this client, I really think they will need three rounds of User Acceptance Testing (UAT) before they will be able to fully test and be comfortable with the vendor’s system,” the project manager said. “But I’m getting lots of pressure to compress the schedule and the execs are looking hard at the number of UAT cycles as an opportunity to compress the schedule.”
“What do you imagine will happen if you reduce the schedule to two cycles?” I asked.
“The client has higher priorities than this project, which results in challenges providing the needed resources. I’ve worked with this client before and this is a recurring problem. If client teams don’t show up to thoroughly test the system, I’m concerned that we will discover significant errors when we go live that may slow or even sabotage system acceptance.”
“So how are you communicating that to the execs?” I asked.
“That’s what I wanted to talk with you about. Should I ‘stand my ground’ in the interests of a successful project? You always say, ‘let the sponsors decide’.”
I told her, “What I care about most is informed decision-making. You need to figure out how to communicate your concerns without being adversarial. You will always lose a contest of wills with the project sponsor. Give them a choice. Frame it as a risk—what are the advantages, disadvantages, and risks of having only two UAT cycles?”
“The advantage might be a reduction in overall project duration, but the disadvantage is we would have less time to discover errors or quality issues with the system that the vendor is providing. The risk is that significant errors discovered after we move into production could threaten system acceptance and overall project success.”
In my mind, I couldn’t help but imagine the “ding” of the project manager leveling up. “What might you propose to address the risk? How could you reduce the probability, impact, and difficulty of detecting that risk in a timely fashion?”
“Well clearly, I think an additional testing cycle reduces the probability. Alternatively, we could try to encourage the client to provide the needed resources to thoroughly test in two cycles. We might be able to reduce the impact with a communication campaign to the user community to be patient with us for the first two weeks in production. We might also reduce the impact by having a larger team available after going live to fight fires and fix errors found promptly. Not sure what we could do to detect quality errors sooner—that’s the point of UAT.”
“So now it’s a matter of how you communicate this to the execs,” I told her.
“I see where you are going with this. Let them know that the three UAT cycles are based on my experience with the client having other priorities and not sufficiently staffing UAT in the past. I assume we need three cycles. They can choose to address this with client exec staff or not. If the client indeed cannot fully staff the UAT then it raises a risk of quality issues getting into production before they are detected which could negatively impact client perceptions of the system. My recommendation is three cycles to address this risk.”
“Excellent, you recommend, and the sponsor(s) decide.” I smiled.
There wasn’t a fanfare or a dazzle of lights that surrounded her as she put those pieces together, but I’m pretty sure she went up at least one level during that conversation. Gratz!
