When the Project Sponsor is just too important to be effective

As a project manager, there are a few things you want in a project sponsor:

  • A genuine interest in the success of the project
  • Sufficient “clout” and credibility to argue for the project’s priority against other projects
  • Availability to give ad hoc direction, sign off key documents, etc., as and when required

Failure on the part of the sponsor to fulfil any of these criteria can cause the project serious problems.

Photograph of a door with a sign on it saying "Project Sponsor - No entry unless authorised"You might think that the sponsor’s interest in the success of the project could be taken as read, but this can be lacking, especially if the sponsor did not initiate the project but was “volunteered” for the role (usually by their boss). If there are multiple potential sponsors for a project, the most enthusiastic supporter of the project is likely to be the one that has the most to gain from project success, or the one who would wake up in the middle of the night in a cold sweat if the project was not done!

 

Clout” usually comes from the project sponsor having seniority, or at least from having good connections with those in seniority, so from this point of view the more senior the sponsor, the better.

Availability sounds like a simple requirement, but the lack of it can seriously affect the successful delivery of the project. A sponsor who is too busy to give ad hoc direction on the best business approach to take in a crisis, for example, risks the project going down a blind alley. A sponsor who cannot give the time required to review and approve a business case will not get their project started; a sponsor who cannot devote a little time to removing project roadblocks will not get their project delivered.

It could be argued that a lack of sponsor availability to the project implies a lack of interest in the project, but this is not always the case. Sponsors who hold very senior positions may get bogged down in “Business as Usual” matters, particularly if they are detail-oriented people or adopt a “hands on” management approach with their BAU roles.

One approach that I have used successfully is to anticipate the sponsor’s potential lack of availability, and persuade the sponsor to delegate a significant chunk of their role to a deputy (ideally a right hand man/woman) who can handle the day-to-day sponsorship duties, with the more senior sponsor only being called on when unblocking is required or when the project is fighting for survival. The deputy will have better access to the sponsor than the PM, and thus the sponsor can influence the project through their deputy.

The senior sponsor is then called upon only when they are really needed, and the project benefits from the sponsor’s oversight, albeit through their deputy.

Are your sponsors just too important to be effective, and if so how do you handle it?

Related articles

Lessons Learned: Specific or Universal?

lessons-learnt

At a recent PMO FlashMob event, I got chatting with a few FlashMobbers about what can be done with the Lessons identified in project closure reports. There were split opinions in the group:

  • Some thought that Lessons are usually specific to the Project concerned, and are only useful in later stages of the same project, or in running future projects that are very similar to the one from which the Lessons were learned;
  • Others (including me) thought that it is possible to extract more generic learning from at least some Lessons that can be implemented across many projects (even those that are different from the project that identified the Lesson), perhaps by adding or making a small change to a checklist, template, approach, BAU process or corporate PM methodology, or by including the Lesson in PM training or coaching.

I have written before about Lessons Learned and my ideas on how to use them, but I thought it might be fun to try an experiment, with which I would be grateful for your help.

I have written a web survey containing a number of Lessons learned from projects (some very loosely based on my own experience, and some completely made up) – please take a look at them, and for each one let me know:

  • Whether you think it is possible is to draw any learning from the Lesson that can be applied to projects beyond the same type as the original project, and if so
  • What learning you would take from that Lesson and how you would apply it.

On completing the survey (which should only take you about 5-10 minutes) you will see a summary of all the coded responses so far (the survey doesn’t allow respondents to see the free text responses). I will also give you the password to a follow-up article outlining my own thoughts on the examples, which I will update periodically with the best quality outputs from the survey.

So why not make yourself a cup of tea, take the survey and find out how closely your approach to applying Learning from Lessons compares to that of others in the PMO Community?

Benefits Realisation Management (Book Review)

Full title:Benefits Realisation Management –
A Practical Guide to Achieving Benefits Through Change
Author:Gerald Bradley
Publisher:Gower Publishing Ltd (Farnham, Surrey) 2010
ISBN:978-1-4094-0094-3
Pages:352
RRP:£80 (review copy supplied free of charge by the publishers)
Rating:****

This well-written book starts by explaining the fundamentals of Benefits Realisation Management (BRM). It debunks popular myths, and explains why adherence to outdated beliefs can prevent organisations realising all of the benefits that could arise from change. However most of this “practical guide” is devoted to applying BRM to various situations.

First it covers how to apply BRM to projects and programmes (as early in the cycle as you can), then extends this to portfolios (projects or programmes applying BRM well are far more likely to deliver their business case benefits), and closes with implementing BRM across an entire organisation (run it as a programme and apply BRM to it to demonstrate the benefits). The text is peppered with real examples from the author’s extensive experience, and the liberal use of colour diagrams helps to cement understanding.

