Contents:
- This month's Feature Article: How Many Emergency Projects Do You Have?
- Announcements
=-=-=-=-=-
Feature Article: How Many Emergency Projects Do You Have?
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. But the debt can be anywhere.
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:
- Timebox work on every project. A timebox helps people focus on the work they need to complete now.
- Work feature-by-feature instead of across the architecture, so everyone can see how good the features are and if the team will finish by the desired date.
- Integrate testing into every part of your project, instead of waiting for everything to be done before you start testing.
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.
=-=-=-=-=-
Announcements:
We've reinvented the AYE conference this year. Take a look at the schedule. In addition to the pre-conference warmup tutorial, we have two tutorials and consulting after the conference. I'll be leading a tutorial about strategic planning after the conference.
I'm thrilled to announce that Manage It! Your Guide to Modern, Pragmatic Project Management won a Jolt Productivity award. You can see that link for the preface and the templates or see the publisher's page for more excerpts.
Take a look at my blogs for my most recent writings:
Managing Product Development
Hiring Technical People
See previous issues of the Pragmatic Manager here.
Thanks for reading, and please do send me your comments.
Johanna