Management Consulting
Management Coaching
Workshops
Project Management
Management
Hiring
Requirements
Consulting
Process Improvement and Quality
Managing Product Development
Hiring Technical People
Behind Closed Doors: Secrets of Great Management
Hiring the Best Knowledge Workers, Techies & Nerds
Corrective Action for the Software Industry
Amplifying Your Effectivess
Speaking Calendar
Testimonials
Resume
Contact
Maintaining Project Agility
by Johanna Rothman. Originally published in Cutter's e-Project Advisor, February 8, 2001.
Gotta release it now? Gotta put in just that one more feature? Gotta do something else? The more gottas you have, the less agile your project is.
E-project management is about the ability to adapt quickly to changing conditions. So, how can you possibly adapt if the more you adapt the less agile your project is?
One possibility is to change conditions in only one dimension for a given project and to have multiple concurrent projects to achieve all the gottas. Instead of trying to cram lots of features into one
release and improve performance, group the features and performance work into chunks of work and then schedule a release for each chunk. Start the releases at the same time, so you're still working on the same product, just with different deliverables at different times. This is the "release train" concept. You schedule a large number of independent pieces. When they are ready, they ship. The slower pieces don't prevent the faster ones from being part of the product or from shipping. If you need to change which pieces get done first, you have options. E-projects are particularly suited to managing which pieces are done when, if the customer never actually receives the software, or if the software is installed and the customer uses it.
Another possibility to improve project agility is to improve the overall speed of product development, so that you can get more features in your products. I start with a low-tech approach to improving speed of product development -- I ask the technical staff what's preventing them from moving faster. After we get rid of the useless meetings, the interruptions, and the time wasting, we move toward two of the most common project slow-downs: optimistic scheduling and producing too many defects along with the code.
When I discuss the schedule estimates and actuals with project staff, I focus on what they estimated and when they delivered it. We compare the actual against the planned and understand why they are different. Most engineers I know reliably underestimate their work by some specific percentage. Once we discuss that underestimation, we come up with a plan to manage it, generally including them creating about a month's worth of inch-pebbles so they can track their schedules better than I can. (An inch-pebble is a one- to two-day task that is either complete or not complete.) Some engineers overestimate the time required. We also develop inch-pebbles, which they track, to see if they can participate in other areas of the project in addition to their work. In my experience, most engineers with more than five years of experience are actually fairly good estimators, they just can't estimate the amount of weekly bureaucracy they have to deal with.
Both possibilities for managing the speed and agility problems come back to management, both functional management and project management. Instead of reactive management, e-project management demands proactive management.
How can you be a proactive manager? We can't think any faster than we do right now, so we and our project staff have to do different things. Here are some suggestions for being more proactive:
- Measure fault feedback ratio (ratio of bad fixes to total fixes), starting early in the project. Where are the defects coming from, and how many of the fixes create more defects? Engineers create defects along with the product. As project managers, we need to manage the "leakage" of defects from one activity to the next. If we continually look to see where our current defects cause other problems, we can prevent some of the more defect-producing activities and concentrate on those activities with defect reduction.
During the implementation and testing part of the project, it's common for the developers to create more problems than they solve with a fix. When I observe requirements definition activities, I measure the same sort of fault-injection problem, where people create problems when they try to solve problems. If you measure the fault feedback ratio early, you'll know if you're creating technical debt you'll have to deal with later. Technical debt is expensive and time-consuming to manage. - Tracking the critical path daily with the use of inch-pebbles is a way for the project staff to be more proactive with you. Inch-pebbles help you and the project staff know within a day or two if anyone on the project is falling behind. If you combine this with a short (five minutes) check-in with everyone individually, you'll know if the project is on track.
- Keep the project short and small. The more project content, the longer the project duration, and the more people, the fewer tradeoffs the project manager can make. If you need more content in the project, or if some pieces take longer, start multiple independent concurrent projects. Where possible, keep your project staff to competent capable people, with a very few number of less-experienced people.
None of these techniques are rocket science; they're standard project management practices. The more agile the project, the more you have to use these techniques.
Johanna Rothman observes and consults on managing high technology product development, looking for the leverage points that will make her clients more successful. You can reach her at jr@jrothman.com or by visiting www.jrothman.com.
What can we do for you? Go to: Writings and Presentations, Chronological Listing