Delivering a Deaf Ear to the Electorate

Well, it’s over a week since the DeliveryDemon emailed David Cameron’s constituency office about the intrusion of multiple nuisance calls from his party. Has there been a reply? Has there even been an acknowledgement? Not a peep.

The DeliveryDemon is not party partisan. Rather she regards voting as a form of damage limitation. This one tiny example is part of the all-encompassing pattern which gives her reason to believe that no political party has any commitment to the issues which are important to the electorate.

The DeliveryDemon has a message for every single would be MP and their cohorts – if you want the least bit of credibility, be prepared to do the job that goes with the pay and publicity – listen to, and represent, the views of the people in your constituency.

Delivering Stakeholder Management

It’s relatively easy to identify most stakeholders. Once they have been identified it’s relatively easy to put together a communication plan which allows you to tell them what they need to know. The plan can include two way communication events such as requirements analysis, Q&A events, document reviews and user tests. These are all part of the tried and tested approach to stakeholder management.

Rather more difficult is the management of stakeholder expectations. The project manager can issue crystal clear bulletins about what has been agreed and what is actually happening. At some point these butt up against stakeholder assumptions, recollections and aspirations. The bits which match will bolster the stakeholder’s world view. The bits which don’t match may provoke a reaction. If they do, that’s all to the good as it allows the project manager to identify and deal with any mismatch between the project as agreed and stakeholder expectations. But not all readers will bother to react. The danger comes when stakeholders skim project communications for the bits which confirm their expectations and ignore the rest. Then expectations may begin to diverge substantially from the project aims. Once that happens to any extent the project will never be a success. It may deliver to scope, cost and timescale but it won’t be viewed as successful because it’s not delivering what stakeholders have come to expect.

For a project manager to become a good stakeholder manager, it’s necessary to look beyond the project’s formal structured communication, and apply the black arts of expectation analysis and expectation management. Catch a straying expectation before it’s far from the straight and narrow and it’s easy to nudge it back on course. Let it stray long enough to become feral and you may not catch it in the lifetime of the project.

Becoming a curator of expectations requires a diverse set of skills, but the core skill is networking. Informal chats can alert the project manager to straying expections much more quickly than any formal discussion. It’s not just the obvious stakeholders who can be useful sources of information. Other projects and BAU targets may hide a reliance on invalid expectations, and people may set such targets as a means of pressurising a project to change its remit.

Sometimes divergent expectations arise because the business has moved on from the original project requirements, and the project may need to change in order to deliver business benefits.

It may not be easy to decide whether expectations should be brought in line or the project changed to meet expectations. This is where stakeholder management feeds into risk and issue management, and through that to the broader project governance and sponsorship if it appears that problems are going beyond the authority delegated to the project manager.

You can, in isolation, deliver a project which meets all its objectives. But unless you step outside the ivory tower and keep abreast of events in the wider context the project may not be seen to be successful. That’s why a project manager needs a taste for coffee, beer and cocktails, not to mention a tolerance for the smoky, windy conditions endured by the huddles which gather outside the doors of most office buildings.

Project / Programme Delivery and Service Delivery – Is There A Conflict?

(Shamelessly taken from a reply the DeliveryDemon provided to a question on LinkedIn)

Do you see a conflict?

The main interfaces with service delivery are:

• When defining the scope of the project, acknowledge that there will be an impact on service delivery, and involve the stakeholders who can form a view of the impact and how it is likely to affect other priorities, and take decisions.
• During the design / delivery / test stages of a project, identify and involve the service delivery stakeholders needed to provide input / carry out activities / test.
•  As part of dependency management, identify dependencies / resource conflicts with other projects also impacting service delivery, establish a suitable level of communication with them.
•  For transition to business as usual, allow for testing and business change within the service delivery function.

All of the above are down to planning and communication and should not be a significant source of conflict if well managed.

There is only ONE intrinsic and irresolvable conflict between programmes / projects and service delivery. Service delivery is there to deliver a service and that is their first priority. In the event of a serious incident, restoring the service has first priority.

In the event of a serious incident, all the programme / project manager can do is:

• Keep tabs on the incident resolution without hassling those at the sharp end.
• Make use where possible of resource not involved in the incident, provided their workload has not increased to cover colleagues dealing with the incident.
• Carry out an impact analysis, work on a contingency plan and implement it.
• Keep the project / programme stakeholders informed.
• Escalate only in the event that it is likely senior management will give the project priority over the service.
• Keep the morale of the team up when they can’t make progress.
• When the pressure lifts, get in there with the key stakeholders to ensure that the programme / project gets appropriate priority as the pressure comes off.