The Real Estimation Process
"I'm a software developer. I write programs in an object-oriented language called C# (pronounced ‘C-sharp'). I'm a skilled object-oriented designer, too. I should be-I've been at it 12 years and worked on major projects for several software companies.
For the last 4 years, I've been a team leader. I lived through the heyday of the dot-com era and now work in the development group at an iPad application vendor. "All of this estimating theory is just that- theory. It's not really the way things work. Sure, I've been on projects in which we tried different estimation techniques. But here's what really happens: You develop an estimate using whatever technique you want. Your estimate goes in with the estimates of all the other team leaders.
The project manager sums all those estimates together and produces an overall estimate for the project. "By the way, in my projects, time has been a much bigger factor than money. At one software company I worked for, you could be 300 percent over your dollar budget and get no more than a slap on the wrist. Be 2 weeks late, however, and you were finished.
"Anyway, the project managers take the projects schedule to senior management for approval, and what happens? Senior management thinks they are negotiating. ‘Oh, no,' they say, ‘that's way too long. You can surely take a month off that schedule. We'll approve the projects, but we want it done by February 1 instead of March 1.' "Now, what's their justification? They think that tight schedules make for efficient work.
You know that everyone will work extra hard to meet the tighter timeframe. They know Parkinson's Law- ‘the time required to perform a task expands to the time available to do it.' So, fearing the possibility of wasting time because of too-lenient schedules, they lop a month off our estimate. "Estimates are what they are; you can't knock off a month or two without some problem, somewhere. What does happen is that projects get behind, and then management expects us to work longer and longer hours. Like they said in the early years at Microsoft, ‘We have flexible working hours.
You can work any 65 hours per week you want.' "Not that our estimation techniques are all that great, either. Most software developers are optimists. They schedule things as if everything will go as planned, and things seldom do. Also, schedulers usually don't allow for vacations, sick days, trips to the dentist, training on new technology, peer reviews, and all the other things we do in addition to writing software. "So we start with optimistic schedules on our end, then management negotiates a month or two off, and voilà, we have a late project.
After a while, management has been burned by late projects so much that they mentally add the month or even more back onto the official schedule. Then both sides work in a fantasy world, where no one believes the schedule, but everyone pretends they do. "I like my job. I like software development. Management here is no better or worse than in other places. As long as I have interesting work to do, I'll stay here. But I'm not working myself silly to meet these fantasy deadlines."
Discussion Questions
1. What do you think of this developer's attitude? Do you think he's unduly pessimistic or do you think there's merit to what he says?
2. What do you think of his idea that management thinks they're negotiating? Should management negotiate schedules? Why or why not?
3. Suppose a project actually requires 12 months to complete. Which do you think is likely to cost more: (a) having an official schedule of 11 months with at least a 1-month overrun or (b) having an official schedule of 13 months and, following Parkinson's Law, having the project take 13 months?
4. Suppose you are a business manager and an information system is being developed for your use. You review the scheduling documents and see that little time has been allowed for vacations, sick leave, miscellaneous other work, and so forth. What do you do?
5. Describe the intangible costs of having an organizational belief that schedules are always unreasonable.
6. If this developer worked for you, how would you deal with his attitude about scheduling?
7. Do you think there is something different when scheduling information systems development projects than when scheduling other types of projects? What characteristics might make such projects unique? In what ways are they the same as other projects?
8. What do you think managers should do in light of your answer to question 7?