Under Pressure and on Time

Overview

How do you hire-and keep-the best software engineers in the business? What real-world practices can really motivate a team to produce excellent results? From startups to major corporations, virtually every commercial software company struggles with building teams and shipping great software on time. Now industry expert Ed Sullivan shares the hard-won lessons and best practices from his 17-year career in software development, including six years at award-winning NuMega ...
See more details below
Available through our Marketplace sellers.
Other sellers (Paperback)
  • All (20) from $1.99   
  • New (3) from $12.48   
  • Used (17) from $1.99   
Close
Sort by
Page 1 of 1
Showing 1 – 2 of 3
Note: Marketplace items are not eligible for any BN.com coupons and promotions
$12.48
Seller since 2008

Feedback rating:

(169)

Condition:

New — never opened or used in original packaging.

Like New — packaging may have been opened. A "Like New" item is suitable to give as a gift.

Very Good — may have minor signs of wear on packaging but item works perfectly and has no damage.

Good — item is in good condition but packaging may have signs of shelf wear/aging or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Acceptable — item is in working order but may show signs of wear such as scratches or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Used — An item that has been opened and may show signs of wear. All specific defects should be noted in the Comments section associated with each item.

Refurbished — A used item that has been renewed or updated and verified to be in proper working condition. Not necessarily completed by the original manufacturer.

New
073561184X BRAND NEW NEVER USED IN STOCK 125,000+ HAPPY CUSTOMERS SHIP EVERY DAY WITH FREE TRACKING NUMBER

Ships from: fallbrook, CA

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
$50.00
Seller since 2014

Feedback rating:

(162)

Condition: New
Brand new.

Ships from: acton, MA

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
Page 1 of 1
Showing 1 – 2 of 3
Close
Sort by
Sending request ...

Overview

How do you hire-and keep-the best software engineers in the business? What real-world practices can really motivate a team to produce excellent results? From startups to major corporations, virtually every commercial software company struggles with building teams and shipping great software on time. Now industry expert Ed Sullivan shares the hard-won lessons and best practices from his 17-year career in software development, including six years at award-winning NuMega Technologies.

In Under Pressure and on Time, Sullivan describes a proven model for creating, directing, and growing a world-class development team. Discussion includes recruiting, interviewing, company culture, scheduling, release engineering, tools, key processes, beta management, project status, project closure, and other critical topics for which-until now-frustratingly little information has been published.

But Under Pressure and on Time digs one level deeper than other project management books, delivering the fire-tested practices and essential how-to's that help you lead software teams to greatness.

Read More Show Less

Editorial Reviews

From Barnes & Noble
The Barnes & Noble Review
For all the talk of "manufacturing" software through "standard components," the fact remains: Great software is built by talented people working together well.

Leading great software teams is an art and a science, and in a brutally competitive marketplace, it just doesn't get easier. If there's any consolation, you're not alone. Perhaps it's more of a consolation to know there's actually some help available: Under Pressure & On Time by Ed Sullivan.

Sullivan's been in the trenches for nearly two decades. These days, he leads NuMega Labs' development center (they've shipped more than 30 products, 90 percent of them on time). His book thoroughly demystifies every phase of software leadership: creating your team, directing it, and delivering the results that keep it thriving.

You'll find coverage of recruiting and interviewing to get the right people -- and retaining them. (It's about more than providing munchies and air hockey tables.) There's also specific, expert guidance on the vital day-to-day stuff nobody ever writes about: scheduling, betas, release engineering, and so forth.

Most software team leaders and IT managers "rose from the ranks" of developers. Nobody taught them how to lead. Ed Sullivan will. (Bill Camarda)

Bill Camarda is a consultant and writer with nearly 20 years' experience in helping technology companies deploy and market advanced software, computing, and networking products and services. His 15 books include Special Edition Using Word 2000 and Upgrading & Fixing Networks For Dummies®, Second Edition.

Booknews
Sullivan (engineering director for a private company) describes a model for creating, directing, and leading a successful software development team. He outlines specific techniques and describes established practices. Advice is offered on recruiting and retaining personnel, building the right organizational structure, and creating the right corporate culture for software development. Project planning, execution, and closure are all detailed, and the necessary tools and methods identified. Annotation c. Book News, Inc., Portland, OR (booknews.com)
Read More Show Less

Product Details

  • ISBN-13: 9780735611849
  • Publisher: Microsoft Press
  • Publication date: 5/4/2001
  • Pages: 273
  • Product dimensions: 7.33 (w) x 9.17 (h) x 0.92 (d)

Meet the Author

Ed Sullivan is currently the Director of Engineering for NuMega Labs of Compuware. He manages more than 140 people and a product line of $25 million growing at over 60% annually. His responsibilities include the development, quality assurance, documentation, and usability of the products. He also has overall responsibility for recruiting, organization, processes, tools, and standards within the organization. He is justifiably proud of hiring the best engineers in the industry and of shipping more than 30 products with a 90% on-time delivery rate and industry-leading reviews and sales. Before joining NuMega, Ed spent eleven years at Digital Equipment.
Read More Show Less

Read an Excerpt

