Creating the schedule for a project can often be one of the most difficult and politically charged aspects of the entire project. Schedule the project correctly, and you'll have an effective tool to manage the project. Schedule the project poorly, however, and no matter how hard the team works, the effort will be perceived a failure if the software is delivered late. Although scheduling a project is notoriously difficult, understanding the principles of good scheduling can often make the difference between fabricating dates and developing a realistic time estimate.
In this chapter I'll detail the information you'll need to build a schedule, discuss the most important scheduling concepts, and show you how to create an accurate and realistic schedule.
Before you build a schedule, you need to understand your project's require-ments, technology, and user interface. Figure 11-1 shows the elements involved in creating a schedule. Once you understand these fundamental aspects of your project, you should have an excellent idea of what you're trying to build and how it will work.
Click to view graphic (Image not available)
Figure 11-1 Critical input to the scheduling process
However, if you haven't defined your project's basic requirements, prototyped its biggest technical risks, or created a model of its user interface, you simply do not have enough information to create an accurate schedule. You won't be able to enumerate the tasks involved or estimate accurately how long each of them will take. Your schedule will be filled with vague tasks that are too broad to track or measure, and because of this, your schedule won't be trustworthy. It will be thrown aside at the first sign of trouble, and you'll be left without any way of managing the delivery of your project.
Scheduling Concepts and Issues
In order to create your own schedule or review one created by others, you must have a solid understanding of basic scheduling concepts. In this section, I'll discuss the fundamental concepts everyone involved in the scheduling process must understand. In addition, I'll provide an overview of the most important personnel issues involved with creating a schedule. And lastly, I'll cover some of the most common scheduling problems that development teams face.
The following concepts are fundamental to the creation of reliable schedules.
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:
- Development The software engineering portion of the schedule should provide enough time for the product's feature development, unit testing, and debugging. Additional time should be allocated for the development team to review materials produced by the QA and user education teams, and potentially the human factors and release engineering teams as well.
- Quality assurance The QA portion of the schedule should provide enough time for the development of test plans and test scripts, and for the testing of the infrastructure itself. Additional time should be allocated for integration testing of each milestone in the schedule.
- User education The user education portion of the schedule should provide enough time for the development of the documentation, online help, and tutorial. Additional time should be allocated for any copyediting and proofreading that might be necessary. And don't forget technical reviews with team members.
- Human factors The human factors portion of the schedule should provide enough time for the design and evaluation of a detailed user interface. There should also be time for an evaluation of the product's graphic material, an internal and external review of the user interface, and a documentation review. Testing the "out of the box" experience should also be included in your schedule.
- Release engineering The release engineering portion of the schedule should provide enough time for build system development, installation development, and configuration and maintenance of the source code management system.
- External dependencies Your schedule should also provide whatever time is necessary to account for any external dependencies that your project might have, including the delivery or use of third-party software, capital equipment availability, or even the arrival of new employees or the support of other teams.
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.
The following are some of the personnel issues involved in schedule creation.
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.
Pitfalls Every Team Must Avoid
The following are some of the most common scheduling problems development teams encounter.
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.
Building a Great Schedule
Now that I've covered the basic scheduling concepts, let's focus on the details of building a great software schedule. The process has three basic steps: defining the tasks, grouping them into base levels, and grouping the base levels into project milestones.
Later in this chapter I'll provide an example of a typical schedule that describes the basic project structure you need to manage. As you will see, however, the goal is not to micromanage every detail of the project. You can't possibly know what someone will be doing on a specific date six months from now. Instead, you want a schedule that enumerates a set of well-defined deliverables that occur regularly throughout the development cycle. With this in place, you can manage the team toward each deliverable and mark and measure your progress with certainty.
Your first step is to define all the tasks required to implement a specific feature. The total time it takes to complete these tasks is the time it will take to complete the feature. Schedule the features from the list of must-have requirements first and then move to the should-haves and could-haves. This method will help you achieve a viable release as soon as possible.
After that, schedule the QA, user education, UI, and release engineering teams' tasks. Each team will have their own set of work items based on their own project deliverables, and those tasks should be organized so they integrate with or follow closely behind the implementation of the features by the software engineers.
Base levels define the delivery date for a group of related features. They should occur every two to three weeks. Remember, these features must be both available through the installation procedure and usable by the development team. Base levels are important short-term objectives to focus the team's attention and effort. To a large extent, nothing matters more than completing the next base level on time. If you don't hit the next base level, your project is officially behind schedule and you need to take corrective action immediately. The following are some sample base levels (from NuMega's error detection product, BoundsChecker):
- A source code library and nightly build are established, and a bare bones installation procedure is completed.
- The product hooks and logs basic memory functions.
- The product displays first memory error message using the UI prototype.
- The product successfully detects memory leak types 1 and 2.
- The product successfully detects memory leak types 3 and 4.
- The product successfully detects memory leak types 5 and 6.
- The product's real UI appears, but without print, sort, and filter support.
- Print, sort, and filter support is complete.
- The product integrates with other products in the suite.
A milestone is a group of base levels that represent the completion of a significant portion of the product. They should be evenly divided across the duration of the project. For example, if you defined four milestones for your project, each one would represent 25 percent completion. Obviously, the more complex the project, the more frequent your milestones.
Each milestone should have a stabilization and integration period, as discussed in Chapter 6. To review, this is a period of time, usually one to two weeks, during which the entire team focuses on addressing issues that have surfaced in the features that have already been implemented. These periods during which testing is done, bugs are fixed, design and integration issues are addressed, and performance is evaluatedare critical to the project because they allow the software to stabilize. Do not move forward into new feature development until you're certain that the current features are functioning well. In addition, stabilization periods are also a great time to catch up on any work that has been delayed. This period offers the team a time for individuals or sub-teams to catch up with the rest of the team and get back in sync.
External milestones involve people or teams outside the project and mark critical points in the project. The most common external milestones include:
- Alpha release This is a release with only a few critical features implemented. Alpha releases are not widely used, but they can be beneficial if you need to show progress or get feedback on critical features externally.
- Beta release This is a release with most, if not all, of the features implemented. Beta releases are given to customers for testing and evaluation.
- Release candidate (RC) This is a release you intend to send to manufacturing if testing is completed successfully. Release candidates are a signal that the project is nearly done and its release is imminent.
- Release to manufacturing date (RTM) This is the date on which the production release will be sent to manufacturing (or posted to the Web, whatever the case might be).
Each external milestone requires the software to be distributed to people outside the team and even outside the company. Because of the importance of these events, you should have a stabilization period before each milestone. This allows your team to focus on quality, integration, and important fit and finish issues before the product is released. The beta release and release candidate are critically important and will be discussed in detail in Chapters 13 and 14....