Positive feedback

We've all heard the phrase "positive feedback", but I wonder how many of us realise that the typical conversational usage is wrong?

Typically the phrase connotes corrective action taken to restore performance. In systems terms, however, this is negative feedback. Positive feedback makes things worse; it continues an already destabilising trend.

Here's 'positive feedback' correctly used and illustrated, on page 298 of Ian Stewart's wonderful book 17 Equations that Changed the World; the chapter on the Black-Scholes equation. More of which here.

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.

Change failures I've seen

Change fails when:

• current delivery systems or system interfaces are insufficiently known or understood
• systems are not studied for change opportunities or responses
• where the work of change is on separate projects that deliver lovely pieces of paper, but no renewal, renovation or abandonment of systems.

It also fails, or is hampered by:

• under-resourcing
• neglect of subject matter experts (who probably know more of issues and opportunities than any consultant will imagine), and
• no communication at a sufficient level of operational detail to be meaningful in the real world of productive systems.

An example.

I once worked for a large corporation where we executives trotted off to a very expensive conference, in a high price venue to dream up change projects. A bunch or 'projects' came out of it, of course.

Not about places in our current systems that we could look for change and refinement, but work in the parallel universe of pieces of paper...nothing happened after our huge investment: investment wasted.

Although I did learn how to use data validation lists in Excel...a very expensive training.

Better would have been a day discussing Deming's work (some similar views at Curious Cat although this tends to be a bit 'tooly') and how we could reform our business in productive response. Alas.

5 Ws, 2 Whos and a How

Change management has grown a mantle of mythology in business (I think of Kotter's 'panic first' method and Prosci's ADKAR top-down method: which is not so bad, but seems to relegate systems to psychological affect), but sensibly, change management is a special application of project or program management. In project management we lead people to use systems to achieve productive outcomes that usually change something: often resulting in improved capabilities.

Thus: change is guided by a set of questions I label as

5 Ws, 2 Whos and a How

1. Why - is change needed? Stimulus arrives from the environment; that is such things as the market or competition, or the desire to change capability, release resources for other purposes, etc.
2. What - is to be changed? Systems usually, administration, delivery, staffing, production, financial. Defining what is to be changed is essential to success, just as defining requirements is essential to project success. It comes down to the capability to be produced by the change and what is needed to deliver the capability.
3. Who - is affected by the change? Once we know what needs to change, we know who is affected. Both insiders and outsiders: manage both, engage both, utilise the knowledge of both. The insiders (staff, shareholders) are affected because they will benefit or loose. The outsiders are affected because they are customers (or suppliers, or government).
4. When - will the change occur, start and finish? Timing in business is everything. Coordinating multiple activities (sounds like a project) is essential for all change efforts. Coordination implies communication: all affected parties need information to guide their action as part of the change (that is they, as beneficiaries, or even losers) need to be informed so that they can act.
5. How - will the change be conducted and concluded, what tells us that change has been accomplished? Typically change is carried by system changes. Failed change usually results from failure to change the work systems and therefore the working assumptions and presumptions, thus the culture, and ends up with systems and aspiration in conflict producing waste. Failure is promoted by failed communications, inattention to systems and lack of knowledge about system and change implications.
6. Who 2 - will conduct, participate in and bring the change? Following John Seddon, change is best produced by those who work in the system to be changed, to devise a better system to serve customers (everyone has a customer: this is whom the effort of a unit or system is to benefit either proximately or remotely), and manage sub-system interfaces. Isolate change in a 'change agent', or start with Kotter's 'panic', or Prosci's top-down psycho-patronising, and you cut off the potential biggest allies and the best placed change producers. Veneered change is faulty change; embodied change turns the system to meet its new capability requirement, with a deep understanding of current capability and the risks that change will evoke, guided and operated by people who are involved and therefore care.

As a program, change relies upon coordination between subsystem leaders: coordination is not merely reporting some metrics that pretend to show progress, but is a two way street of sharing, insight and opportunity making, one hopes, coming from an active (temporary) 'community of production'.

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.