Do I have your attention yet? Most people in software development instinctively know that the project manager's drive to make sure the project is on time is at odds with the desire to have high quality software. Not that project managers don't want high quality software too, it's just they want the software and they want on-time delivery and costs that are at or less than what was estimated, in addition to quality. Their efforts are often successful at reducing cost and the development time without impacting quality. However, it is possible for them to push their techniques too far.
Although all of the following project management techniques are at least well meaning, and in some cases, they are even time honored techniques, they do have the potential for disaster.
Getting top honors in the list of things which can destroy software quality is the practice of time boxing. This practice is where you tell someone how long they are allowed to work on the task before it must be turned over. I say turned over and not completed because used at its extreme it often means that the code isn't complete, it's merely pushed along the process.
Time boxing works—most of the time—because it does three things:
- It forces the developer to be creative in finding a solution that fits within their budget.
- It eliminates unnecessary frills that are often added to software that don't necessarily add value.
- It prevents the developer from over testing.
The intent is to get the piece working. There's a whole QA phase where detailed testing will hopefully reveal any problems that there may be with the code.
Time boxing doesn't work when the problem is unknown, the technology isn't proven, or there's no real way to predict the results. It also doesn't work when the box is made so small there's no possible way to complete the objective within the allotted time. In other words, there are some things that time boxing works well for, such as well understood, carefully estimated, execution-type tasks. And some that it doesn't work well for, like research and development, problem solving, etc.
When time boxing is used correctly it shouldn't result in poorly tested code that will cause hundreds of hours of diagnostics and rework. It should be used with moderation to ensure the lowest cost, quickest and best quality software possible.
Everyone needs something to strive for. Milestones are a respected way to motivate people towards a unified goal. That motivation can often lead to great results in short periods of time. However, everyone must accept that the milestone date won't always be met and then they must decide what to do when that happens.
Project managers must put dates out in front of the group to motivate them but when the dates aren't realistic and they are consistently missed, it's time to reevaluate the plan. The problem is that when a really important date comes up there will be little drive to hit it because an expectation has been set that the date isn't important. After all if the team misses 10 dates in a row, how important can the 11th date be? It's like the boy who cried wolf.
If timelines are being set that have no penalty behind them and people aren't meeting them it's time to put some teeth behind them or move the whole timeline.
Continuing to create a constant stressful and confusing situation does not create a good software solution in the long run. Developers need to be able to concentrate on their work. The desire to meet the date and the confusion about whether the date is real or not may lead to developers skipping critical steps in the development process and, in doing so, creating problems that will be hard to find.
Pretending nothing is wrong
When it comes to project management, ignorance is not bliss. Despite the often overwhelming political pressure to have a successful project, it's necessary to be forward in describing the risks of the project with the rest of the organization. Nearly every software development project has risks that make it possible that it will be late or over budget or both.
The problem with this is eventually there comes a time when those risks turn into a reality and then panic sets in. Everyone scrambles to put together the rest of the pieces of the project and the quality of the project will suffer from the hastiness of the final assembly.
Of course, this problem isn't fully realized until the project gets behind; however, most projects find a way to get behind a little at some point in the project. Nearly every software development project is at risk of the rush that is caused when the business learns about the true state of the project after believing that nothing was wrong for a long time.
In software development we have a great number of techniques for delaying dependencies. We can stub out functions, remove connecting infrastructure, or bypass extensive error handling. All of these techniques when used correctly can be helpful to moving a project along. However, when it becomes required to get the project completed and when the costs of these techniques are not factored into the planning, trouble sets in.
Often times just sequencing a software development project can be very challenging. The dependencies are often hard to see so inevitably there are dependencies that aren't in the plan to start. Scheduling around these unforeseen dependencies can drive a person mad. So the techniques of neutralizing dependencies are used. However, if too many of these techniques are used the clean up cost can often become a non-trivial part of the project's overall cost—and one that isn't discovered until the very end.
Making sure that you're doing what is necessary to manage dependencies—without picking up too much cost—is a necessary part of software development. When project managers don't balance the cost with the convenience of reducing the dependency they create hastily assembled code which exhibits quality problems.
Disaster waiting to happen?
Be on the look out for project management techniques which have gone awry and may be causing your next project to be a quality disaster.