.. 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.
My comment
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.
Genral objections
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:
Good luck.
Image by Phillie Casablanca via Flickr
Conclusion
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.
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=8a73d2f1-b4e6-4d54-a011-b5ccdb265d99)
Thank you sir for your observations. I may be little old fashioned and that could be due to my initial training as an aerospace engineer. In aerospace industry they do everything by the book and that is why flying is safer than any other means of transportation. Anyway, I guess for large project it is still the water fall model that works best. Here are my comments:
ReplyDelete“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.”
I wrote “Many IT projects are elaborated progressively and in these scenarios project managers rely on rolling wave planning. “ I talked about rolling wave planning, didn’t I?
“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.”
I clearly discussed about the benefits of having a risk owner. Nobody has a crystal ball to see the future but one can anticipate if things go wrong what measures will be required to correct the situation. Project risk assessment is a highly specialized job and only people who have prior experiences in similar projects should be selected as risk owners.
“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.”
Hey, I talked about user involvement. Here it is; “The second reason is user involvement and often the project planners fail to plan human solutions to the very human users that the product is proposed to serve.”
Hmmmm, now you want me to talk about the role of a business analyst. Okay, next week another article about that.
My special thanks to you to for writing comments to my article. I surely need some constructive criticism.
Warm Regards
Funny my roots are in aerospace engineering as well :-P
ReplyDeleteMaybe I have misjudged your article. Could be.
My main point is that in IT projects there are so many unknown factors (it's like a box of chocolats) that it is almost impossible to plan everything ahead and to have solutions in place for any upcoming risks. You do have to make up as it happens.
Some things can be planned ahead like you need a server to run your application on. But somewhere during your development you find that widget X does not allow multiple requests from the same client. The company that makes widget X will not change that. Or the client wants everything done in Java. Or the one team member that only knows how to tweak the server calls in sick for three weeks.
These are risks and changes to the project that you can not anticipate and can not plan for.
I have found that it is huge problem that many IT projects are planned with set end dates when the analysis is not completely done or done without everybody involved. You usually end up with a project with a fixed budget, a fixed timespan and a content that is completely vague. You know the content will change (probably dramatically), but budget and time will be fixed forever.
one of the main reasons for failure is because there is a lack of consideration for the magnitude and complexities of project management and consequently, there is a natural inclination to attack it piece meal.
ReplyDelete