The average software developer, for example, doesn't own a single book on the subject of his or her work, and hasn't ever read one. That fact is horrifying for anyone concerned about the quality of work in the field, for folks like us who write books, it is positively tragic.
The projects most worth doing are the ones that will move you down one full level on your process scale.
The last project generated a ton of paper and it was still a disaster, so this project will have to generate two tons.
If the date is missed, the schedule was wrong. It doesn't matter why the date was missed. The purpose of the schedule was planning, not goal-setting.
Process obsession is the problem. Process obsession is not just an anomaly that occurs now and again. It is an epidemic.
I see design standards that don't tell you how to come up with a good design (only how to write it down), employee evaluation standards that don't help you build meaningful long-term relationships with staff, testing standards that don't tell you how to invent a test that is worth running.
We all tend to tie our self-esteem strongly to the quality of the product we produce - not the quantity of the product, but the quality.
Since the days when computers first came into common use, there must have been tens of thousands of accounts receivable programs written. There are probably a dozen or more accounts receivable projects underway as you read these words. And somewhere today, one of them is failing. Imagine that! A project requiring no real technical innovation is going down the tubes. Accounts receivable is a wheel that's been reinvented so often that many veteran developers could stumble through such projects with their eyes closed. Yet these efforts sometimes still manage to fail.
The documentary obsession of Methodologies seems to have resulted from paranoid defensive thinking along these lines: 'The last project generated a ton of paper and it was still a disaster, so this project will have to generate two tons.' The technological sectors of our economy have now been through a decade-long flirtation with the idea that more and more and more paperwork will solve its problems. Perhaps it's time to introduce this contrary and heretical notion: Voluminous documentation is part of the problem, not part of the solution.
During the past year, I did some consulting for a project that was proceeding so smoothly that the project manager knew she would deliver the product on schedule. She was summoned in front of the management committee and asked for a progress report. She said she could guarantee that her product would be ready by the deadline of March 1, exactly on time according to the original estimate. The upper managers chewed over that piece of unexpected good news and then called her in again the next day. Since she was on time for March 1, they explained, the deadline had been moved up to January 15.