If you, like me work in a place where there are more projects than there are QA staff to test them, you’ll see a situation where individuals are assigned to multiple projects. This is never going to be an ideal situation for either the individual or the projects that they are involved with. There are a couple of reasons for this.
Each project brings with it an administrative overhead, in the form of meetings that need to be attended (ie. scrums, planning sessions, reviews), paperwork that needs to be completed, organising work delivery, and reporting back on work as it is carried out. This all must be paid for by the tester from the time he has available, which actually leads to them having to make more time if that’s possible, or cutting corners if it’s not.
Competing time frames and project schedules lead to project delays. A project plan is never a perfect picture of a project, and nor can it be given the fluid dynamic nature that a project beast is. At best a plan is an accurate and detailed overview, at worst, not much more than a crude mud map that outlines only the most high level activities and time guestimations. Plans slip, and suddenly where there two back to back activities for two projects, now they overlap. This leads to negotiating and bargaining with resources to now start splitting their time to serve both.
Each project is the most important one in the eyes of its stakeholders, and the tester will be asked by stakeholders from each to put their project first. This is never a good position to be put in, because there is no clear way to move, and someone is always going to loose out.
So what do you do if you are assigned to multiple projects, and you have to work with each and see deadlines met? I’ve found that there are a few work practices that will help you work effectively, and avoid digging holes that you will later fall into.
Communicate clearly what time you have and what you can reasonably be expected to achieve, to the project stakeholders of each project.
If you have 4 hours for two projects in a single day, write to each project stakeholder (together or separately) tell them what time you will be starting and what time you will be ending with their project, and what it is you will do with that time. Make sure to factor in overhead for the projects. 4 hours time does not mean 4 hours of testing; it means more than likely 1 hour of overhead, 2.5 hours of testing, and 30 minutes of time for unexpected unplanned events. Work out what that 2.5 hours of testing will likely get done, and communicate that upstream.
Organise dependancies ahead of time.
Testing is not an activity done in a vacuum. You will need at the very least, a build on an environment that you have access to. You will also need change logs, resolved bug lists, new feature documentation or descriptions, and the priorities of the project team. Get emails to project stakeholders asking for this before your time on a project starts. If you wait until your time on a project starts, you could very well end up spending all of your testing time trying to get these dependencies sorted out. In real work terms, you risk achieving a lot less.
Communicate any changes to your time schedules as they happen.
Events will happen that will change your time schedule and impact your ability to work on a project. Some you will have control over, and others will be beyond your control, such as a build getting delivered late, or a critical person not being available to help at a time previously agreed. When this occurs you want to communicate what happened, and what the impact is to the project stakeholders of each project that is affected. Do that immediately. People are more likely to find a positive outcome with real time information, than having something dumped on them at the last minute and having to find an emergency solution that has a lot more risk.
Don’t take sides.
Stakeholders that are vying for you as a resource will invariably try to draw you onto their side to get more of you than has been allocated. This is where most political bargaining situations occur, and unless you navigate those waters very well, you will end up making someone in the organisation – very – unhappy, which could have consequences. Put friends aside, and state clearly to all stakeholders that you must work according to your project allocation. Don’t get drawn into discussions on who is more important, and what project is more important. If there is a conflict between projects and your being put in a position to take a side, escalate this back up to a relevant person in the organisation heirarchy, and let them decide what the resolution is.
Finish your work time with a concise report on what you achieved, what still needs to be done, and what is blocking you (if any).
When you come to the end of your time allocation on a project, don’t just drop what you’re doing and move on to the next project. Spend 10 – 15 minutes writing a concise bullet point style work review communique. Explain what you did finish, and what you didn’t finish, and if something held you up, precisely what it was. After you stop working, someone else might be picking up where you left off, or work might be left until you are next allocated to that project. Someone is going to need to know what the end status of work is, and putting this into a form that is easy to digest and quick to send around to relevant stakeholders is going to be much easier than having to tell them all face to face or on IM. This becomes another potential project administration time sink, and productivity blocker.
I’ve personally found these work practices very effective in dealing with multiple projects, and multiple stakeholders all trying to get their – most – important project done. At the very least I’ve found that they have saved me a lot of problems with miscommunication and misunderstands that can lead to very real project delays and angry managers.