In my experience no.

I worked as a senior developer on a project where the PM's (3) were freshly minted Prince 2 certificate recipients with no prior PM experience. This was on a large IT programme.

The project was a train wreck, extremely late, hugely over budget (talking £m's), chaotic and stressful all causing several release date slippages.

When the software was finally delivered over 18 months late, the application was well received by the users and the business. So in spite of it's lateness, the project is considered a raging success. Why? because the software was well received by the users.

Now you might argue that is the only real criteria for a successful project, however I do not think so. I believe that if you look at the project in isolation and look at it as a product in itself the only conclusion you can come to is that is was, 'as a project' an unmitigated disaster.

What has happened is quite the opposite, the software was well received, so the project was a success, and indeed the PM's have now gone on to lead other projects with a similar approach and are lauded by the senior management and board.

Ultimately it's about perspective, if you are the kind of organisation where bad news is not allowed even if it's the truth then all your projects will be successful.

I think a project by definition should have objectives, so it if meets those objectives its successful.

The PM's career is a different matter. You'd have difficulty convincing me that the PM of a successful project wasn't successful by default - in that instance. Overall PM success could be a separate matter, however. If they are consultants making lots of money, you could call them successful. If they manage projects with teams who want them again on future projects, then that's another gauge of success. Over the course of a career a PM could manage a mix of successful and failed projects but their overall success must be a combination of objective project goals and subjective people goals. Whether they are viewed as successful or not is quite often how they spin their failures... but that's a discussion for a "Ask about career management" board.

For the project to be successful, it must fulfill the requirements set forth at the beginning.

For example, if product sales are not in the metrics, then the project can still be a success even if the product does not sell.

Realising benefits is seen at the programme level rather than project level. If projects delivers as per the requirements and customer is happy then Project is a success and PM who has driven it can also be termed as successfull.

Benefit realisation falls out of the project life cycle but is in the scope of product life cycle.

I think I've had this disagreement with Pawel elsewhere - I think if a project fails the PM fails - no question about it. If the project was doomed from the start a good PM would not take it (no sense in throwing oneself on a time-bomb), if the PM does not see the project as doomed from the start and takes it on they they are directly tied to the outcome of the project...black and white but not always pretty. I think this thinking removes the PM from removing themselves from what the main goal is - delivering.

It's often hard to distinguish the success of the project and the PM; from the client/user's perspective, they are usually one and the same. From IT's side, you will sometimes see cases where the project succeeded in spite of the PM, or only succeeded because of the PM.

Since perception is reality, one of the key tasks every PM should focus on (mentioned in a couple different ways by others posters) is to set expectations early, and make sure the conversation is ongoing. If the clients or users are continuously informed (thereby preventing surprises), expectations will adjust along with progress on the project. If it is subsequently killed or fails, they'll understand why (and perhaps even expect that outcome) and the better ones will still credit the PM for their role.

Bottom line is that quality of communication will be the biggest influence on how the PM is perceived in most cases, but is particularly important in a troubled project.

Absolutely you can. The main cause in my experience is on long projects, the sponsor has different expectations of success than originally planned but hasn't shared them. So, you can deliver everything on time, in budget and with high quality, but the bar has changed and something that was considered high quality (for instance) is now considered standard.

The best way to deal with this is to be close to your sponsor and check periodically whether the success criteria is still valid.

The other cause is unfounded rumor. I once had a project blow up at the end when someone decided that it was a failure. The project was legislative and came in on time and within budget the solution met all the business risk levels and the team was highly engaged. Someone started saying that the project was vastly over budget - I think the claim was 30% over budget - the finance VP was all up in arms and the only way we were able to calm it all down and reset the perception to success was to provide all the documentation. Love that PM forever because his documentation was perfect.

Two dimensions to project success: product success and project management success: -- Boeing 777 was successful in both dimensions -- City of London Taurus project was unsuccessful in both -- FoxTrax (look it up) was a well-managed project that failed to produce a successful product -- Sydney Opera House is a wildly successful product that was produced by a very poorly managed project.

Competent organizations understand this. Less-than-competent organizations don't.