|
The Pragmatic Manager Podcast|How Many Emergency Projects Do You Have? Episode
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 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? One reason for emergency projects is from a previous projectâs technical debt: work that was necessary for a product--but 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 shouldnât be 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âthose are the one that have 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 need to be. 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 not sure how, here are some ideas:- Timebox work on every single 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 all the features by the desired date.- Integrate testing into every part of your project, instead of waiting for everything to be done before you start testing. If you work feature-by-feature, you can test feature-by-feature, which helps developers see how good their work is.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.I'm offering a public project management workshop Sept. 22-24, 2008 in Waltham, MA. Youâll learn how to start, steer, and end a project successfully, using pragmatic approaches to project management. Youâll have a chance to practice approaches to projects that prevent emergency projects. Go to jrothman.com/workshops.html for more information. Here's the specific URL for the Manage It! Pragmatic Project Management Workshop. The registration form is on that page.Have comments on this podcast? Iâd love to hear from you. Email me at jr@jrothman.comYou can also listen to this podcast as an mp3.
[ Tue, 15 Jul 2008 13:00:00 GMT ]
|