11: Scheduling

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.

Prerequisites

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.

Fundamental Concepts

The following concepts are fundamental to the creation of reliable schedules.

Balance

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 balance—or worse, if you are given a set of constraints that cannot be balanced—you 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 estimate—an educated guess—about 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 project—every 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.

Parallel Development

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.

Feature Contexts

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.

Personnel Issues

The following are some of the personnel issues involved in schedule creation.

Task Assignments

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.

Leveling

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.

Overhead

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.

Schedule Ownership

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 schedule—or 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 them—no matter what. Any mistakes in a schedule were our problem, and we were responsible for figuring out a solution without delaying the release.


Engineering Credibility

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.

Tasks

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

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.

Intermediate Milestones

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 evaluated—are 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

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....

Read More Show Less

Table of Contents

Foreword ..... ix
Acknowledgments ..... xiii
Introduction ..... xv
I: People, Organization, and Methods
1: Great People and How to Find Them ..... 3
2: Résumés, Interviewing, and Retention ..... 21
3: Project Organization ..... 41
4: Ranking and Culture ..... 61
5: Software Tools ..... 75
6: Fundamentals of Quality Assurance ..... 99
7: Release Engineering Fundamentals ..... 123
II: Project Definition and Planning
8: Requirements ..... 139
9: Research, Evaluation, and Prototyping ..... 157
10: User Interface ..... 171
11: Scheduling ..... 185
III: Project Execution
12: Staying on Course ..... 205
13: Beta Testing ..... 221
14: Release Candidates ..... 237
15: Project Closure ..... 247
Index ..... 257
Read More Show Less

First Chapter

Chapter 11.

Scheduling

  • Prerequisites
  • Scheduling Concepts and Issues
    • Fundamental Concepts
    • Personnel Issues
    • Pitfalls Every Team Must Avoid
  • Building a Great Schedule
    • Tasks
    • Base Levels
    • Intermediate Milestones
    • External Milestones
    • An Example
    • Beta Testing Additions
    • Unexpected Problems
  • Common Problems and Solutions
    • It’s Always Wrong
    • It’s Harder Than It Looks
    • It’s Out of Sync

11 Scheduling

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.

Prerequisites

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.

Figure 11-1 Critical input to the scheduling process (Image unavailable)

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.

Fundamental Concepts

The following concepts are fundamental to the creation of reliable schedules.

Balance

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 balance—or worse, if you are given a set of constraints that cannot be balanced—you 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 estimate—an educated guess—about 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 project—every 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.

Parallel Development

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.

Feature Contexts

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.

Personnel Issues

The following are some of the personnel issues involved in schedule creation.

Task Assignments

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.

Leveling

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.

Overhead

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.

Schedule Ownership

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 schedule—or 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 them—no matter what. Any mistakes in a schedule were our problem, and we were responsible for figuring out a solution without delaying the release.


Engineering Credibility

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.

Tasks

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

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.

Intermediate Milestones

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 evaluated—are 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

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.

An Example

