Talk:Project management triangle

Notability established

I just established notability by adding three references. One search in Google books shows that there are dozends of books naming this concept. Notability is not an issue here. I think original research is.

Let me make one thing clear. I didn't write this article. I separated this text from the Project management article and moved it here, as part of a series of actions to improve that article. See also Talk:Project management

-- Marcel Douwe Dekker (talk) 01:07, 2 December 2008 (UTC)

Merger Proposal

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

The result of this discussion was pages merged.

---

The assertion at the project triangle article notwithstanding, I fail to see how the subject matter of the two articles differ. Because I believe that "project management triangle" is the more common term, I recommend merging the very similar "project triangle" article into this one. 98.212.175.119 (talk) 00:32, 24 January 2009 (UTC)

The "project management triangle" article is not cited properly. Although the article may be titled the more common name the citations should be brought up to scratch. —Preceding unsigned comment added by 79.97.214.91 (talk) 18:14, 21 March 2009 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Copy-paste registration

• In this initial edit text is copy/pasted here from the Project management article.

-- Mdd (talk) 13:27, 5 November 2009 (UTC)

Quality

The second paragraph of the introduction includes the phrase: "scope" (quality). This erroneously implies that quality is the same as, or is within scope. I tried checking the reference [5], but the referred Microsoft Office site returned an error.

Please note that Time, Cost, and Scope are quantity values, whereas Quality is of course a quality value.

Also, while placing Quality within a Time-Cost-Scope triangle indicates an association between the concepts, it erroneously implies that a decrease in scope will necessarily decrease the amount of quality (since the area of the triangle will be less). Although decreased scope might decrease the expected benefit (if all products/scope-items are required for the benefit), there are other possible scenarios: (a) the scope can decrease because a product is not needed in the project anymore (e.g. it is realised that a component has already been bought); and (b) less scope can mean more time and cost to spend on the remaining scope items, lending greater quality to them.

Rwilkin (talk) 04:55, 12 September 2015 (UTC)

I differ in opinion with the notion that "quality" doesn't have quantity associated with it. A quality requirement can easily have quantity, such as the a velocity requirement on an automobile project. I also think that the image that shows quality in the middle of the golden triangle should in fact have scope in the center, and quality on one of the vertices. Scope is what you're tasked with delivering as a project manager, while quality, schedule, and cost are the constraints placed on that scope. For example, that you're asked to build a shingle-clad 3-story house with gold-plated bathroom fixtures for $200,000 within six months. The scope of the project is the house itself. The requirements of "shingle-clad," "3-story," and "gold-plated bathroom fixtures" are the quality constraints, or requirements, placed on the construction of that house. (The cost and schedule constraints are self-evident.) There is often serious confusion among even experienced project managers about the difference between quality and scope, but if you think of scope as the "what" you have deliver, and the quality as being "how good" the scope has to be, it's pretty easy to keep the two concepts separate. Here are a couple of articles that explain this better: http://www.theprojectmanagementblueprint.com/?p=244 and http://www.theprojectmanagementblueprint.com/?p=75 MarkHWarner (talk) 20:17, 11 August 2016 (UTC)

Scope

The term Scope is used inconsistently within this article. The Overview section defines it as "what must be done to produce the project's end result". The STR Model section says "Scope refers to complexity (which can also mean quality)." And the 'Project management triangle topics' section identifies it as "Requirements specified to achieve the end result".

In using product-based planning, PRINCE2 focuses on products when using the term: scope. This is a more simple and less confused use of the term, where scope is the amount of stuff (products) that the project has to produce.

High level requirements are what is needed to achieve the sought benefits - which is a focus on "why". Whereas, the focus of scope is on "what"; so the definition in the 'Project management triangle topics' section (defining scope as requirements) appears unhelpful.

Rwilkin (talk) 05:24, 12 September 2015 (UTC)

Competing forms / Mix of concepts

I think the general concept of a set of concerns exists a number of ways within this article and outside of it. That seems to make for a bit of a muddle and some gaps in the overall topic.

• The top diagram shows cost, scope, and schedule; lower shows good, fast, cheap; lower yet scope = time x resources.
• Lower yet is a diamond and below that a 6-pointed star.
• I have also seen it as "cost, schedule, and performance" and somewhat amended that it needs to be "cost, schedule, performance and risk" to avoid a bias for longshots.

I'm thinking the article 'triangle' title is a bit selective, and that maybe the overview section should discuss that alternative basis of considerations exist.

This will probably still be a complicated muddle due to the number of varieties -- sort of like there are multiple ways to do scheduling, and forms of schedule (Gantt, network diagram, tabular, etc) and it's just hard to say it all clearly.

Markbassett (talk) 22:58, 20 July 2016 (UTC)

Beginning of Rewrite

I've just made the first of what may be several edits to fix some of the more glaring problems with this article. I started with the introduction. The previous introduction did not really explain what the project triangle says, and implied that it was a model of project success rather than project constraints. It should be better now. If I get time I'll carry on fixing the article top-down. I also added several citations to the project management literature. Paul Ralph (University of Auckland) (talk) 18:58, 22 July 2017 (UTC)