On Managing Emergency Projects
October 9, 2009 | Author: PM Hut | Filed under: Uncategorized
On Managing Emergency Projects
By Johanna Rothman
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.
This original article can be found at: http://www.jrothman.com/pragmaticmanager/emergencyprojects.html
Johanna Rothman consults, speaks, and writes on managing high-technology product development. Johanna is the author of Manage It!’Your Guide to Modern Pragmatic Project Management’. She is the coauthor of the pragmatic Behind Closed Doors, Secrets of Great Management, and author of the highly acclaimed Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People. And, Johanna is a host and session leader at the Amplifying Your Effectiveness (AYE) conference (http://www.ayeconference.com). You can see Johanna’s other writings at http://www.jrothman.com.
Related Articles
No comments yet.
feel free to leave a comment
Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!
XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
All fields marked with " * " are required.










