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.

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.

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.

Leadership

Leadership is the practice of providing to people an environment where they can sustainably and beneficially explore capability, opportunity and enquiry in pursuit of mission.

10 factors 10: the team

10. Your team. Be a great people manager. Show them the project vision and how they can make it happen. Motivate them. Trust and believe in them. Make them feel valued. They will work wonders.

No manager 'motivates' people. People motivate themselves. Unfortunately if the manager is not careful he or she will end up DE-motivating people. Dangerous!

Nor do you 'make' people feel valued. If you conceptualise the project team as a community of adults intent on a productive outcome, then you will inevitably value people's expertise and they in turn, being valued, will deliver commitment.

Doing it right

In Deming and disease, I wrote of an example of the typical management mish-mash often seen in business.

Demings recommendations may appear to be recondite to some, so examples?

One that that touches on the topic is: Seddon's "Systems thinking, lean production and action learning" in Action Learning Research and Practice 2007 v. 4 n. 1.

John Seddon practices systems work in organisations through Vanguard Consulting in the UK.

No commercial relation; I just think that his philosophy of the people doing the work are best placed to understand the system they work in is the right one.