Project Success

I recently presented on Achieving Project Success.

Most discussion on this topic that I've heard wanders around matters related to requirements, definition and budget.

But there's more. Sure those topics are important, and neglected will frustrate success, but they are not sufficient.

Others discuss project processes: particularly relying on the setting of acceptance criteria at relevant points in a project: for deliverables, but also for completion of capability elements.

Again, neglect here will frustrate success, while attention itself is insufficient.

My talk covered three topics, some absorb the matters above, but I took a more global project view:

Project Success Baseline

• Objective and requirements set out in sufficient detail.
• Contract distributes risk on basis of control and avoids risk switchback during construction and concession phases. Risk allocation adjusted for phase based role changes between the parties.
• Contract sets out governance between parties, performance monitoring and control provisions.
• Principal recourses include step-in rights, performance bonds, contracted dispute procedure, termination.
• Suitably experienced contractor and management for type and size of project.
• Suitable and adequate financing structure for contracts used (such as construction finance and operational payments).
• Cooperative contracting approach with regular project ‘conferences’ to maintain tempo and performance.

Project Governance

• Project Board (senior reps of primary parties, Principal is chair) to overview performance and approve ‘stage gate’ progress. Meets at and between stage gates.
• Project Control Group (reps of delivery parties, Project Director is chair) meets at least monthly to review progress, risk rolling wave (risk retirement, treatment, and emergence) satisfaction of milestone and phase acceptance criteria.
• Constant review of project performance climate: risk events, communication and cooperation between parties, critical stakeholder and participant views against project conduct criteria.

Project Control

• Earned value reporting on pre-concession phases, with forecast of milestone achieved dates (to identify slippage) and corrective actions to be taken.
• Tracking of sub-contacting commitments and performance
• Review of progress and performance by Principal, SPV and financiers, reported to Principal.
• Value reviews to ensure appropriate investment in performance of product and implications for concession period operations.
• Principal retains visibility of sub-contractor procurement methodology and performance.
• Periodic reviews of deliver project management performance.
• Project level relationship between Principal and providers maintained through formal and informal reviews of performance.

Risk Criticaility

We've all been down the risk ceremony path: where risk management starts with a 'workshop', descends into a matrix, then disappears.

Risk has a number of dimensions and Shenhar's book is a great start to thinking about risk in an organised manner; after Shenhar risk should be assesed in terms of the vulnerability of dependencies to failure events (and failure modes become important) on a probabilistic basis. These should then be assessed for affect on schedule, investment and performance to produce actions that will mitigate if not avoid the risk.

You probably know the near-pointless and potentially misleading 'matrix' that both Eight to Late and Cox bubble prick.

The outcome of basing project management on a mature understanding of risk should be the criticality of events to completion, budget or technical performance. This then drives mitigating actions: abatement and avoidance, or if minor, ignoring (or buffering in schedule or budget).

Shenhar's project taxonomy

He calls it 'the diamond approach' to project understanding, and it has great ideas: at last, some thinking that lifts project thinking to the level of a workable theory, rather than just a set of practices (and therefore a 'craft').

I refer to Shenhar and Dvir's Reinventing Project Management, published by Harvard Business School Press.

Four dimensions are identified: Technology, Novelty, Pace, Complexity. There are four gradation steps for Technology and Pace, and three for the other two. There should be four for them too, which I'll suggest below.

Some of the terminology is less than precise and could be improved, but I guess it leans to a simple working project language to make its point.

For instance, take Technology: we range from 'low-tech' to 'super-high-tech', with parameters for classification brushed in the broadest strokes.

This is insufficiently objective, and different domains will understand terms differently.

'Low-tech' would indicate that components and production techniques for the finished product are predominantly conventional off the shelf items and/or require engineering that is ubiquitously available in the relevant market. 'Super-high-tech' on the other hand would be a product that relies on experimental development of unique processes or products not available anywhere in any domain.

The experimental definition identifies the risk to schedule, budget and performance instantly. Quanitification has its own problems, but historic cost escalation could give some leads: for example, Sydney Opera House, the Lockheed Lightning military aircraft (distinct from the English Electric Lighning of times past: a faster plane by far), The Apollo program, Polaris missile development...the list is long.
 
Similarly for Pace, which  runs from 'standard' to 'blitz'. These can be defined by additional investment to shorten delivery time. So 'standard' is the economical pace imposing no opportunity cost penalty on the promoter. 'Blitz' would be a pace that requires resources and working methods that represent a potential (and significant) opportunity cost penalty to a promoter. Sometimes this can be offset by a 'time to market' benefit, but not always.

Novelty needs a first step, prior to 'derivative'. Derivative implies that work is based on but not identicial to other recent examples. In the building industry this doesn't work. The prior step would be 'Repeated'. Many commerical buildings, most factories and most houses are 'repeated' projects. The large proportion of materials, techniques and skills required are identical to those required by the previous project. Nothing new but configuration and sometimes site conditions.

Similarly for 'complexity'. This dimension is quite difficult, but the there steps listed are adequately defined to be useful. I would add 'adapted' between 'assembly' and 'system'. Take a typical factory unit development. Mostly these are an assembly of known items by known methods, and represent a 'repeated' project. However, a factory for a specialist application (I think of a large printing works that I was involved in), which required fine-tuning to equipment and process, including the use of AGVs and automated paper warehousing and 'publishing' equipment, while not a 'system' in Shenhar's sense, was more than a mere assembly. The way things were brought together led to responsive interactions between 'assembled' components that amounted to an adaption that lifted the level of complexity.

The parameter that measures this dimension is the relationships between 'systems'. An assembly is work within, essentially, a single delivery or industrial system, adaptation is known systems in a novel or rare (to the project team) interacting arrangement. Shenhar's 'systems' represent a unique configuration of subsystems and require (some) specialised (not ubiquitous) processes to enable the product to meet its performance requirements and allow the customer to achive the mission for the product. Array is the most complex and has interacting unique systems or configurations.