To make sure you’ve understood the basics, let’s walk through a detailed example, shown in Table 11-1 on page 184. Although I’ve simplified the project and eliminated information that would normally be included, this example should be detailed enough to show you how everything fits together. The following are the basic scheduling assumptions for this example.

  • Scheduling principles
    • Each feature has a list of engineering tasks associated with it. They are not shown in the example but could be easily listed in the document. A single task can’t be any longer than two weeks; most should be one week or less. Must-have features are done first, based on requirement prioritization, and the less important features are done later.
    • QA tests the features as soon as they are delivered by development. Some features will have automation, but all other features will be manually tested. The details of testing activities are described in a QA plan.
    • User education documents features as soon as they are delivered. The documentation effort follows the features delivery as much as possible. The details of this effort are described in a user education plan.
    • Human factors evaluates each UI feature implementation as soon as it’s completed, consults on changes, and reviews the product experience as the project is developed. The details of this effort are described in the human factors plan.
    • Release engineering will create a simple build and installation procedure immediately, and then increase the features and robustness of the build and installation procedure regularly over the course of the release. They also support the inclusion of a new feature when it is ready. These specific feature and capability improvements will be described in the release- engineering plan.
  • Personnel
    • Matt: dev lead and full time developer
    • John: software engineer
    • Jim: QA lead; also writes automation
    • Frank: QA specialist; executes the automation and manual tests features
    • Sarah: user education lead
    • Kenny: human factors lead
    • Bob: release engineering lead
  • Milestones, internal and external
    • There will be four bi-monthly base levels, two major milestones, two betas, one RC period, and one RTM.
    • Every two base levels will form a milestone. Milestone 1 will represent half the project’s completion; Milestone 2 will represent the other half.
    • Table 11-1   A Sample Schedule

      Date Goal Dev Team   QA Team  
          Matt John Jim Frank
      Jan 01   (White space indicates work has started on next task.)      
      Jan 08 Base level 1 F1 F2 A1 T2
      Jan 15          
      Jan 22 Base level 2 F3 F4 A3 T4
      Jan 29   F5      
      Feb 05 Milestone 1 Integration and stabilization period      
      Feb 12     F6   T6
      Feb 19 Base level 3 F7   A7  
      Feb 26          
      Mar 05 Base level 4 F8 F9 A8 T9
      Mar 12          
      Mar 19 Milestone 2 Integration and stabilization period      
      Mar 26          
      Apr 02 Base level 5 F10 F11 A10 T11
      Apr 09   F12 F13 A12 T13
      Apr 16 Beta 1 prep Test for beta 1 readiness.      
      Apr 23
      May 21
      Beta 1 F14, F15. Fix, tune, and make minor enhancements.   A14, A15. Improve automation and test according to QA plan.  
      May 21 Beta 2 prep Test for beta 2 readiness.      
      May 28
      to Jun 25
      Beta 2 Bug fix. Tune. Make minor enhancements.   Improve automation and test according to QA test plan.  
      Jul 02 RC Execute release candidate process.      
      Jul 16 RTM Project closure      

      # (Number) = Feature identification number

      F = Feature is coded and unit tested, all engineering tasks associated with it are complete.

      A = Feature has test automation

      User Ed Team Usability Team Release Engineering Team
      Sarah Kenny Bob
          Complete simple builds and install
      D1 U1  
      D2 U2  
      D3 U3, U4  
      D4, D5 U5 Better build and install according to release engineering plan
           
      D6    
        U7  
      D7    
      D8, D9 U8, U9  
      Vacation   Great build and install according to release engineering plan
           
           
      D10, D11 U10, U11  
      D12, D13 U12, U13 Full featured install
           
      Document activities according to doc plan Final review: external testing, OOTB evaluation  
           
      Document activities according to doc plan Visual freeze Final install
           
           

      T = Feature has been maually tested

      D = Feature has been documented

      U = Feature has had its usability review

    • Beta 1 will be one month long. Features F14 and F15 will be added during beta 1, but the rest of the time will be spent on testing, tuning, and fixing bugs. Each team member has a specific list of activities during the beta 1 time period.
    • Beta 2 will have no new features. No major feature changes are allowed—just testing, tuning, and bug fixing. There is a specific list of activities for each team member during this time period.
  • Release candidate
    • A release candidate will be built at the end of beta 2 if testing has been completed without major problems.
  • Status meetings
    • A meeting will be scheduled every Monday to review progress. If a base level is not completed on time (or it appears that it won’t be), changes required to get the project back on schedule will be made.

Beta Testing Additions

In the example, you’ll notice that two tasks are scheduled for delivery during the first beta period. Although you want to refrain from adding features—particularly important or complex features—during any beta period, it sometimes makes sense to schedule a set of low-cost and relatively low-risk features for the first beta. The longer you delay putting your product in the hands of your beta customers, the longer it will take to receive feedback on the quality and the implementation of your features. The benefits of sending your product through a beta cycle earlier can often outweigh the risks of adding minor features after the beta program has started.

Although adding a few features into the first beta period is sometimes acceptable, no new features should be scheduled for the last beta period. The final beta period is a time in which features are locked down and the team focuses on quality, performance, and fit and finish problems. Beta testing will be covered in detail in Chapter 13.

Unexpected Problems

If you have created a schedule using the principles in this chapter, you probably have planned your project as well as anyone could. However, software development is an imperfect science and problems are always nearby. You’ll need to check your project’s progress against your schedule regularly and compare your actual progress against each base level and milestone to see if you’re on track. If you’re off schedule you’ll need to identify the problem, update the schedule, and hit your next base level or milestone. Sound simple? It’s not—and this is where the project manager and the leads need to be on top of their game. Due to the complexity of keeping a project on schedule, I’ve devoted most of Part III to the subject.

Common Problems and Solutions

The following are some of the typical problems and questions that surface when applying these techniques, and some solutions to those problems.

It’s Always Wrong

Creating a solid schedule takes a lot of effort, so it’s easy to understand why some teams aren’t willing to do it. Often, the people who are the most reluctant have tried to use schedules in the past but had to abandon them early in a project because of all of the unexpected problems that surfaced. When a schedule doesn’t reflect reality, it will be largely ignored.

There’s no question that scheduling is a difficult exercise, but it is an essential step. You are creating the roadmap for your project. If you need to ship on time, you must understand the work you have before you and the amount of time it will take to get it done. The techniques I have outlined in this book will make scheduling easier, more predictable, and less risky.

It’s Harder Than It Looks

It seems so simple to break tasks down into time frames of one or two weeks, but it can be a real challenge. There always seems to be a three-week, four-week, or five-week task in the schedule. If you have a task that takes this long, break it down into smaller tasks. If you measure your progress in smaller time frames, you can see deviations from the plan earlier. If it’s too difficult to subdivide a task, you probably don’t understand it very well—a sign of significant risk. You need to prototype a solution to get a better understanding of the work.

It’s Out of Sync

You need to have synchronization periods in your schedule. In addition to stabilizing the software, they provide opportunities for the rest of the project teams to catch up. You can’t predict all your problems ahead of time, but you can predict that you will have some. Allocate time in your schedule for them—whatever they might be.

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)