James McGovern comes right to the point on the project management overhead which is currently embraced as the way to do everything from opening a can of beans to putting a man on Mars.
Why on earth is so much process present? Why does it take three documents and six meetings to write six lines of Java? There are twice as many pages of documentation as lines of code! Well, having worked with the people involved on these documents, plus the development, and the testing, not just on this project but several others, I think I've figured out the purpose: process is being used as a substitute for competence. The funny thing is that I too am losing my sense of humor and are starting to become borgified and believe that CMMi is the perfect way to use process as a substitute for competence. With enough steps, documents, design reviews, and test plans, I think that the proverbial 1,000 monkeys with typewriters really could produce a functional IT system. The incredible amount of mutual reinforcement breaks the task down into such minute pieces that each piece is comprehensible and completable by anyone with even the slightest modicum of coding or testing ability. The added advantage is that no one is required to think let alone understand. It even helps project managers to a pretty good degree of accuracy how long each minute task will take, and can thus do a pretty good job coming up with a (obscenely long) timeline for a project in any stage of development.
Things that are worth five minutes conversation between principals involve battalions of portfolio, programme, project managers and their panoply of governance police without consideration of the competence of the few people that actually do the creative stuff or the fact that the individual commissioning the work has the authority and responsibility to do just that. To move on from the 1970's waterfall, we need clear but much shorter chains of commands along the lines of Jean Luc-Picard "Make it, so!" to a small team of competent players responding "Yes, sir"