Breathing Underwater

As noted in my previous blogs regarding screw ups in the workplace, sometimes what we do can make it harder to do our jobs. Sometimes, however, we are dumped into the deep end of the pool and have to keep everyone's head above the water, including our own, in a situation that we did not make for ourselves.

The first thing to do is to determine if you are actually underwater. By being underwater, I mean that your tasks and their scheduled complete date are sufficiently in jeopardy that if you had to choose between green status (all good), yellow status (likely ok, but problems) and red status (dear god), you'd put yourself in red status.

An example from my own life involved taking on a project for my company with a bank. The project had been scoped and approved and then paid for by the IS department of a specific group...then, during the time before the planning phase started, the company reorganized and a different group ended up with the contract. These folks did not want an external development company; their leader wanted full control over the project. He did what he could to get me and my team to literally move to Boston where he could supervise us. That was not in the contract, so we had several meetings, put together a plan and a schedule, and started moving forward.

Unbeknownst to my company and myself, he began hiring contractors. He already had one, but added two more. He gave them direct orders, often counter to what he agreed on in meetings with me and what they agreed upon in meetings with the entire team. Meetings we had DAILY to prevent this type of cross communication.

Once I caught on that, effectively, the other team had gone rogue at the customers request, I spoke with my boss and then the company president. Looking at my daily numbers, we were not only not moving forward on the schedule, in many cases we were moving backwards as my team had to fix things that had gotten broken, or throw away code that would no longer be used due to a change in direction that happened in a time zone three hours ahead of ours.

Armed with my daily numbers regarding checkins, bug fixes, feature progress, emails from all developers involved, I approached my boss and his boss and made the recommendation to simply end the project. If the project was being, effectively, sabatoged daily, then we needed to get out with our reputation intact and no additional monetary losses.

For reasons that made sense only to upper management, my request was not approved. I had to schedule more regular meetings with the client, meetings where the president of the company was present. Meetings were I got dressed down, nearly every day, for things that had been discussed the previous day. But I persevered. I've talked about the value of documentation before, and this is the project that brought that home for me. For every allegation, I had a document on why it had been done and who had approved it.

Eventually we achieved a rhythm; my team would come in and spend the first hour or two of the day undoing checkins from the Boston team. Then they'd fix the code the Boston team had made plug it back in, make sure the build wasn't breaking and the tests were now running, and then they'd start their work. Where you normally assume a person isn't productive eight straight hours a day, and I typically assumed six hours of productive time, I modified my schedule to include this maintenance and dropped them down to three hours of productive time per day and stopped counting the Boston team's work at all.

Suddenly, the client was getting what he/she wanted (in a really convoluted, frustrating way). I was able to alter the schedule and scope. I brought in Starbucks cards and toys and books for my team--every time they had to undo a tangle created by the Boston team, they got a prize.

In return, on the day when they finally got the build automation and test automation to work perfectly--greens all across the board--they took a picture of themselves doing the "Vanna White" thing with the monitor holding the good news and sent it to me (I was home sick that day). The whole team, grinning ear to ear made it clear I'd gotten their heads above water, and that, maybe, I had developed some gills. We did end up delivering on time and on budget, with the new schedule and scope.

Not all projects are that bad. But I think of that whenever a project I'm working on looks dire. At least, I think, its not that project all over again.

So basically, the steps to managing an underwater project break down as:

1) Realize you are underwater. Accept. Do not panic
2) TELL SOMEONE. Specifically your boss and/or his boss. The sooner people know, the sooner they can help, but also the sooner they can adjust their expectations.
3) It's ok to recommend that you close or cancel a project that is under water. You can do this based on return on investment (the calculation that the project is costing the company more than they'd get for completing it). But only do this if that is absolutely the case, and you have clear measurements to prove it.
4) You might get help, you might not. At the end of the day, the project underwater is your project. You will have to use what you have available to get back to the surface (and hopefully beyond)
5) Things you have to help you: the ability to adjust schedule, the ability to adjust scope, the ability to adjust resources. As we discussed in the Iron Triangle post, these are three things that make up a project; adjusting any one of them affects the others. So to pull yourself out of being underwater schedule-wise, you can add resources and reduce scope. To meet an expanded scope, you can extend schedule and resources, and to deal with fewer resources you can extend schedule and reduce scope. In my example above, that's what I did: I assumed fewer resources (because my team was undoing the work of the other team) and shrank scope and expanded schedule accordingly.
6) Address morale. Even if you don't actively have a team working against your team, being on an underwater project reduces morale. Death marches are often a technique used to try and get back out from under water, and, for a short time, they work, but the damage to morale affects the long term effectiveness and usefulness of your resources. You need to keep morale up, even if it means breaking for lunch together despite the fact there's still work to do.
7) Be creative. These prescriptive steps don't cover it all; the fact my team was thinking of beating the hell out of one of the developers when he came over to learn more about our systems required me to make each time they had to undo someone else's mistake a rewarding experience, to reduce the overall frustration. AS a manager, donuts, coffee, toys and books are a small price to pay to avoid homicide and to get a project done. But whatever works for me might not work for you--so be creative.
8) Keep communicating. Daily if you have to. No one wants to be surprised when a project goes underwater and stays there and maybe fails to meet dates or scope requirements. Keep everyone in the loop on the blocking issues and what you're doing to resolve them. Not every project will work out. You will have failures. This documentation will protect you and provide information for a project post mortem (a common technique where people call a meeting to find out what happened during the project). Often post mortems for projects that did not succeed become blame games that are not useful. But the communication, summaries and reports you keep during the process can clearly identify what was what, and keep the unproductive blame game at bay.