The book explains how best to apply BRM now if you are part way through the project/programme lifecycle, and also highlights the most important aspects to apply if you have limited time or resources (although this will not generate full returns).

It even has a section that summarises the entire book “in a nutshell” so that you can quickly find a summary of the principle you need and refer to the more detailed section of the book if necessary.

At an RRP of £80 this book is not cheap, but it has 300-odd pages of wisdom and insights to impart, some of which I have listed below to give you a flavour of what to expect.

Approach
  • Most current organisational change focusses on acquiring and implementing enabling technology (solutions looking for problems), without any subsequent steps to embed its use (business change).
  • Benefits are often derived to justify implementing some attractive capability. But benefits should be the reason sponsors commission projects. So begin with the end in mind. Don’t just implement capability; plan to use it to create value.
  • Starting with benefits increases sponsor buy-in and accountability, as the project flows from the sponsor to the implementation.
Stakeholders
  • Stakeholder = anyone who could screw things up!
  • Stakeholders deliver benefits by changing their behaviours to use new capability, so work with them.
Benefits realisation
  • Sometimes organisations “realise” benefits by removing benefit amounts from future budgets. However this can leave the organisation worse off (e.g. reducing headcount without improving efficiency)
  • The Project Sponsor is accountable for benefits, but realisation of each benefit should be “owned” by an operational manager. This person  will be highly motivated if they are also the beneficiary.
Projects and Programmes
  • Projects are usually defined in terms of delivering enablers. The business case benefits are often forgotten once the project is up and running.
  • To focus on benefits rather than enablers, name the project or programme after the outcome to be achieved (e.g. Crime Reduction, Customer Satisfaction), rather than the enabling deliverable (e.g. CCTV network, Ordering System).
BRM-Specific Roles & Responsibilities
  • Benefits Facilitator – Educates, challenges and guides projects and programmes on BRM. Ideally independent from projects and programmes, and business- rather than IT- or PM-aligned. Exists before the project (contributes to the business case), and afterwards (oversees benefit tracking). A role for the Enterprise PMO (EPMO)?
Planning for Success
  • “Proper” BRM costs about 5% of total project costs, but has a VERY high ROI.
  • BRM practitioners are scarce, so use them where they will have maximum impact and return.
Application of BRM to Projects and Programmes
  • Mapping benefit/dis-benefit distribution across stakeholder groups can identify gaps and disparities. If no-one will own a benefit, is it real?
  • Categorising benefits by type (Definite, Expected, Logical, Financial, non-financial) and by change type (starting new things, stopping old things, doing old things better) can identify duplication, and help with consolidation.
Measurement
  • It is tempting to value each benefit financially, to derive an NPV for the entire benefit set. Whilst possible, this can conceal assumptions (redundancies will result from higher productivity), and may produce double counting.
  • Measurement illustrates whether BRM is on track. “What you measure is what you get”, so choose KPIs carefully to encourage desired behaviours.
  • Set targets if the outcome is well defined, otherwise just track the measure and note the trend, with a view to informing future initiatives.
  • Start measurement (to provide baseline data) immediately the measure is agreed, or as soon as measurement is possible (to track trends).
Benefit dependencies
  • Holding workshops to generate benefits dependency maps scored with weighted paths helps to determine the order in which changes should be carried out, increases stakeholder buy-in to the changes, and gives a framework for realisation tracking.
  • Tracing benefits backwards to their enablers facilitates the creation of draft project briefs. If these changes are not already in progress, they can be costed and prioritised.
Structuring Change Delivery
  • Even if PMs only deliver enablers and outputs, they should keep an eye on benefits and the business case throughout the whole of delivery.
  • If programmes close on the completion of significant change activity, benefit tracking may suffer unless this is handed over to a function such as the EPMO.
Governance
  • Projects and programmes should be independently reviewed regularly to ensure the benefits are still viable. The project should only continue to completion if it is demonstrably worthwhile.
Relationship with Project, Programme and Portfolio Management
  • Benefits should be at the heart of PgM and PjM. For example, the Risks and Issues log should primarily contain risks to the realisation of benefits; Stakeholder engagement should focus on gaining benefit owners’ commitment to the realisation of benefits.
  • BRM can be used to maximise the benefits arising from change portfolios, and to assess the fit of proposed new Projects and Programmes with those already running.

Gower Publishing Ltd (Farnham, Surrey) 2010