You've got a big, important project. It's not converging toward completion within the expected timeframe. There are too many incomplete tasks and too many unresolved bugs. Burndown charts and nasty reminders from leadership haven't been sufficient to get the project on track. It's time for a war room, and you might need to lead it.
War rooms have been in government and industry news lately. They are associated with difficult and rapidly changing situations that need to be monitored and responded to quickly. War rooms are staffed with individuals who are familiar with the situation and capable of driving the resolution of problems as they arise. Over the decades, Microsoft has used a variety of names for war rooms, including shiproom, uber-triage, and box triage. Typically, war rooms are used toward the end of large projects, and they are staffed with one (or more) release manager, all the group managers, and those responsible for driving the resolution of active tasks and bugs.
While the phrase "war room" is ugly, war rooms are essential. War rooms provide accountability and action when "I'll get to that tomorrow" won't do. No, you'll get to that today. War rooms are not meant to be kind or mean. They are not meant to be rude or polite. They are meant to drive the action necessary to resolve issues quickly, getting and keeping important projects on track. If your project is causing stress dreams, you need to set up and lead a war room.
If you keep your technical debt low and your release cadence quick, youâ€™ll have few incomplete tasks and unresolved bugs and, thus, no need for a war room. Read more in Cycle timeâ€”the soothsayer of productivity.
Tying the room together
Typically, war rooms are for projects involving at least 10 people (no upper limit; smaller teams can use standup meetings). You can use war rooms for any kind of project: a software release, a service outage, a marketing campaign, or a security issue, to name a few.
War rooms have a few critical elements:
- A meeting time and place (typically daily in a large room).
- Attendance by those who can and will drive issues to resolution.
- The authority from leadership to take necessary action.
- A leader who is willing and able dispassionately to speak truth to power.
- A list of issues being updated and tracked, along with prioritization criteria for those issues.
Share the meeting time and place with all potential attendees, and ensure attendees can fit in the room. Authority from leadership is necessary to get the right people in the room (and sometimes the room itself) and to reprioritize those people's work.
Bringing all these pieces together is the war room leader and the list of issues, with its associated prioritization criteria. These two elements are often the most difficult and intimidating parts of putting a war room together. Let's break them down.
Who's in charge here?
War rooms are typically run by release managersâ€”people who take time away from their usual duties to guide a project into its timely completion. Release managers are often program managers (PMs), but can be from any discipline. Anyone can run a war room. All you need is authority from your leadership, passion about completing the project, and confidence to speak the truth unabashedly to folks who outrank you.
If your project is in trouble and you feel responsible enough to be seriously stressed about it, you've got the passion necessary to run a war room. Assuming your leadership acknowledges the problem (very likely) and agrees to have you run the war room (also likely), the only other thing you need is the gall to order around your peers, including leads, managers, partners, and distinguished engineers.
Giving out orders comes naturally to some, but for many of us, it's a bit uncomfortable. We're used to collaborating and influencing, not dictating. However, when the project is in trouble and time is of the essence, you often need to tell people what to do. Think of it as a temporary role in a playâ€”you pull out the war room leader hat (and laptop) and become someone else for a while. You become someone who calls it like it is, assigns tasks, questions status, holds people accountable, and suffers no ambiguity or foolishness.
As uncomfortable as it may be to become a war room leader, everyone on your project will thank you for itâ€”even the distinguished engineers. They know the project is in trouble and appreciate someone getting it back on track. Being firm yet fair will win you many friends and much respect. Sure, you'll probably annoy a few people, but they'll know your job is necessary and be thankful you're the one doing it instead of them.
Just as with acting roles, people who run a war room well can often be typecast as release managers. Unless it's a role you like, you should make clear to your manager and leadership that this role is temporary and that part of your reward for doing it well should be the freedom to return to your preferred job.
At the core of a war room is the issue list and its associated prioritization criteria. The issue list indicates what work needs to be accomplished, where that work stands, and who needs to complete it (which sets war room attendance). The prioritization criteria indicate which issues must be resolved now and which can be resolved later (if ever).
No one will attend the war room if they can't see the issue list. At Microsoft, issue lists (usually incomplete tasks and unresolved bugs) are stored in Visual Studio Team Services (VSTS, formally known as Visual Studio Online or VSO) and are available through one or more shared queries. Everyone on the project needs links to those queries, knowing that an item assigned to them means they must attend the war room.
Everyone on the project also needs to know the prioritization criteria. The criteria typically use the same categories as done definitions (design, security, privacy, accessibility, world readiness, reliability, and so on), but indicate what level of risk is acceptable given the time crunch. Issues that don't meet the criteria should be resolved as cut or won't fix or assigned to a future project. Doing so reduces risk and workload and keeps the project on track. It also shortens the war room meetingâ€”a fan favorite.
Since both the issue list and its associated prioritization criteria are important and broadly shared, everyone must agree to them. That can be achieved by leadership edict, a representative cross-discipline virtual team, tradition (same as it ever was), or even your own invention as the war room leader. Regardless of how they are derived, everyone on the project needs to be fully aware of the issue list and prioritization criteria in advance. If people have a problem with the list or criteria, you need to address their concerns or have leadership insist on compliance. Once the list and criteria are in place, you're ready to run the war room.
For more on defining â€œdone,â€ read Nailing the nominals.
Before you run the first war room meeting, you need to:
- Reserve and share a room and recurring timeslot.
- Establish and share the issue list (typically one or more VSTS queries).
- Establish and share the prioritization criteria (typically with a document or webpage).
- Remind everyone about the room, timeslot, issue list, and prioritization criteria, as well as the expectation that if an issue is assigned to them, they must update its status and appear in war room until their issue is resolved or reassigned.
Before every war room meeting, you need to:
- Ensure every active issue is assigned to someone.
During every war room meeting, you need to:
- First, review the key health indicators of the overall project for context. These typically include issue counts, build and test status, and customer feedback trends.
- Next, go through the issues list one item at a time. (It helps to know VSTS shortcut keys, or have an expert friend run the tool.)
- Quickly remind everyone about what the next issue is and its status. You do this to keep attendees from trying to solve problems during the war room, droning on about their issues, and/or avoiding action.
- Then ask, "Is the person assigned to the issue (or a delegate) in attendance?" If not, is the personâ€™s manager in attendance? If not, after the meeting, notify them both and the manager's manager that they missed the war room, their issue must be updated and resolved, they must attend the war room until it is, and the project depends upon it. That's all true.
- Next ask for a confirmation of the issue's status. If the status hasn't been updated, why not? If the wrong person is assigned, who is the right person? When will the issue be resolved? If the issue should have been resolved by now, what's wrong? Update the assignment and status as needed and move on.
- If substantial new information has arisen, ask for a confirmation of the issue's prioritization. Does the updated status change the priority based on the criteria? Is more investigation necessary? If so, update the status and priority accordingly and move on. This may include resolving the issue as cut, completed, won't fix, fixed, or moved to a future project.
- Continue to the next item until you are through. Be quick and to the point. Cut people off if they drone on or rat hole on some narrow discussion that should happen in a different room. There are many issues to cover and many people in the room. Respect their time and focus on action. Attendees will love and respect you for it.
As you can see, the mechanics of war room are straightforward, but you do need to hold everyone accountable for making progress and resolving issues quickly. The best war room leaders are fast and professional, know the keyboard shortcuts, and will say anything necessary and true to anyone at any time.
Running a war room is similar to running a triage meeting. For more on triage, read "Are we having fun yet?" (chapter 1).
What is it good for?
For teams that continuously deliver services with high quality and availability, war rooms aren't typically necessaryâ€”there isn't a large backlog of incomplete tasks or unresolved bugs. However, life is diverse and surprising, and sometimes projects can get out of control. In those cases, when there's insufficient time to slowly get back on track, a war room is essential.
Your project may already have a war room process established. However, if a situation sneaks up on you, you might need to set up your own war room. Ask for permission and support from your leadership. Set up a room, timeslot, issue list, and prioritization criteria. Share them with the whole project team, and address any concerns. Then run your war room regularly until all the issues are resolved and the project is back on track.
While it's a difficult job, running a war room can be exhilarating. It also can relieve some of your stress, since you are doing something about the source of your anxiety. (It can add stress tooâ€”thankfully, thatâ€™s temporary.) In the end, you'll save your project, gain the respect of your peers and leadership, and deliver for our customers. It is worthy work.