On Product Development and More...

As I wrote in a recent posting, Failure is Not an Option, the Standish Group recently published its latest CHAOS report identifying the factors driving success for IT projects (see article "CHAOS Summary 2009").

For those like me who have never worked in IT, it's a bit puzzling to see such high failure rates on projects. So what's going on here?

Michael Hugos recently wrote an article in CIO entitled "The Sorry State of Project Managers and Business Analysts" that helps to explain the cause of IT project failure.

According to Hugos, the project manager and business analyst are not doing their jobs. He states:

"Most PMs seem to be doing little more than project bookkeeping and updating preposterous, often ponderous and usually incomprehensible documents politely referred to as project plans and progress reports. And BAs have become people who are little more than note-takers at rambling meetings (think of every Dilbert comic strip you've ever seen) who attempt to use their notes to create requirements using a barely understood technique called UML (unified modeling language) that creates long, wordy documents too technical for business people to understand and not technical enough for programmers to work from."

As I noted above, I have never worked in IT. But I have worked in a number of software product companies and have yet to see a project fail. On every software product release, there are 4 critical roles: Program Manager, Product Manager, Development Manager and QA Manager (of course, on smaller projects, one person can wear multiple hats and be assigned multiple roles).

I cannot imagine a software product release being successful without having talented individuals in each of those roles - particularly for the roles of Program Manager and Product Manager. To paraphrase Hugos, the Program Manager is the "pilot who steers the release toward success as it moves along and unexpected things happen" and the Product Manager is the "navigator who defines the business requirements" and serves as the voice of the customer. Without those individuals driving projects, failure is just about assured.

I suppose the real question is why would IT management allow the key roles on a project to not do their job? He suggests that these roles have mostly turned into "low level staff positions" that do not have the power and authority to do their jobs. He goes on to suggest that, "if either of them were to actually speak out or take a hard stand on an issue, they're likely to get fired". Simply amazing.