Software Best Practices

Sometimes

Sure everyone is concerned when commitments to the customers and rest of the company aren't met. Everyone wants to improve and make this easier.

This is basically true too. Although, I wonder again if this really refers to the committed date or the estimate. I guess practically spekaing most projects only have the one estimated/committed date and they're the same thing. The project committed dates are usually adjusted very late in the project...

I've experienced this one. Senior engineering managers have said that they expect managers to be able to estimate for their engineers. Once they get a sense of their velocity they can begin to make estimates. Product target delivery dates need to be driven by upper management. This is a reasonable...

Most software estimates are made either by upper management or by marketing, not by the people who will build the software or their managers. Estimation is, therefore, done by the wrong people.

Most software estimates are performed at the beginning of the life cycle. This makes sense until we realize that estimates are obtained before the requirements are defined and thus before the problem is understood. estimation, therefore, usually occurs at the wrong time.

One of the two most common causes of runaway projects is poor estimation.

The next several facts are about estimation so I'm posting them all at once. I'd be interested to hear the many different ways these facts have been overcome in industry. Anyone reading this can chime in. No one has to read the book to participate in this thread.