My genereal approach is: The project manager is allways responsible, fully responsible, for creating and delivering a successfull project.

In this lies the responsibility to identify, analyze and act upon all potential and actual threats to the success of the project - including such factors that formally can be seen to belong elsewhere (i.e trends in society, abstract endcustomer expectation-change , whimfull outside-project executives, and so on) .

Because if the project manager doesn´t act upon them initially, they will eventually hit the fan.

As for the Shakesperian question, regarding defining project success: To OTOBOS? Or not to OTOBOS?

Isn´t it quite selfexplanatory? If primary stakeholder/-ers (in a communicative and formal process) defines success within OTOBOS, OTOBOS is to be! If success lies outside, or even in conflict with OTOBOS, OTOBOS is not to be (or, perhaps more correctly: original OTOBOS is to be changed, in consequence of the new project-success-determinants)!

I would like to see even more project managers that aren´t being (self-)limited by a narrowsighted and slim focus on either project manager responsibilites or OTOBOS.

I would like to see even more project managers stepping up to the plate, with the mandate to deliver real stakeholder-sucess!

/

Pär Westring

Project manager och sponsor within Swedish public municipal government.

I think that the most concise definition of project success is delivering a product/service satisfying the stakeholders (I see the client and the user as a stakeholder). Project Success does not necessarily mean OTOBOS (On Time, On Budget, On Schedule, again, as Elizabeth says), and, of course, OTOBOS does not necessarily mean Project Success.

Certainly projects change. Risks turn into issues; budgets get cut; the business goes in a new direction; scope changes are added on. These can be disheartening to the project manager who is responsible for keeping it all under control. I wonder what percentage of the projects are reported as “failing” or “challenged” just because of factors like these.

I haven’t read the Standish report or participated in the survey so I’m probably wrong, but I envision survey questions like, “Did your project meet its original budget?” or “Was your project delivered according to the schedule?” If a PM answers “no” because the project team, sponsor, and customer agreed to a budget or schedule change, the project is categorized as a failure. I don’t think the survey asks, “Do you consider your project a failure?” or “Are you a failure as a PM?”

So what is the definition of a successful project?
• Is it a successful project that delivers a bicycle OTOBOS when all along, despite the approved scope, budget, and specifications, the customer really wanted a motorcycle?
• If the PM delivers that motorcycle because he knew that’s what the customer wanted, does that make it a failing project because it didn’t meet all the approved scope and other specifications?
• Do difficulties in developing appropriate project plans and other artifacts mean that the project has failed if, in the end, the customer gets what they wanted?
• If the customer is satisfied they got what they wanted and needed despite any nonconformance to the budget, scope, or schedule, is that a successful project?

It’s not unusual that projects are challenged by changes or issues causing the project to be delivered later than originally planned or for more than the original conceived budget or with different features and functions than originally scoped. To me, delivering in spite of these changes and issues is the sign of a good project manager, not a failure.

Change is constant and more now than earlier, this has a high impact on the project maturity in the performing organisation which needs to adopt and implement project and portfolio management processes from an executive level.

Also PMs must communicate and unfold what is happening at the customer site, I have many examples of customers who are not telling me which direction they are going - leaving a risk for the project hitting the wall of failure “You did not deliver what we nned now”

And I agree with the Hut - PMs must learn to stop projects which are heading for failure, the sooner the better.

I generally take a pessimistic approach and communicate and document the risks up front. Makes me a bit of a grouch to work with, but the stakeholders are usually happy when it turns out less bad than I thought!

However, that leaves the other half, which I do think is a fair load to lay at the feet of project management. These generally don’t fail because someone is or isn’t PMI, or because the team chose to use Scrum instead of PRINCE2, but because either the PM was generally not up to the task or because he focused too much on the mechanical aspects and not enough on communication and project leadership.

I appreciate the eclectic approach Project Hut takes in the various postings. There is no one size that fits all, no single right approach, and no one book, whether the PMBOK or my own, that can make a turkey soar like an eagle.

— Steven B. Levy
Author of “Legal Project Management: Control Costs, Meet Schedules, Manage Risks, and Maintain Sanity”

I see it completely differently, Project Managers are not pressured, and that’s the problem. Software doesn’t work, no problem, nobody is (at least physically) hurt. No real accountability.

Project Management is maturing, but Project Managers are not.

I see project management going in the wrong direction at the moment, hordes of unqualified yet certified new PMs on the market. Wonder what that’ll do to project success. There will be a time when we say “Son, back in the good old days of 2010, projects used to be successful nearly 33%”.