Fatbrain Review A fundamental software engineering project management guide based on the practical requirements of "Taming Wild Software Schedules." Emphasizes possible, realistic and "best practice" approaches for managers, technical leads and self-managed teams. The author emphasizes efficient development concepts with an examination of rapid development strategies and a study of classic mistakes, within the context of software-development fundamentals and risk management. Dissects the core issues of rapid development, lifecycle planning, estimation and scheduling. Contains very good and practical discussions of customer-oriented development, motivation and teamwork. Explains such fundamental requirements as team structure, feature-set control (the dreaded feature creep in every project), availability and use of productivity tools and project recovery options. Relevant case studies are analyzed and discussed within the context of specific software development problems. Over 200 pages in this publication are devoted to a summary of best practices, everything from the daily build and smoke test, through prototyping, model selection, measurement, reuse, and the top-10 risks list.
This publication is definitely recommended and will become a classic in the field, just as the author's prior publication, Code Completealready is.
Read an Excerpt
From Chapter 9: Beating Schedule Pressure
Focus on Interests, Not Positions
Suppose you're selling your car in order to buy a new boat, and you figured that you need to get $5000 for your car in order to buy the one you want. A prospective buyer approaches you and offers $4500. You say, "There's no way I can part with this car for less than $5000." The buyer says, "$4500 is my final offer."
When you negotiate in this way, you focus on positions rather than interests. Positions are bargaining statements that are so narrow that in order for one person to win, the other person has to lose.
Now suppose that the car buyer says, "I really can't go over $4500, but I happen to know that you're in the market for a new boat, and I happen to be the regional distributor for a big boat company. I can get the boat you want for $1000 less than you can get it from any dealer. Now what do you think about my offer?" Well, now the offer sounds pretty good because it will leave you with $500 more than you would have gotten if the buyer had just agreed to your price.
Underlying interests are broader than bargaining positions, and focusing on them opens up a world of negotiating possibilities. Your boss might start out by saying, "I need a Giga-Blat 4.0 in 6 months," and you might know immediately that you can't deliver it in less then 9 months. Your boss's interest might be keeping a promise made to the sales organization, and your interest might be working less then 60 hours a week for the next 6 months. Between the two of you, you might be able to create a product that would satisfy the sales organization and would be deliverable within 6months. If you focus on interests, you're more likely to find a win-win solution than if you dig into bargaining positions.
One of the major problems with schedule negotiations is that they tend to become one-dimensional, focusing only on the schedule. Don't get dug into a position. Make it clear that you're willing to consider a full-range of alternatives--just not pie-in-the-sky options. If other people have dug themselves into demanding a specific schedule, here are some points you can use to dislodge them:
Appeal to true development speed. Point out that the worst fault of overly optimistic schedules is that they undermine actual development speed. Explain the negative effects of overly optimistic scheduling that were described in Section 9.1. True rapid development requires that you be firmly connected to reality, including to a realistic schedule.
Appeal to increasing the chance of success. Point out that you have estimated the most likely completion date and that you already have only a 50/50 chance of meeting that. Shortening the schedule will further reduce your chances of completing on time.
Invoke your organization's track record. Point to your organization's history of underestimating projects, coming in late, and all the problems that lateness has caused. Appeal to the other person's good sense not to do the same thing again.
Invent Options for Mutual Gain
Rather than thinking of negotiating as a zero-sum game in which one person wins at the other's expense, think of it as an exercise in creative problem-solving; the truly clever negotiator will find a way for both parties to win.
Your most powerful negotiating ally in schedule negotiations is your ability to generate options that the other person has no way of knowing about. You hold the key to a vault of technical knowledge, and that puts the responsibility for generating creative solutions more on your shoulders than on the nontechnical person you're negotiating with, It's your role to explain the full range of possibilities and trade-offs.
I find it useful to think about how many degrees of freedom there are in planning a software project. The basic degrees of freedom are defined by the schedule, cost, and product triangle. You have to keep the three corners in balance for the project to succeed. But there are infinite variations on that triangle, and the person you're negotiating with might find some of those variations to be a lot more appealing than others. Here are some of the degrees of freedom you might suggest related to the product itself:
Here are some degrees of freedom related to project resources:
- Move some of the desired functionality into version 2. Few people need all of what they asked for exactly when they asked for it.
- Deliver he product in stages--for example, versions 0.7, 0.8, 0.9, and 1.0--with the most important functionality coming first.
- Cut features altogether. Features that are time-consuming to implement and often negotiable include the level of integration with other systems, level of compatibility with previous systems, and performance.
- Polish some features less-implement them to some degree, but make them less fancy.
- Relax the detailed requirements for each feature. Define your mission as getting as close as possible to the requirements through the use of prebuilt commercial components.
- Add more developers, if it's early in the schedule.
- Add higher-output developers (for example, subject-area experts).
- Add more testers.
- Add more administrative support...