Chapter 11: Scheduling continued
Maintaining a balance between the amount of work you have to do, the amount of resources you have available, and the amount of time you have to complete the project is the oldest and most important rule of scheduling. If any one of these gets out of balanceor worse, if you are given a set of constraints that cannot be balancedyou will not be able to deliver the software on time. Even if your project starts off balanced, there’s a good chance it won’t stay that way. Development cycles contain enough twists and turns to throw even the best schedules out of balance. The project manager must review the schedule regularly and take whatever action is required to keep the elements in balance throughout the project. I’ll discuss how you can monitor your project and make changes in Chapter 12.
Tasks and Estimates
Tasks are the fundamental building blocks of a schedule; they represent the specific work that must be completed. As a general rule, it’s easier to monitor the progress of smaller tasks. You can quickly find out if you’re falling behind schedule when the tasks are short and precise. For example, if a task can’t be completed in one or two weeks, break it up into two or more tasks. Filling your schedule with longer tasks will make it very difficult to track your progress.
When you develop a list of tasks, be sure to keep in mind the relationship of one task to others within the project. For example, know which tasks are dependent on other tasks, and schedule them in the proper order. Key features should always be completed first. You must know how long each task will take. Make an estimatean educated guessabout how much time will be needed to complete a specific task. Because of all the work you’ve already done toward defining requirements, user interface, and technology implementation, your estimates should be based on solid information and be relatively easy to develop. If you can’t develop solid estimates for key tasks, you probably haven’t done enough investigation, prototyping, or research for the tasks.
The estimates should include all the work that must be performed to complete the tasks. For example, software engineers should provide estimates for the low-level design, implementation, debugging, and unit testing. User education engineers should estimate how much time it will take to write, review, copyedit, and proofread their own work. Although each individual creates a task estimate for his or her own work, the estimates should always be reviewed by the appropriate lead. These estimates will be used to create an overall estimate for the project, so you must be confident that the numbers have been chosen correctly.
Over time, you’ll find that the accuracy of your estimates will increase, especially as you continue to work on the same product using the same technology. Be sure to review any tasks that take much longer than you expected in order to understand why the estimate was faulty.
A Complete Schedule
Don’t make the mistake of scheduling just the software portion of the projectevery single discipline that contributes to the project should be included in the schedule. These include:
One of the important themes of this book is that running all of the aspects of a project in parallel enhances the development cycle. A good way to implement this development philosophy is through the project’s schedule. Your goal is to integrate the development, QA, user education, human factors, and release engineering tasks together for the completion of specific features.
Consider this example of parallel development. Say your developers will be delivering features that correspond to the commands "Create Customer," "Modify Customer," and "Delete Customer." As soon as the features are ready and appear in the daily build, your QA team should test them and provide immediate feedback on the quality of the implementation. At the same time, your human factors teams should be evaluating the user interface to see if usability standards and implementation goals have been met. Your user education team should be finalizing their description of these features and providing feedback on quality, implementation, and integration.
Parallel development has many important benefits. First, it focuses the entire team’s effort on getting a set of features implemented as soon as possible. This creates a sense of urgency, purpose, and (hopefully) early success in the project. It will also keep the team focused and in sync throughout the development process because your team will be talking about, working on, and improving the same issues at the same time. Second, because the entire team is focused on the same features, you will know much earlier if a feature is done or whether it’s just coded and suffers from problems with quality, integration, or usability. You goal is to get the team to deliver solid working features as soon as possible and not be forced to revisit issues you thought had been resolved. You don’t want to be surprised by quality or implementation issues on features that were supposedly finished weeks or months ago.
Build Breadth vs. Depth
When you create a schedule for your project, order the tasks so that your teams are working on the breadth of the project rather than the depth. That is to say, don’t limit the focus to one part of the system to the exclusion of all the other parts. For example, if you’re building a Web-based order entry application, don’t schedule all the UI development tasks to be completed at the same time, followed by all the business logic tasks, followed by the entire database code. Even if you have solid design specs, scheduling your tasks one at a time will cause an integration nightmare. Instead, develop each of these systems simultaneously. Focus on the tasks that allow you to enter a simple order, store it, and display a confirmation. This approach will create your first end-to-end test and will unite the essential software subsystems of the project.
Ask a developer for a schedule of his or her tasks and you’ll often hear something like, "I have to update the resource manager to include support for 32-bit identifiers, fix the PRODUCT_ID index traversal algorithm to allow duplicate entries, and rewrite error handling code to support multiple threads." Although these are all legitimate work items, you must make sure each of these tasks is in the context of a product feature or requirement. When the focus is on the feature, the developer’s task becomes, for example, "support printing from the Order Entry dialog box," or "allow multiple products to be ordered in a single purchase." This narrower focus will also aid the rest of the development team because they need to understand when specific features or requirements will be available, not the specific tasks required to implement them. When your schedule clearly identifies the delivery of each feature or requirement, other team members on the project can make sure their work is completed in parallel.
Not all developers are created equal. Some developers are skilled with user interfaces, some work on core logic. Some have more experience than others. Some will be very productive, whereas others will have average or even poor productivity. You cannot assume that people are interchangeable and that tasks can be randomly assigned. Be very careful when mapping tasks to developers, QA engineers, release engineers, and so on. Consider each person’s skill, personal productivity, project experience, and work habits.
Your goal is to assign the workload of the project as evenly as possible across the project team based on their individual capabilities. Be careful, however, that you don’t assign too much of the workload to your best team members. Although they might be able to do more work than others, even they have a limit. You might also need them to help others when trouble arises.
It’s naive to assume that people will spend 100 percent of their time on their principal assignments. Every organization has overhead. Overhead includes meetings, process requirements, vacations, training, trade shows, sick days, and holidays. Even if you work 80 hours a week, you might find that 10 hours are still spent in these activities. Account for this time in your schedule. In addition to including expected events (vacations and tradeshows and the like) in the schedule, include some flextime for unexpected events like sickness and winter weather.
Slack and Critical Paths
Some tasks have slack and others are on the critical path. Tasks that have slack can be delayed without affecting the overall schedule. Tasks that are on the critical path cannot be delayed without affecting the overall schedule. When you create a schedule, you need to understand which tasks are which. You must monitor the critical path tasks closely, because any slip in their delivery will cause a corresponding slip in the end schedule or more overtime for the team. It’s usually a good idea to put experienced people on critical path tasks to minimize risk to the overall project.
Target Dates vs. Committed Dates
A target date is a proposed date for the project’s delivery. It’s usually based on external market or business conditions. Although this is important information, don’t simply agree to deliver a project on a target date without first creating a schedule. Use the date as a given in the scheduling equation, and then see how you can balance the features and resources to meet it. If the equation does not balance, you’ll need to remove features, add resources, or some combination of both. Your ultimate goal is to build a balanced, realistic, and believable schedule that the entire team can commit to.
Once you have a solid schedule, you must make sure you secure buy-in from the team. A committed date is a date that the entire team agrees to. They believe it is reasonable and achievable. At this point, the development team is making a commitment to deliver the software at a specific time. With startups and large companies alike, there’s a lot of people, money, and time riding on the software’s timely delivery. Once the team commits to a date, it’s critical that the team delivers on time and earns the credibility that comes from meeting obligations.
All too often, development teams are told what their features are, what resources they will have, and what their dates will be. In this situation, the schedule is not owned by the development team but by the organization or person who handed down these edicts. This a formula for major problems. The team will suffer from morale problems because they will feel that they have been put in a situation that sets them up for failure. Having no sense of owner-ship or commitment to the project can take the heart, spirit, and enthusiasm out of a team.
Instead, the development team needs to set its own scheduleor more precisely, maintain the balance that the schedule represents. With this ownership, however, comes responsibility. If the development team owns the schedule, they must make sure they meet their delivery dates. Commitment and credibility are on the line.
Back At Work
At NuMega, there was tremendous pressure to ship products on time. Our target dates were usually key market events such as the release of Microsoft Visual Studio or the introduction of new technologies like Microsoft Windows 95, Microsoft Windows NT, or Microsoft COM. To take advantage of these events, our marketing teams developed comprehensive rollout plans that called for advertising, press briefings, analyst tours, trade shows, and sales training. Hundreds of thousands of dollars were going to be spent on these activities that were based on a software’s delivery date. In addition, our sales teams and senior management were counting on a significant increase in revenue with the delivery of each product. Any delay would not only cost a lot of money and time but also delay sales opportunities and miss market momentum.
To make sure we got the software out in a timely manner, we did our home-work up front, made appropriate tradeoffs on features, time, and resources, and then built realistic schedules based on the target dates. Because of this, the schedules belonged to engineering, not marketing or senior management. But we had to commit to themno matter what. Any mistakes in a schedule were our problem, and we were responsible for figuring out a solution without delaying the release.
One of the biggest problems engineering groups face is the lack of credibility. When an engineering group continually misses its dates, other parts of the organization lose trust in the group. Once credibility is lost, the ability to get buy-in on schedules is compromised, judgment on project tradeoffs is questioned, and all sorts of schedule games (like false target dates or asking for more while expecting less) can creep in. But if you have a history of deliver- ing on time, you can use this credibility to work important project issues, solicit support, and get the benefit of the doubt when you need it most.
Last Updated: Saturday, July 7, 2001