Software projects rarely come in both on time and on budget, leading to dissatisfied end users. It’s much easier to satisfy one of these conditions by working according to your original plan or adapting to the changing needs of your users. Satisfying both requires a certain amount of prescience. Tom Demarco and Timothy Lister, authors of Waltzing with Bears: Managing Risk on Software Projects, list schedule flaws as one of their five risks of software project management.
In this two-part article, we’ll discuss several symptoms and causes of schedule flaws, present metrics and diagrams that can be used to track your team’s progress against its schedule, and describe Agile ways to address these risks. We’ll focus on the symptoms of schedule flaws in part 1 and discuss the metrics used to discover them and how the Agile methods can help mitigate these risks in part 2.
The risk of schedule flaws refers to the certainty that any schedule created at the start of a project will be hopelessly out of date by the end of that project, and should not be counted on as an accurate projection of completion date, content, or cost. With the uncertainties and intangibles of software, it does not matter how much time and effort is put into creating the schedule at the start of a project because the schedule will certainly change along the way.
CAUSES OF SCHEDULE FLAWS
There are two different categories of causes for schedule flaws. The first category is directly related to unpredictability of the environment around a project, including the people, hardware, and network issues; vacation schedules; weather; and other causes that directly affect the rate at which work can be done. The second category is related to the difficulty in accurately predicting the time significant pieces of software will take to implement, test, and be ready for deployment.
- CATEGORY 1: Environmental issues are particularly tricky because they are unpredictable. People get sick, snow storms happen, and fiber gets cut occasionally. These usually aren’t a huge drag on your project and are generally outside of your control. However, their effects should be considered and anticipated. Also related to this category, and in your control, are the quantity and lengths of meetings that occur which pull people away from system development. If there is one item that can kill the productivity and morale of a good team, it’s the multiple meeting mania that occurs in some cultures.
- CATEGORY 2: The time issue is just a fact of life. Software is incredibly complex, it is not bound to obeying any laws of nature, and it is made up of lots of independent pieces that have to perfectly fit together into a coherent whole to function properly. Add to that the fact that no software plan survives its first contact with the customer, and you’re left with a situation where your plan is going to need to change to keep up with what is really happening. This is the risk that we’ll focus on below.
SYMPTOMS OF SCHEDULE FLAWS
Teams that suffer from schedule flaws often exhibit one or more of the following five symptoms:
1. Frequent change requests from customers and stakeholders
In theory, it seems logical to nail down what the stakeholders for a project want before anything happens on a project. The flaw in this vision is that customers rarely know what they want, especially if the system is new or revolutionary. As soon as they see some piece of the system in action, they’ll start to get ideas, which lead to change requests. Some of these may be new requirements that they’ve just discovered, and some may be refinements on work that has already been done. In either case, this results in new work that was unknown at the start of the project.
2. Unreliable estimates
Every interesting piece of software that gets built is inherently something new. Because of this, the time to build individual pieces is difficult to accurately estimate. Even in a well-understood domain, the particular solutions chosen by teams are rarely the same twice because the context in which the project exists is rarely the same twice. There is also a higher probability that a piece of work will be completed significantly after it was estimated rather than before. Inaccurate build estimates can drive the larger project schedule to being late.
3. Large amount of “off the books” work
Teams typically have two sets of work—things that are “on the books” or part of the schedule, and “off the books” work that everyone knows about, no one talks about, and no one factors into the plan. This can include action items such as the inevitable activities that have to be done to deliver software, some specialized kinds of testing like load and scalability, or just corners that were cut in the interests of some short-term deadline that everyone knows can’t be shipped but no one has planned time to correct. Every team has these, and these don’t usually show up as a schedule flaw until the last days of a project.
4. Uncertain quality
Uncertain quality is a more specific kind of “off the books” work. There are lots of software projects that don’t have a good grasp of the quality of their system day to day. They may not do full system builds until late in their project lifecycle; they may do only a limited amount of testing during development, put off performance or security testing until the software is “done,” or several other items that delay testing until late in the process. The effect of this is that there is a potential project risk of an unknown amount of work that needs to be done at the very worst time in a project’s lifecycle—at the very end, right before delivery is scheduled.
5. Matrixed team members
Every company has people who have specialized knowledge that are critical for the success of several projects. These staff members may be an architect who consults on several teams; the specialist in performance testing, usability, accessibility, or security; or just testers in general. There are also several other roles that teams need in varying degrees. Often times, the company has more work and more teams than it has developers to support them. In an attempt to maximize the utilization of these scarce resources, these people are asked to support several teams at the same time. This results in them becoming a bottleneck in the workflow of not just one team, but to all the teams with which they work.
METRICS
Having a good set of historical metrics is key to understanding when schedule flaws are occurring and what their effects have been. The most basic metric used to illustrate schedule flaws is a simple burn-down chart. Burn-down charts are just graphs of work completed versus time, sometimes with both actual and planned work/timelines shown. A project is on-track as long as the actual progress and planned progress match. A solid metric describing your progress against your desired delivery date is the most critical measurement for a project to keep, since it is the leading indicator of whether you have a problem.
Here is an example (figure 1) of a burn-down chart. In this diagram, we can see a project that spent several weeks basically tracking the ideal curve down their burndown chart. The net amount of work remaining for this release was steadily decreasing in a way that would let the project complete at a predictable date—in fact, it was proceeding on schedule. Then, suddenly, the project went off-track. A large amount of work was added to the release, as can be seen by the upwards slope of the burn-down line, and the completion date of the project was immediately in trouble. Scope had to be cut or time added to bring the project in successfully.
The chart in figure 1 is useful for seeing the net amount of work remaining on a project and projecting a completion date, but it does not provide a picture of the amount of work added versus work completed in absolute terms. There are several other kinds of graphs that are good for illustrating this, such as a stacked bar chart showing the amount of work complete versus amount of work remaining.
In figure 2, a burn-up chart example, the total height of any bar represents the total amount of work present in the project, while the green represents work completed and the red shows work left to do. In other words, the total scope of the project is constant as long as the height of each bar remains constant in comparison to the others. If the total height grows, then the project has included additional scope. Here, you can see that work is being added as quickly as it is being finished, resulting in a finish line that is constantly moving to the right.
These two graphs show the same backlog for the same project, but illustrate the different information available from each graph.
In the first section of this article, we discussed several reasons why projects may be late and showed how having historical data can help in discovering whether a project is on-schedule. In the next issue, we’ll talk about specific metrics that can be used to find the root cause of a schedule delay and then show how Agile methods can be used to find schedule issues early and mitigate their effects on your project.
