Manage the 'inner' stakeholders

Stakeholder management, like most things in popular literature, is often reduced to a set of rules of thumb. Often good as far as it goes, but there are some stakeholders that need extra care.

I call them the inner stakeholders.

Who are they, and how do you find them?

Easy.

First, find the project sponsor. That's probably easy, but not always. The real sponsor.

Next find who the sponsor has dependency or supply relationships with.

That's them, then. These are the 'inner' stakeholders.

Because of their relationship with the sponsor, they have a stake in the project in some way. Maybe even a way they don't see or fully appreciate.

It's your job as the PM to find out what their stake is and how they conceive it.

You need to meet them and ask about the links to the project, and the links to the things and people, functions and customers, the project is linked to. The relationship of the 'stake' to the 'holder' can be a second or third-order relationship, and those relationships might then have similar links to other inner stakeholders. They all need to be found, named, and analyzed.

This is the group you need to get in a room and identify the interconnections and how their influence can be useful to the project (and therefore to them). A 'rich picture' can help do this.

Then keep them updated. Maybe weekly sometimes, maybe monthly or quarterly at others.

But keep them updated somehow, and keep your sponsor in the loop as an ally, a facilitator and a power and information broker.

No matter what. Do it.

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.

Strategy is? 2

The strategy process is historically separated into planning and execution phases. Some writers tie the two together: Mintzberg and Quinn spring to mind. I do too.

This diagram attempts to capture the dynamic as a feedback system revolving around performance (which is where projects live).

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.

Strategy is?

There is possibly not a topic in business that is more written about than 'strategy'; except perhaps 'leadership.

What is 'strategy'?

In my view, all projects are a response to a strategic need: they build capability for mission delivery into the future.

Some concepts of strategy have a static feel to them: Porter's 5 forces, for example. I know Porter's model is not static, but it tends to a static iconography.

This diagram includes the dynamic forces that influence strategic thinking in business. It could be though of as the third dimension to a typical Porter 5 forces diagram:

The 'capability platform' is created by capital investment, responsive organisation structures and processes, and the right people to deliver skills that make strategic sense in the business environment.

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.

Governance

Governance is a special case of leadership or management.

Just like leadership it runs on information; but this time it features reporting and decision making structures that cover all aspects of a project or organisation, and not restricted to core delivery.

What do I mean?

Project governance is centrally to do with decision making that affects the delivery of the project and its relationship to corporate (owner or sponsor) priorities and mission.

The basic question of project governance is "is this project going to deliver the value that will advance the corporate mission, compared to other current or forthcoming opportunities.

In the answer to this question the risk of throwing good money after bad has to be confronted boldly. Be prepared to end a project that will not produce what an alternative use of $ will.

Document Everything

In investigative work, of which I've been involved in, there's the well known rule of ABC; I've extended it to 'ABCDE'; less snappy but more representative of the work:

• Assume nothing
• Believe no one
• Check everything
• Document
• Evidence.

In a project context, we can make that 'document everything.

I sat down with a 'not-senior-not-junior' member of my project team last week to discuss her work. I'd been puzzled over the seeming order in which she was doing it;  with her team leader being away it was time to make inquiries.

I found a disaster unfolding before me.

Her team leader (the away one) had been quite clear on the mission and was seemingly executing it well. It was relatively small, self-contained and low risk, so I left it to her.

In the transfer of information to the 2IC team leader something had gotten lost and the tree being barked up was in the wrong forest!

So: DOCUMENT EVERYTHING.

A brief project plan, or statement of brief would have clarified everyone's perception, so I'm going to knock together a template for just such a thing. It makes good procedural discipline as well, so that a pattern of activity is instilled in the team when undertaking a contributory task, to ensure they know how it advances the overall mission, and so they can see how it achieves what it needs to.