Monday, August 29, 2016

The triple constraint

I used to disparage the triple constraint: I thought it simplistic and unhelpful.

The three constraints (triple, because they interact) are illustrated below.
 
More recently, this has been elaborated into a double triangle: attempting to be all things to all people describing project factors, rather than the constraints.

The elaboration is unnecessary. Risk, resources and scope go to budget, budget and scope go to schedule, quality goes to scope. There are probably other schemes, but they end up in the triple constraint quite quickly.

Risk as a factor is interesting...its like putting 'doing your job' as a factor. Risk is assessed then used to guide the setting of budget and schedule against scope. Scope is quality.






I like Glen Alleman's much more helpful diagram, below. He introduces the concept of 'technical performance measure. Much more meaningful then either 'quality' (as if that means anything), or scope.

















My preference is for a modified triple constraint, that is more attuned to the business environment and the realities of projects where a project exists to produce a capability that has value for the sponsor.
























I've adapted Alleman's TPM to be 'objective', although 'performance' as the out turn result of the project is what we are after. Fussing around with 'quality' as the centre of the triangle does nothing for anyone; what we need to focus on is the value produced (to meet a certain performance by a certain time to produce value from the investment: think Net Present Value).

The money is invested; its not just a cost, but the investment has to be carefully managed to ensure that the sought return achieves the necessary value. We don't manage 'time'. Alleman is right, that we manage schedule, but I prefer to use delivery, as this focuses attention on the project doing what it is meant to do: deliver value.

Friday, August 26, 2016

Stoplights

After gantt charts, the next favourite topic of communicative techniques is the project 'stop light' chart. Three colours (red, amber, green) to give a 'high level' view of project performance. However, they are criticised.

On a real project (any decent sized construction project), I've never seen anything as puerile as a stop light pretend chart. I've seen detailed status reports.

There are only two main parameters for projects (once we've established the sought performance of the product): out-turn cost (EAC), and date of (defect free) completion. One could also report drift in the parameters, and if there are unmade decisions creating schedule or cost risk, the EAC and DFC date could have probability ranges attached. Not that a board will pay much attention to the implications of either: best convert them to a date range and a cost range.

On the other hand, some people seem to love RAG status reports. Maybe because they remind them of lollypops...I can't think of a grown-up's reason to like them.

Tuesday, August 23, 2016

Project Graphics

In a post some time ago on the Tufte forum, ET criticises the information sparseness of typical PM gantt charts, and their derivatives. I'd agree with him, but wonder what to do as an alternative. I've played with a few alternatives. I like the medical chart work; something like this could be effective; but I'm not sure how. Projects can be too complex. I think of a $200m retail complex with cinemas, parking, public facilities...let's say 1,500 high level tasks.

This topic has been explored by some others. One ending up with a vertical gantt chart. I don't see how this is an improvement, when people intuitively read a gantt chart left to right. A variation on this seeks to use the thickness of the gantt bars to carry information.

Based on this idea, I thought to add information numerically (thus, not quite a graphic development).

The baseline (or Original Target) is the line with diamond ends, the current forecast/actual (CF/A) is the hollow bar, and progress (PAD -- production at date) is indicated by the coloured solid bar. This is an earned value progress: the schedule performance index. If less than 1 (under-performing) the bar is amber, and lags the report date, representing as shown a SPI of 0.9: 90% of the distance between the start line and the report line.
If greater than 1, as on the lower bar (SPI of 1.2), and the activity is 'over' performing, the bar is green. The numbers surrounding are self evident on inspection.

A development of this is to strip the numbers off the bars, as below.

Here the activity name is above the 'action' bar. A blue solid bar indicates a completed task, and the black thick vertical end line represents the completion date. Early completion is shown in Activity name 3, and late completion in Activity name 4. As can be seen, Activity name 1 is substantially behind schedule, and Activity name 2 reasonably ahead of schedule.

Gauging progress is always problematic, unless the activity is easily measured: laying bricks or pouring concrete. Much harder for intangible activities, like design. Here I break the activity in easily assessed sub-activities, and measure those on a 0-100 basis. For design this might break into: requirements confirmed, preliminary options completed, preliminary options presented, preferred option identified (as a milestone) and so on. Easier to estimate this as well; and even easier if there is relevant 'reference class' historic data (and more at the Transportist).

The only drawback with my concept is that one must be using EVM to track production. But, that's a good thing.