«    »

Understanding Project Schedules

Project schedules are obviously important for project managers and team leads. They are often asked questions like "When will this project be finished?", with a typical follow-up question of "Can it be done sooner?". So one key responsibility of project managers is to create and maintain the project schedule. Does this mean that software developers can remain blissfully ignorant about project schedules? I say no.

There are many good reasons why developers need to understand project schedules. When the project manager asks you how long it will take to do a task, the process of creating an estimate is essentially like creating a project schedule. As a senior developer, you might have junior developers working under you, and now have to provide estimates for their tasks. Junior or senior, poor decisions made by developers as they design and code the software can significantly increase the time spent on a feature. Developers ignorant of the schedule are more likely to negatively impact the schedule because of this. Often there is pressure to complete the project quicker - perhaps the customer wants the software sooner, or the project manager wants to finish 'early' in order to look good. The result can be an unrealistic or impossible project schedule imposed on the developers. The consequences are increased stress, overtime, and missed milestones. Understanding project schedules can help you negotiate a more reasonable schedule.

Project schedules depend on four inter-related factors: time, resources, scope and quality. Time is how long it will take to get the work done. Resources are the people that actually get the work done - the developers, testers, analysts, etc. Scope is the amount of work that needs to be done. Quality represents all aspects of quality concerning the software and the project, the most obvious of which is the defect rate.

These factors are inter-dependent: you cannot change one without affecting the others. For example, what if your project is scheduled to take ten weeks, and you are suddenly told it must be done in seven? You don't get more people (resources), nor can you eliminate some features (scope) or reduce the quality. Since you cannot change any of the other factors, you cannot change the amount of time required to complete the project. Sometimes people think that the project schedule is the reality, when it is actually a forecast that tries to predict what the future will be like. If conditions change, then you can update your schedule. But you cannot arbitrarily modify the schedule: this will cause it to diverge from reality and make it useless or even harmful.

In management books, it is common for quality to be left out as a main factor and instead be treated as an aspect of scope, leaving just three main factors of time, resources and scope. (See for example Rapid Development by Steve McConnell, page 126.) This is a reasonable choice that produces a simpler model. However, I prefer to have quality be a separate factor on its own. When project time lines are arbitrarily shrunk and the project finishes earlier, it is often because the quality of the software has been sacrificed in order to meet the aggressive deadline. By making quality a fourth factor of equal standing with the others, the trade-off between time, resources, or scope and quality becomes more apparent. To me, quality represents more than just the defect rate: it also includes the non-functional, implicit software requirements such as usability, maintainability, and scalability.

Any change to the project schedule typically involves a trade-off between two or more factors. You can reduce the time required to complete the project if you reduce the number of features to be delivered. If you want to implement more features, you can add more resources or increase the time required. If half-way through the project you lose a developer, you'll either need to increase the time required till completion, or reduce the number of features.

I created an applet called the Management Diamond to visually represent the relationship between the four factors of project schedules. This software is available to run or download from my Software page. This software is strictly for educational purposes, and is not meant to be accurate. It uses a constant, linear relationship between the four factors.

In reality, relationships between the factors are not always linear, nor do they stay constant throughout the project. If the quality is poor - many defects or difficult-to-maintain code - instead of saving time you will spend extra time due to the overhead imposed by the poor quality. At the start of a project, adding people will help you get more done in less time. But near the end of a project, Brook's law states the opposite: "Adding manpower to a late software project makes it later". Brook's law comes true when the overhead spent by existing project resources in training the new additions to the team is greater than the contribution provided by the new people. In essence, while you have increased your resources, you have also increased your scope to include some new work - train the new people.

As software developers, we have limited control or influence over the number of people available for the project or the time available to complete the work. Often, even project managers have little control over resources and time. Lowering quality below a certain level hurts rather than helps. But scope - the remaining factor - is one we can play a significant role in determining.

The requirements phase of a project is the best time to control or reduce the scope. As requirements are being gathered, we can provide guidance on the level of effort required for each requirement. We can also suggest changes that reduce the level of effort, often with limited or no impact to users. With this information, the customer can make intelligent decisions about the value of each requirement in relation to the effort required. If resources or time is limited then this is the best point in the project to reduce the total effort required by controlling the scope.

Once construction begins and we are designing and coding individual features, we can still have a major impact on the scope. Often the requirements we are working from are sufficiently vague that we have several options for how to proceed. The more elaborate and complex the solution we choose, the longer it will take. The difference between the time required for the simplest versus the most elaborate solution can be several orders of magnitude. Rapid Development (page 332-333) has an excellent example of this. For a project to create a charting program, there is a requirement to support polymarkers (symbols like squares, circles, etc. that indicate positions on a graph). The requirement does not address what size these polymarkers should be, or whether the user should have control over the size. The simplest solution is to define constants in the code for these sizes, thus providing no ability for them to be changed. Time required: a few minutes. One of the most complex options is to provide a user interface for the user to specify the size of each of the polymarker shapes. Time required: a week or more. This tremendous variance in scope arises from a seemingly trivial aspect of the original requirement - the polymarker sizes. A developer unaware of the impact on the project schedule may by default choose the more complex solution - this is a natural bias for many developers. Combine this with similar decisions on other features, and the project will likely end up far behind its original schedule.

As software developers, our actions impact the project schedule, and we in turn are affected by the constraints imposed by the schedule. Understanding project schedules - the four factors of time, resources, scope, and quality - is therefore a necessity for us as professionals. To learn more about project schedules, I recommend the book Rapid Development by Steve McConnell.

If you find this article helpful, please make a donation.

«    »