PM World Today Letters To The Editor

On The Project Management Iron Triangle

It seems that the "triangle", now dubbed the "iron triangle", is still very much in vogue in project management software circles even though this artifact is now rusty. The controversy is over whether three sides of the triangle represent "time, cost and performance" (Kerzner), or "scope, quality and resources" (Ambler), and whether these represent the real picture. The fact is, there are four interacting interdependent constraints that must be balanced by the project manager, of : scope, quality, time and cost. However, this suggests a square and not a triangle.

Some time ago, I tackled an emminent authority on project management, on this issue. : While he agreed that there are four connected constraints, he said that the math associated with four variables gets too complicated for most people to handle and in any case a triangle is more arresting than a square.

In other words, a triangle sells better.

Max Wideman

http://www.maxwideman.com
max_wideman@sfu

Max Wideman Comments Further

on the December 2002 Viewpoints Column of PM World Today



As an alternative to a more robust Finishing/Transfer phase (as suggested below) I think what is missing in the software world is often the application of an effective work breakdown structure to the larger project picture. (I don't think that WBS is even mentioned in the RUP PM methodology. I must work on that!) Thus, your effort to execute a successful business process change would be a separate work package, perhaps running parallel to the software development work. That would also help in getting the "Requirements" and "User buy-in" properly sorted out. Associated hardware installation/upgrade would be another work package belonging to the same overall project. In this way, I think that well established project management practices do in fact cover the aspects that concern you.

With regard to selection of appropriate methodology, I was thinking then of construction where there is a whole variety of true and tried approaches which seem to fall into place naturally - for the most part. Although, even there I have seen people skilled in the art of screw ups, screw up right royally!

M.
Max Wideman <max_wideman@sfuc.ca>
Web Site http://www.maxwideman.com

Comments On The December PM World Today Article by Ken Ganshirt on Scope Verification

December PM World Today relating to scope.
http://www.pmforum.org/pmwt02/dec02ltr.htm#MAX2


Ken: Thanks for taking the time to explain at length. You are correct that I didn't follow your line of thinking the first time around. And indeed now I do and I don't have any difficulty with your position. It is a sad reflection on a lot of projects that the most tricky part of the project, that of transferring the product into the "care, custody, and control" of the owners/users is oft entirely missed. And, as you say, that involves "business process change", i.e. the way people do things - and all the resistance that this typically generates!

M.

Thanks for you response, Max. I'm afraid my experience - 28 years in IT in the telecom industry - suggests differently. Specifically, selection of the project management process and how you will apply it to a particular project is only intuitive if you have enough training and successful experiences to make it so.

(If anything about project management was truly intuitive we would not be having this discussion .. and quite probably would be in different professions! )

Even if the project manager finds it intuitive, it may not be so intuitive to the rest of the project team. And it needs to be; at least to the core team - those responsible for defining the scope of the project and getting acceptance of it from all who matter (clients, sponsors, significant resource contributors, significant resources. et al).

Even if the basic methodology is already a given in a particular company, there are still many issues that need to be sorted out. Some things are as simple as, how will we track costs and time? I have seen people ignore the internal systems that already exist for those purposes and try to track in Excel, Project, or even Word .. hopelessly inadequate tools in complex projects in complex organizations.

I have also seen people realize, well into a project, that nobody knows what the escalation procedures are. This is especially true in matrix organizations.

I know you will appreciate that those are just two of a very long list of issues that one needs to attend to if the project is going to be managed successfully. If nobody takes the trouble to talk it through and lay it out at the front end, they will be forced to either add significant unnecessary overhead to the project or, also unnecessarily, go into reaction mode when faced with the need to escalate issues.

These things all need to be talked out and agreed to, and some of it documented, at the front end. This is all quite independent from whatever the deliverable might be.

And none of this is unique to IT projects or even the telecommunications industry.

My experience is that if you try to mix that discussion (project management process) in with the very critical excercise of outlining the scope of the deliverable(s) (what's in, what's not) it all gets mixed up. You don't get very far into the discussion before it becomes clear that on any given issue nobody has a clue which part you're talking about.

In case there's any confusion, I should make it clear that when I refer to scoping the deliverable(s) I'm not talking about requirements definition or anything so detailed. I'm simply talking about laying out the boundaries, the picket fence, outlining what is within the scope of the deliverable(s) and, as importantly, what is not.

On the successful projects I have been part of, either as a resource or as part of the core team, we have always addressed scoping of the management process sepately from scoping the deliverable process.

In virtually every project I have been involved in where this was not done the project had more than the normal share of problems, even in those few cases where the project was ultimately successful, by any sensible measure.

Not having clarity on both sets of issues - clarity in the minds of all of the critical team members and stakeholders - is a killer.

I'm not the only one who has such experience. That, I believe, is why there is so much discussion the past few years of separating the discussion and articulation of Project (management process) Scope from Product (deliverable) Scope.

That was the context in which I suggested that, even when you separate those two scoping exercises, there is still frequently something missing in many business process change projects. I chose to refer to that missing bit as Process Scope, meaning scoping the processes which are part of the deliverable(s). That is, I proposed that it might be useful, or even necessary, to make the scoping exercise even more granular than just Project Scope and Product Scope.

I proposed, obviously not as clearly as I had hoped, that you could further break the Product (deliverable) Scope into two parts. One part would deal with implementation of the tools that would be used to make the change possible in the first place: the hardware, software and communications components. The other would deal with the business process changes.

It has been my experience that it is rare for genuine business process change to result from trivial projects. In the majority of such projects each aspect of the deliverable - the tools versus the processes - is non-trivial and each aspect is usually primed and resourced from significantly different parts of the organization. It has been my experience that, where there is deliverable scoping done at all, it's normally limited to the tools. It generally gives short shrift to the business process changes.

Given the difference in the cultures of the folks with primeship for the tools versus the business process changes, this it usually quite understandable. The technology professionals have, increasingly over the past couple of decades, been exposed to the need for scoping their efforts -- as a self-defense measure if not as a proactive tool. Whereas the business folk responsible for the business process changes do not usually have such a background.

Business process change projects, and therefore such situations, are pretty much universal to business and government organizations. In addition to seeing that consistent oversight in my own industry, I hear about it from peers in other industries. It's at the heart, for example, of almost every CRM implementation disaster ever published.

It was in that context I suggested that in such situations it would be useful for the project management profession, regardless of industry, to extend the Product (deliverable) scoping exercise to ensure that the business process changes are included.

I know that has become intuitive to you and I, but it clearly is not to the majority of people managing such projects or they would not continue to run into the problems they do. Even when I have been involved in such projects with people who were supposedly experienced project managers, they invariably come from a technology background and are not very disposed to spending time and energy on the non-technical aspects. They especially are not comfortable with the human factors so necessary for successful business process change.

I'm not hung up on what the additional scoping activity should be called. I simply offered the notion of Process Scope as a convenient handle for the discussion. Clearly, when some folks are already confused over the distinction between Project Scope and Product Scope, I just muddied the waters further by using the term Process Scope.

I much prefer your use of the correct term, business process change. I simply would like to see an effort in the training courses and the methodologies to highlight that scoping the business process change effort is probably more important even than scoping the technology that will be used to enable those changes. More important because, as you are certainly well aware, changing how people do work is always more difficult and more complicated than changing technology.

Sorry for the novel, Max. I hope it makes sense now. I'm not seeking agreement; simply understanding.

...ken...


----- Original Message -----
From: R. Max Wideman
To: Ken Ganshirt
Sent: Thursday, January 02, 2003 11:45 AM
Subject: Re: Comments on Scope Verification


I've probably lost my train of thought at this point, but the three types of scope you mentioned did leave me a little confused. In *teaching* project management, I think that it is important not to confuse (i.e. to differentiate between) management of the project management process and managing the development/construction of the technology.

However, in practice, on any given project, the two must (obviously) be very closely integrated. For example, I do think that the project management process needs to be selected appropriately according to the project, that is to the type of product being produced. Perhaps on a large project, these two aspects might receive separate attention. Mostly, the project process selection is done intuitively. It only goes wrong when you have someone from a different background or industry put in charge! (Like putting a construction manager in charge of a software development project.)

That is not to say that people cannot move from one industry to another, just that they need to be aware of the differences and proceed accordingly.


Hope that helps.

M.

At 5:23 PM -0600 1/1/03, Ken Ganshirt wrote:

Max, thank you for your considered comments on my submission in the December PM World Today relating to scope.


http://www.pmforum.org/pmwt02/dec02ltr.htm#MAX2

I'm very curious, as a result. Do you, then, disagree with the notion of making a distinction between "project" scope and "deliverable" scope (usually referred to as "product" scope), typically through separate documentation covering each issue? That is, making a specific effort to agree upon and articulate the policies and processes that will be used for managing the project, and a separate, but clearly dependent, effort to articulate guidance on the nature and extent of the deliverables?


Is it your contention that a single scoping effort and document should generally be considered the preferred approach?

By the way, I don't disagree with your observation that the "whole" project should be managed. I do think it's quite beside the point I was trying to make. I take it as a given when discussing approaches to project management with peers, although you are quite correct that in reality it's too frequently not (a given).

...ken...

--
R. Max Wideman
Vancouver, BC, Canada
max_wideman@sfu.ca
Tel & FAX: 604-736-7025
Get the answer at: http://www.maxwideman.com

On Corporate Memory and Standards

Here's a fact based project- engineering related story you may enjoy; Even if you've seen it before , which is probable, it's worth another look
-------

The US standard railroad gauge (distance between the rails) is 4 feet 8.5 inches. That's an exceedingly odd number.
Why was that gauge used? Because that's the way they built them in England, and the US railroads were built by English expatriates.
Why did the English build them like that? Because the first rail lines were built by the same people who built the pre-railroad tramways, and that's the
gauge they used. Why did "they" use that gauge then? Because the people who built the tramways used the same jigs and tools that they used for building wagons,
which used that wheel spacing.

Okay! Why did the wagons have that particular odd wheel spacing? Well. if they tried to use any other spacing the wagon wheels would break on some of
the old, long distance roads in England, because that's the spacing of the wheel ruts. So who built those old rutted roads? The first long distance roads in Europe
(and England) were built by Imperial Rome for their legions. The roads have been used ever since.

And the ruts? The initial ruts, which everyone else had to match for fear of destroying their wagon wheels and wagons, were first made by Roman war
chariots. Since chariots were made for, or by Imperial Rome, they were all alike in the matter of wheel spacing.

Thus, we have the answer to the original question. The United States standard railroad gauge of 4 feet 8.5 inches derives from the original
specification for an Imperial Roman war chariot. Specifications and bureaucracies live forever. So the next time you are handed a specification
and wonder what horses behind came up with it, you may be exactly right. Because the Imperial Roman war chariots were made just wide enough to
accommodate the back ends of two war horses.

Now the twist to the story............. There's an interesting extension to the story about railroad gauges and horses' behinds. When we see a Space
Shuttle sitting on its launch pad, there are two big boosters rockets attached to the sides of the main fuel tank. These are solid rocket
boosters, or SRB's. The SRB's are made by Thiokol at their factory in Utah. The engineers who designed the SRB's might have preferred to make them a bit
fatter, but the SRB's had to be shipped by train from the factory to the launch site. The railroad line from the factory had to run through a tunnel
in the mountains. The SRB's had to fit through that tunnel. The tunnel is slightly wider than the railroad track, and the railroad track is about as
wide as two horses behinds. So, the major design feature of what is arguably the world's most advanced transportation system was determined by the width
of a Horse's Behind

Robert B Gillis, INTERNET:rbg@dccnet.com