Software developers expect the business sponsor of a technology project to grant them reasonable access to the business team. In the early project phases requests for access may be frequent and inconvenient but they are tolerated. Things tend to quieten down during the implementation phase and the disruptive nature of this cross team collaboration is all but forgotten. Until it’s time to conduct the User Acceptance Testing (UAT).
Protect your team’s capability
UAT can place a significant burden on a business team and it has the ability to disrupt workflows or jeopardize service levels. No manager, wants to been seen as obstructive or unhelpful, but if the profile of their team is raised due to under-performance morale will suffer. Looking beyond the team under-performance can have serious implications for the wider organisation in the form of financial penalties, damage to reputation, etc..
In some circumstances it may be possible to avoid the difficulties associated with performing UAT through delegation. However, where the team has specialist knowledge or expertise that must be employed during the testing effort delegation may offer only partial relief even where its use is considered to be appropriate. Where UAT cannot be avoided the manager must seek to reduce its burden in order to mitigate the risk that it poses to the team’s performance.
Limit the scope of change
Performing UAT on a complex or sizeable application is challenging. By limiting the scope of the testing effort it should be possible to reduce its impact on team performance. I’m not advocating the adoption of some selective testing strategy as this will expose to criticism should defects in the application be discovered post delivery. Instead the objective should be to have a predictable flow of bite-size features that can be tested in isolation. Thereby enabling them to be scheduled alongside the team’s day-to-day responsibilities.
Be proactive
Seize the initiative at the earliest possible opportunity. Make sure that the project risk register includes the impact of UAT on your teams targets and performance. If possible stipulate an acceptable testing strategy at the project’s inception. The objective is to identify all of the UAT requirements and have them formally acknowledged in the project plan. Doing so makes it harder for others to make political gains should things start to fall behind as a result of supporting the UAT effort.
Advertise your team’s capacity
Avoid making any commitment to testing during busy times and holiday periods. Don’t assume the Technology team are aware of your particular circumstances. Make your constraints are known and ensure that they are recorded in the project plan. This will force the project team to focus on the UAT resourcing concerns early enough to make changes to the schedule possible.
Keep your eye on the ball
Try to attend all of the project update meetings and do take the time to read the emails and other project communications. You will be surprised at the number of problems that you are able catch by being in the loop.