Defining UAT Team Roles and Responsibilities
Today, we welcome back our popular guest author, Renée Mineart.
There are many, many challenges in developing and delivering a successful application. That’s what makes it interesting, if you ask me. One of the greatest of these challenges, in my experience, is time management (apart from a planet wide pandemic of course!).
Not your time as a developer, not my time as a manager. That comes part and parcel with the project. However, getting your userbase to set aside time in their busy schedule to test the project you’re developing, now that is a challenge. Also, negotiating that time with your userbase’s manager can be a hurdle.It’s often easier for us to get two different operating systems to work together than it is to get a group of people to all go in the same direction. If only people were as easy to program!
What’s worse, once you’ve agreed the time with all parties involved, if something that is deemed to be more important comes up, User Acceptance Testing (UAT), or other project work, often gets brushed aside as the least critical task which isn’t ideal.
If Covid-19 has taught us anything, testing is vital and it doesn’t really matter if your bugs are virtual or viral, you will only find them with an adequate testing program.
Where I’m working at the moment, we have a formal system in place for acquiring and managing the time of members from different teams, we call it Work Centre Planning (WCP). It’s a four-step process that allows us to manage and forecast everyone’s workloads in the organisation. This completely does away with the tug-of-war struggle of getting people’s time for testing or other support tasks.
Step 1. Every team leader decides how much time they can free up from their team members on an individual basis for project work. We call this the Business As Usual (BAU)/Project Split.
The splits generally fall into patterns like 60/40, 70/30, 80/20, etc. Where 60% of someone’s time is dedicated to BAU and 40% to project work, which includes anything from UAT, project meetings, development work, etc. This forms an up-front agreement with our development team and team leaders. It means a team leader knows just how much time their staff can give to BAU.
Step 2. When a developer, project manager, etc., needs someone from another team to work on their project, they discuss the requirements with the team leader and agree a block of time on a weekly basis. They also discuss the requirements with the individual as required, but often the individual is already aware of the work coming down the pipe.
Each team in our organisation has a spreadsheet and each team member has a worksheet where their BAU & project time is tracked (as well as annual leave, holidays, etc.,). When a certain number of hours (x hours) are agreed for an individual, the team leader removes x hours from that person’s BAU time and assigns it to the project. All time defaults to BAU if not assigned to a project.
All of these spreadsheets are then collated into a Power BI Dashboard where we can see the department as a whole, each team or each individual’s workload. We generally forecast 4-6 weeks in the future, although we prefer 8 weeks when we can manage it. Obviously, as time progresses, the forecast becomes more refined and specific.
But we can, at a glance, get a feel for how much time the department has scheduled for BAU, projects, leave, etc. We can then drill down and see that for each team or individual with just a click of the mouse in Power BI.
Most importantly, we can see if any individual is overbooked and is expected to do more work than they can squeeze into a week.
Step 3. Every Monday, we have a WCP meeting with the PMs, developers and team leaders and iron out any projected overbookings and discuss our catalogue of projects. This keeps team leaders in the loop of what is coming down the pipe, so there are no last-minute surprises or unexpected demands on their staff.
Step 4. At the end of each week, individuals in the department enter their time in a time tracking application, documenting how much time they actually spent on BAU or project work. This gives us a historical view of the department’s workload.
I remember running a development project many, many years ago where I was promised 50% of a developer’s time for six months. It lasted about three weeks before it was cut to 40%. I then spent the following five months fighting to get even 25% of his time on any kind of a regular basis. It seems more important work just kept coming up. It made it even more difficult in that I wasn’t working in the same physical building, and not even in the same city as the developer. Much like everyone else is doing right now, but before it was cool.
Work Centre Planning gives us a formal process to negotiate time between teams and essentially ring fence resources from different teams to work together on a single project. Because everyone has agreed to the process up front, there are no take backs of people’s time once it’s been committed to a project.
Also, because we have regular meetings, team leaders and managers are aware of the work coming down the pipe and its importance to the business. Essentially, we involve them in the process, and they get to share in the success. Work Centre Planning has been a win-win for everyone involved and a major stress reducer for project managers.