The very big project

Familiar project structures typically include a PCG: project control group (or Project Board, in Prince2)

In large projects I've conducted I find a couple of other formal groups useful:

1. An Operational Management Group (OMG, or OMCommittee), and
2. A Stakeholder Reference Group (SRG)

Operational Management Group
On complex projects, the sole manager, even with staff is not adequate to the complexity of the operational activity. The OMG is composed of the decision-makers from essential contributing disciplines or departments. It usually runs to 5 or 6 people.

The OMG role is to advise the PM/PD on critical issues of coordination, operational strategy and the details of performance, again, particularly where coordination is required.

In smaller projects, the PCG can reach into this area, but in larger projects, it concentrates on policy and strategic matters, and authorizations of critical decisions related to scope, expenditure, and policy.

Stakeholder Reference Group
Large projects can have many conflicting stakeholders, stakeholders that the project genuinely seeks to serve in some way. The representatives of these groups meet every 6 to 8 weeks to consider progress, the relation of the project scope and performance requirements to evolving stakeholder concerns and needs and to advise the OMG of stakeholder interests. The OMG may refer these concerns to the Sponsor for further consideration, with any project effects being referred to the PCG/Board.

Best practice?

Really? Best for whom?

I'd prefer to develop my project practice in Deming's cycle; therefore, not 'best practice' but 'better practice' better for my projects in my circumstances. Using someone else's 'best' ties me to their past, not my future.

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'.