Reducing Schedule Risk (Part 2)
Reducing Schedule Risk, which I originally wrote over a year ago, describes how project managers can identify and track project milestones to reduce schedule risk. While every manager should adhere to this best practice, it's clear that setting miniature milestones will not entirely eliminate the risk associated with the development of a complex software system. Hence, "Reducing Schedule Risk, Part 2".
Build on a Solid Base
Bugs are inevitable. Good software development practices will reduce the number of defects per KLOC, but it will not eliminate them.
Unless you're starting from scratch, you're adding features to a system that already contains bugs. While these defects might not be have a huge impact to the system's current functionality, they might seriously impede and even block your ability to develop new features.
Imagine, for example, a bug raised against a low-level API that's currently not being exercised. Given that the specific interface is not being called, you might have opted to simply document the bug in a release note, or perhaps ignore it altogether. However, building a new feature that requires this interface will now be affected. Not only will you have to develop the feature, but you'll also need to fix the bug(s), which will certainly increase the duration of your overall task. If the person in charge of sizing the feature is aware of the bug, he/she might include it in the sizing. However, if he/she assumes that the interface is defect-free, or that it's someone else's responsibility to fix this problem, then chances are he/she will omit it from the sizing. What do you end up with? A project schedule that doesn't include all of the necessary tasks.
What is considered a "solid base"? While there is no standard definition of what constitutes a solid base, I believe that a system with less then .1% defect rate can be considered solid. In other words, if your system contains less than 1 defect per KLOC, you can feel confident that your overall project schedule won't be seriously affected by existing defects. You're challenge will therefore be to accurately size the new features.
Every good project manager should know off the top of his head the average fix rate of his/her development team. The fix rate of my current team is ~4 bugs/developer/week, or 16 bugs per person-month. Knowing this rate and the number of outstanding defects in our base system allows me to calculate how long it will take my team to fix bugs in the event that the ratio exceeds .1%. Once you understand how long it will take your team to create a solid base, add this sizing to your project schedule.
Assign The Right People To The Right Tasks
In "First, Break All the Rules" (1), Marcus Buckingham and Curt Coffman of the Gallup Organization present the remarkable findings of their massive in-depth study of great managers. One of these findings is that "people just don't change that much."
While a charismatic project manager might turn a poor developer into an average one, or an average developer into a good one, he/she will never transform a poor developer into a great one.
Do not head into a project with poor developers thinking that the project management skills or motivational techniques you learned during last week's seminar will transform them. They won't!
If you have the option of selecting your team, choose people who have a track record for getting things done on time, according to specs, and with a high degree of quality. If you don't have that luxury - and most of us don't - plan accordingly. Assign your best developers to tasks that are on the critical path, and your poorer ones to activities that are less time-sensitive. And follow Buckingham and Coffman's advice. Give your second-rate developers a clear set of guidelines and instructions that they must follow to get the task completed. Don't just tell them where to go; show them how to get there.
Start With High-risk Tasks
Most project managers agree that the waterfall model is ineffective when it comes to developing complex software systems. Unfortunately, many don't understand the basic principles behind incremental software development processes. They put the simplest tasks in their first iteration, and leave the high-risk ones until the end.
Does the expression "when the first 90% of the project ends, the second 90% begins" apply to your projects? If so, you're guilty of not properly planning your iterations.
Starting with simple tasks gives the impression that the project is running smoothly and progressing rapidly, but that impression is only temporary. Sooner or later, you'll be looking for excuses to explain why a demo presented 3 months ago is still not ready for testing. Or why the interfaces are still changing even though the product is schedule to be generally available in less than 2 weeks.
Identify the high-risk tasks, and add them to your earlier iterations.
Don't Boil The Ocean
While high-risk tasks are practically unavoidable, don't try to boil the ocean. If your entire project consists of high-risk tasks, then the project itself is high-risk and bound for failure.
When scrubbing your requirements, follow the 80/20 rule. Make sure the majority of your effort is spent on tasks that are well defined and understood by your techies. If your designers have no idea how to implement the majority of the tasks listed in your project plan, assume there are going to be some roadblocks. Reduce the number of high-risk features, or add a buffer to your project plan to account for the risk.
Integrate Early And Often
Integration is too often an activity left until the final phase of the project. Developers write, test and demo their code stub thinking that their piece of the puzzle is going to smoothly fit into an adjacent piece. And when it doesn't, they point the finger at the developer that worked on the other component.
Integrate early and often, and take advantage of best practices such as the daily build process. Integrating now can save your days or weeks of costly redesign down the road.
There you have it. Five additional tips to help you reduce schedule risk and launch your project on time, according to specs, and with a high level of quality.
(1) Buckingham, M. and C. Coffman, "First, Break All the Rules: What the World's Greatest Managers Do Differently", New York, Simon & Schuster, 1999.
This article was originally published on www.gantthead.com.