Shipping Software On Time
Planted 02024-06-05
The following is a partial transcription of notes from a 1991 videotaped talk referenced in chapter 010. Our BillG Review in the book Hardcore Software by Steven Sinofsky.
Chris Peters has been at Microsoft since December 1981. The following is a compilation of notes taken by individuals who attended Chris’ Tech Talk to developers in January 1991 and a similar presentation is available to check out through the MS Corporate Library, or order tape #237 by emailing msstudio.
The case study discussed in this presentation is Microsoft Excel 3.0 for Windows, which shipped just 11 days later than scheduled one year prior. At that time, Chris was the Development Lead for the project.
Role of individuals within business units
Everyone in the business unit has the same job. That job is to SHIP PRODUCTS. It doesn’t matter if you are in development, test, program management, user education, or product management; your job is not to code, not to test, not to manage, not to go to meetings. The job description of everyone is the same “ship products.” An expansion of this statement is “ship products EXACTLY ON TIME.” Every day you should do what you can to maximize that goal.
Desirability of fixed ship dates
Eliminate the term “target ship date.” It implies no commitment. It undermines the central goal we should all have, which is to ship a quality product on time. There are many variables in a project schedule which should be variable but the ship date is not one of them.
Fixed ship dates:
- Force creativity
- Force decision making
- Require complete and total commitment by the entire business unit
Work towards fixed schedule dates in the following way:
- Don’t try to have a schedule until you have a spec
- Get line individuals to estimate their own schedules so they have higher commitment to making the dates
- Add buffer time to account for the unexpected
- Set 3-month milestones to buy into the fixed date and milestone dates up front
Don’t let features creep in. There will always be another release. You should already be convinced you’ve got a good product. If the feature is really desirable, trade it for one you’ve already got planned. The difference between twenty new features and twenty-one new features isn’t going to make or break your product, but it will make you miss your date. Will the product flop without the twenty-first feature? If not, do not slip the schedule in order to get it in.
Set milestones. Big milestones make the date seem closer and give opportunities to adjust the schedule. People can be motivated to meet a date eight weeks out much better than fifty-two weeks. Don’t bother to adjust the schedule until the milestone is completed.
The importance of clear goals
Keep the goals simple. By concentrating on a date, getting everyone in the business unit to be committed to the date, and making that the essential goal, everyone is striving for the same thing. Clear goals include what the product is and, also, what is product is NOT. Simple goals help in communication.
For Excel 3.0, the goal was “sexy, cool features with an emphasis on graphics.” The Excel team wrestled with the idea of putting 3D spreadsheets into the product. This was a difficult decision, since Lotus was using this feature as a key differentiation point. The answer was ultimately “no” for a simple reason: added 3D did not help the goal. If the goal said “great analytical capabilities with an emphasis on consolidation” then 3D would clearly have been in, and many features that ended up in Excel 3.0 would clearly have been out. The whole team must have clear goals to ship software on time.