.. it's not about a person, but about the process
This morning I came across an article by Amit Sarkar "Top Ten Reasons Why A Project Fails And What You Can Do To Change" and it triggered me to write a long comment to that. I don't know if anyone will ever read it as nothing appeared on the site. Might need moderation. Still I copied what I had typed into the box to reproduce it here. And the added some more text here and there.
First I suggest to hop over read the article.
Having been involved in quite a number of projects myself I think that I can honestly say that you are clearly a project manager that works according to the book. The problem is that the book is not correct. Or it might be the not the correct book. The Bible is not the best source of knowledge for project managers, nor is the Koran. Nor Harry Potter.
I will not break down all your 10 points.
But the biggest mistake in managing IT projects is the misconception that everything can be known at the beginning of a project. Requirements are never completely clear and will change during the project because of changing insights and demands from other systems.
Same goes for risks. Some can be identified ahead, but most risks are only becoming clear when the projects moves ahead and bumps into related systems that have limited possibilities.
It all sounds too familiar
Image via Wikipedia
The solutions you propose are related to the 'good old' waterfall model and that is no longer a best practice in IT world, if it ever was. Nowadays we would like to work in iterations taking small steps to make things work a bit and have close commitment from all team members and the project owner, the stakeholder or at least someone who can and will take decisions and who is a member of the project team as well. That way progress can be made in short cycles and the stakeholder is always involved and knows every step of the way.
Typically in such a process it is not known what comes out at the end. You might think beforehand that you need a better mobile phone and end up with something like Twitter.
Then ... what
IMHO a project manager is a facilitator for the project team. The project manager makes it possible for the team to do their work. At best he goes around serving coffee.
I have seen project managers who spend a lot of time in endless meetings with all kinds of layers of management and keeping all kinds of lists, but were never around when you really needed them. I pity them for the time wasted and myself for the time waiting for them to come back from the trenches.
I think that the points you mention are known problems, but the solutions you mention are not the way to go. In IT so many times the stakeholder has no real knowledge of IT in general and has no real idea about what it really is that he needs or wants.
To me it is important that a project team together with the stakeholder iterate over the product that will be delivered. Not everything will be known at the start (and that's okay), but that also means that you can't really plan anything ahead. It's impossible to have all requirements and all risks assesed and have solutions for these as well.
A final great to Amit Sarkar:
Image by Phillie Casablanca via Flickr
I know, I know, I am all wrong. I am not a project manager. Happy for that in a way. But I have been involved in a lot of projects that failed not because of bad team members or project managers, but because of the process that was chosen to do the project. Not as much the project management methodology (Prince or Cadence or whatever) but the process that was used to get from the start (nothing) to the end (something that all involved people can live with).
I think project management has come a long way (to the moon and back) and that in IT projects people need to understand that we do not know at the start of a project to which moon we are going and whether we are going any further than the coffee shop around the corner. Most of the time it is not rocket science.
So once again: Good luck.