Is the Iron Triangle still the only success criteria?

I think iron triangle might be enough for the success criteria since the concept of scope might include the concept of quality which can also be considered to, in general, deal with stakeholder satisfactions and other potential factors.

IMHO, many project fails regardless of what standards, tools or methodologies they used, are using or will use because the project should deal with uncertainty of future. Luck plays a big role in the success of project. Of course, without effort on proper project management approaches, chance might not even come.

I don't think the Iron Triangle can be the sole criteria for project success anymore. I think success can be attributed to maintaining it as best as possible, but, again, not the sole reason for success.
Look at agile projects-the entire premise of agile is to embrace change and accept failure. Is that project successful if those two things were to happen? Yes. Maybe. Depends.

I remember when I was studying for the CAPM, there was a heavy emphasis on stakeholder management. The idea behind that was if you were to have successful stakeholder management, you'd have a greater chance of project success.

I need to make a distinction between project success and product success as part of my response, and I should apologize in advance for going a little off topic.

Project and product success are often conflated and, while there is some justification for it, the success or failure of one does not guarantee the success or failure of the other. The project is about delivering a product (or service). The product is intended to deliver value. One could argue that the purpose of the project is to deliver value, but if that is true, why do many companies stop measuring the success of a "project" as soon as the "product" is delivered?

You don't use the iron triangle to measure product success. There's a part of me that wants to argue that you do not use it to measure project success, either, at least not in the same way as you use it during the project.

The iron triangle really only seems to be iron during the project, not after. It's used to identify constraints, not just for measurement criteria. "Here are three variables; you can define two of them."

When the product is delivered, people usually care about one or more of the aspects of the iron triangle, but the constraints binding which you can use are removed.

* Did you deliver either what the customer requested, or what the customer wanted? (don't get me started...)
* Did you deliver on time?
* Did you deliver within budget?

Immediately after a product is delivered and a project is closed is usually too early to measure product success.

I've seen projects declared a success even though they were not on time or within budget. In my experience, projects are more often called a failure for delivering what the customer requested, but not what the customer actually wanted.

Jim Highsmith wrote an article about the Agile Triangle, advocating the combination of project and product success measures (although not in those exact words) and discussing how the iron triangle is just one point, representing constraints, with the other points on the triangle being quality and value.

http://jimhighsmith.com/beyond-scope-sched...agile-triangle/

I am not opposed to combining project and product success into one set of measures. What I recently found on a large project where we attempted to do this, however, was that by the time we were able to celebrate success (almost 5 months after delivering the product), a lot of the excitement was lost. It's significantly more motivational to your teams to have some sort of celebration as soon as you deliver. Months of blood, sweat, tears, and profanity have gone into delivering the product, then you deliver, then nothing, for months. Waiting to celebrate until you achieve product success can be a morale breaker.

(sorry about capital letter. is to emphatize). What Aaron stated is critical to understand and it is a point to be into account Rajasekar comment. Project manager is accountable for the project. Business analyst is accountable for the product. The project WILL NOT make money. The product will be make money or any other type of expected benefit. The only thing the project can assure is that the product (and no other product) will be created as defined. And that belongs to project quality. And again, product/service/result to be create for the project IS the concern of the business analyst because the business analyst is the role that work before the project exists to define the solution (the product/service/result is the object of the solution) and aftet the project ends to monitor if stated results are achieved. This is critical to understand to be successful as project manager.

Thank you, Sergio
It is important for the PM to identify the BA, find out how the BA defines success including quality and risk assessments:
* Defining customer expectation
* Time to deliver
* Cost of delivery
So, I am standing on a project viewpoint that the Iron Triangle remains valid for success criteria, however, embedded is QA/QC.
Do you use another method or scoring model? If so, what?

So, the strategic windon will help the PM to define time (project time). Budged (project budged) is what the organization has assigned inside the approved business case. Scope (project scope) is what the PM will define taking into account the product requirements. And Quality (project quality) is what the PM will define to assure that the defined product/service/result (the object of the solution) is created and non other ones. That is the only thing a PM can manage. As the Argentinian people like me said: Francisco Pope helped me to take a phone call with God regarding project management. I made a deal with God. He will not perform as project manager in the future. I, as project manager, will not make miracles in the future. So, please do not ask me for that.

I don't think the Iron Triangle can be the sole criteria for project success anymore. I think success can be attributed to maintaining it as best as possible, but, again, not the sole reason for success.
Look at agile projects-the entire premise of agile is to embrace change and accept failure. Is that project successful if those two things were to happen? Yes. Maybe. Depends.

I remember when I was studying for the CAPM, there was a heavy emphasis on stakeholder management. The idea behind that was if you were to have successful stakeholder management, you'd have a greater chance of project success.