How Many Emergency Projects Do You Have?
Johanna Rothman, pragmaticmanager@jrothman.com

A project manager at a client took me aside recently. "Johanna, how many emergency projects should I have?" I was a bit surprised and asked what he meant. "Well, my boss thinks I can manage two normal projects and two or three emergency projects. I'm swamped."

I would think so. If I'm managing more than one project--actively managing, not caretaking--I can't even take on one emergency project, never mind two or three. Asking a project manager to actively manage risks, remove obstacles, and help the team accomplish the work on several projects--a couple of which are the most important thing the company can do--is overloading the project manager.

So, how do things get this way? Typically, emergency projects arise from a product's technical debt--work that was not completed in a previous project. To be fair, when the world changes out from underneath you, you might have an emergency project to catch up, but those aren't the norm. Emergency projects have names such as "hot fix" or "patch release" or "service pack" or something else that acknowledges the work wasn't finished the first time, incurring technical debt.

Anywhere you've cut corners in the past is a candidate for technical debt. If you don't have a coherent and cohesive design, writing and testing the code feels as if you're strangling yourself, and the product doesn't quite work the way you and the customers expect it to. Without requirements in some agreed-upon form, developers and testers decide on their own what the features are. Sometimes they even agree--but the customers might not. If the project team ran out of time for a feature or two or three, features the customers expect but are missing, some High Manager will say, "Ok, we'll do a patch release." If the testers don't have enough time to test and the developers don't have enough time to fix defects, the number of total defects may overwhelm the customers, which will require a hot fix.

If you have an emergency project, convince your manager that you need to pay attention to that project to the exclusion of every other project. If you don't, it's likely you and the team will not pay down enough technical debt, or that you won't know when you're done, or that you won't be able to meet the desired release date. Once you've got an emergency project, finish it.

Now that you're past the emergency, can you see ways to organize, manage, or replan your current projects so you don't require more emergency projects? If you're stuck on ideas, here are some:

Emergency projects slow everything down and prevent project managers and teams from making real progress on their work. Prevent them when you can. Finish them if you've got them.

=-=-=-=-=-
Take a look at my blogs for my most recent writings:

Managing Product Development:
http://www.jrothman.com/blog/mpd

Hiring Technical People:
http://www.jrothman.com/blog/htp

To see previous issues of the Pragmatic Manager, go to http://www.jrothman.com/pragmaticmanager/index.html

Thanks for reading, and please do send me your comments.

Johanna