So how does this happen? It happens because we have a bad habit of encouraging the accidental sponsor.
Let me be cynical about this - and it won't be for the last time - when I tell you how project sponsorships are 'handed out' in some organizations: when the Senior Executive meets, and they understand - or are dragged into the understanding - that they need to appoint a project sponsor for a major initiative, it's too often a matter of assigning whoever's next: They say, "we need a sponsor, and I sponsored that last IT project thingy - it's your turn!"
Through some misguided respect for arbitrary authority (and putting someone who doesn't know much about projects at the top of the project heap is about as arbitrary as it gets), and by unthinking deference to seniority, organizations and the project managers in them too often make the mistake of thinking that the person or people the executive have appointed as the sponsors for our projects will be, must be, the 'right' sponsor(s) to help make the project a success.
So Just Who is the Right Who?
The smartest man I know, Dr. Francis Hartman in the Project Management program at the University of Calgary refers to the 'who?' question as the third (see below), and probably most important, of the Three Key Questions he asks at the beginning of any project, and as the key pointer to the appropriate Project Sponsor.
Question 1: "For this project, when will we know that we're done?" He does this to establish a project end point, and an associated set of deliverables that all stakeholders can agree on.
Question 2: "At the point at which we're done, how will we know that we've won?" Here, he's aiming to get agreement among all project stakeholders on the metrics for project, a clear and shared definition of success well before the project starts.
Question 3: and the appropriate Project Sponsor indicator: "Who gets to make the call on questions 1 and 2?"
Whoever gets to make the call, to 'declare' on behalf of the organisation, that the project is 'done', and that the team has 'won', is probably the right sponsor or sponsors.
Yes, the most senior person in the organization - everyone says "The President" the first time they're asked - can ultimately make the call on questions 1 and 2, but we're looking for the person closest to the action (see The right sponsor - two key criteria below), the furthest down in the organization, who the organization will designate to 'make the call' on questions 1 and 2 on their behalf.
Don't be fooled into accepting a 'figurehead' senior executive sponsor just because you think they'll have the authority to make the decisions you require. If they're not close to the project, if it won't affect them personally, you'll probably end up with a sponsor with little time for, or interest in, what you're doing...
How Many Sponsors are too Many?
One solid, engaged, accountable Project Sponsor is very good. Two solid, engaged, accountable Project Sponsors are OK, but more difficult to manage.
More than two sponsors isn't effective at all - what you've got then is a Steering Committee trying to act like a sponsor.
Organizations sometimes make the mistake of thinking that any exec whose area is affected by the outcome of the project, directly or peripherally, should have a sponsorship role. This can lead to trouble.
I worked on a financial systems upgrade project in Pennsylvania a few years back where the hosting organization had identified two project sponsors - the CFO and the CIO.
So we did our stakeholder analysis carefully and thoroughly, and came up with a plan and schedule that specifically addressed the expectations of both of these important stakeholders and their organizations.
As expected, the CFO was all about compliance and reporting, and the CIO was all about aligning the new system with his IT roadmap, and the systems, standards, and integration that implied. Our plan covered both.
But the CFO was also all about making an aggressive schedule, an aggressive schedule he'd already committed to his boss and to the Board (the fact that he'd committed to a date before a plan was put in place is another issue).
The fact of the matter was that we couldn't get the system in on time, and still meet all the IT roadmap requirements and implications of the CIO's expectations.
Of course, we could have caved and said we'd do it all on the tight schedule (that would have been a disaster), but I'm pleased to say we stood our ground.
But the problem remained: two sponsors with conflicting expectations.
At our request (and this had to be handled delicately), the President stepped in: recognizing that adherence to an IT roadmap was also an important consideration wherever possible, he made it clear that the date was most important, and asked us to adjust the plan accordingly. He also acknowledged - with the CIO in the room, God bless him - that everything the CIO wanted couldn't be accommodated within the required schedule.
The CFO was then designated the single and accountable Project Sponsor, with the CIO as an important member of the Project Advisory Team.
The CIO wasn't thrilled with the outcome, of course, but he understood what was required, and more importantly, that it wasn't the project team who'd told him he couldn't have everything he wanted. It was the President, so he didn't take it out on us.
Sure, we were able to give the CIO much of what he wanted on the project, and he was a supportive stakeholder, but he wasn't the accountable Project Sponsor, and because of that, we were able to resolve a potential multiple-Sponsor conflict.
After all, we assume, if these people have reached the esteemed position in their organizations where they would be assigned such an important role, they must, therefore, also be well qualified to be effective sponsors, right?
Wrong! Project sponsors aren't like a good Cabernet: they don't age into greatness, and their seniority often has little to do with their potential effectiveness as sponsors.
And too often, their work experience doesn't count for a lot in a project environment. Someone who's an expert on process - for example, a Corporate Controller who's built his or her reputation on honing a repeatable process like the month-end close - may be ill-prepared to sponsor a project initiative, where the work is linear and non-repetitive.
Worse yet, with all their other (i.e. non-project) experience, they may fall back on what they know; what's worked for them in the past, regardless of where that experience came from: "I don't think we need to do that formal stakeholder analysis stuff - it's a lot of work and I don't think we have the time. Let's just get everybody together around a table and work it out - that's always worked well in the past..."
Dumb Idea: Project Kick-off Meetings
Not that a kick-off meeting is a dumb idea in and of itself, but they're a dumb idea when they become purposeless cheerleading sessions: "This is the most important project we've got going in the company today!" says the sponsor, who won't have much time for the project team after the kick-off. Never mind that there are three other 'most important' projects under way at the same time, competing for the same resources...
If a Project Sponsor is prepared and equipped to come out with absolutely clear and usable directions for all those gathered - a very public declaration of the answers to the Three Key Questions, for example - in terms that ought to reduce or eliminate uncertainty (see 4. Clearly, Clarity below), that would make for a useful kick off meeting.
Unfortunately, they aren't often working meetings. They're more often casual and poorly planned meet and greet sessions that don't accomplish much more than putting faces to names.
Worse yet, a Project Sponsor might leave such a meeting with the impression that their work is largely done - "I've encouraged the team, and set the tone and direction for the project..." - when in fact, it's just beginning.
If a kick-off meeting has the potential to be nothing more than social occasion, if it shows all the signs of the Project Sponsor sprinkling a little holy water on the project and then never being seen again, don't bother.
The great value of experience aside, we need to be able to explain to sponsors that project experience is different - no, sponsoring a project is not just like running a division, no, it's not just like being effective in marketing a product - it's all of this, and more, and different.
And we need to be able to explain that Project Sponsorship is not an occasional thing, but an active thing, a verb more than a noun, an important commitment that will demand time, engagement and most importantly accountability.
And here's the big kicker that sponsors need to be aware of: whether a project succeeds or fails, a Project Sponsor should be accountable for that success or failure, as much or more than anyone on the project team, including the project manager.
And the executive the sponsor works for needs to understand this too.
What to Do
But just knowing all this doesn't help much, does it? And you're not likely to be well-received by a sponsoring executive if you're pointing out that he or she is probably unqualified for the job
But there are things you can do to help make a more effective Project Sponsor on your project.
1. Sponsors: Train and Educate
I'd never propose play the role of CFO for one of my clients, and certainly not without formal training in finance and accounting first, and a lot of experience besides. It's interesting that some people think that a project sponsor might be able to do that job without any training at all.
Sponsors, just like you and I and anyone else on a project, need to be educated on what it takes to effectively work with a project team. Just as PMs need to be taught to deal with executives, sponsors should be explicitly, deliberately taught to deal with projects, project issues, and project people.
They need to learn about change management - the effective trade off between cost, duration, and performance
The key is to convince them of all of this without causing offence. Senior roles sometimes come with senior egos, and senior egos don't like to be told that they need training.
- Unless your sponsor is of an unusually open mind set, don't suggest that they take training "with the team" - senior people don't usually like to do that, and certainly not in a situation where what they don't know might become readily apparent to all the other attendees.
- Suggest that they may want to attend project management/project sponsorship sessions that are specifically run for senior people/sponsors. All the project management conferences I've attended run special sessions, and even whole tracks, just for the most senior people. When sponsors are in a room with other people who they see as potential colleagues at the same level, when they're not concerned about showing what they don't know, they tend to be a little more open, and a little more receptive to ideas on effective sponsorship.
- Ask for their help (this is a really good idea in general, and I'll come back to it a few times) - most people are flattered to be asked for help, sponsors/senior people included.
If you tell them "how badly you need their support and understanding" and "how important it is to you and the project that they get up to speed on the PM stuff they're going to have to deal with," "how critically important the role of sponsor is to the success of the project," and "how much you're looking forward to working with them," you may be able to convince them to spend a little time on up-front sponsor education.
And while you're at it, don't call it education - tell 'em it's an opportunity to "spend time with other senior people like you". You'd be surprised how amenable people can be to your suggestions when you validate their role and seniority, and ask for their help.
2. Select a Sponsor - Deliberately
A Project Sponsor should never, never, never be a figurehead position.
As early as possible, make clear the important and significant contribution required from a Sponsor for your project. Make sure that you include a clear and exhaustive description of the role and responsibilities of the Project Sponsor in every document you produce, as early as possible. Descriptions of what they're expected to do, and how much they're expected to participate, must be clear up front.
We need to be deliberate and selective in where we need sponsor support - the way that they know and understand organizational culture, for example.
If they're not willing to/available to put in the time and energy required per the project charter, do we really want them as a Sponsor?
I can hear you now: "But I don't get to pick the Sponsor, and they don't ask what I think about it..."
You have two choices - diplomatically but forcefully point out what is needed in an effective sponsor now, before you start the project, or deal with the implications of having an ineffective/unhelpful sponsor later. I know which one I'd choose...
3. Insist on Sponsor Accountability - Carefully
How brave are you? Brave enough to ask your Sponsor: "Is this project on your performance review?" You should be.
Yes, it's a tough question to ask, but there are tougher implications later if you don't. Just how engaged do you think a Sponsor will be if your (very important) project doesn't have an impact on their performance ratings?
While you're working with your team on their accountability agreements (another very good idea), talk to your Sponsor about their accountability agreement too.
The right sponsor - two key criteria: Even before looking for the appropriate amount of Project Sponsor accountability (the project as an important part of their performance review), there are two questions that'll go a long way to telling you who the right Project Sponsor should be:
If this projects succeeds, will the person or people I'm thinking about as sponsor benefit directly and visibly from the project's success, and
If this project fails, will this person directly and visibly 'hurt' in the organisation, as a result of the project failure?
Experience tells me that if the answers to both 1 and 2 aren't a resounding 'yes', you've got the wrong sponsor...
4. Clearly, Clarity
A Project Sponsor I worked with last year - acutely aware of the political implications of what he was doing, and even more aware of the negative implications of uncertainty and confusion - started us off on the right track:
"OK, now that I've heard everyone's input, I'm going to make a decision, 'cause that's my job as Project Sponsor.
The decision is option A. The decision is not option B.
Does everyone here understand that I've decided on A and not B? Please nod your head to show that you understand.
Let me say this again. Not B, but A. If you were in favour of B, sorry, that's not how it's going to be.
Let me be clear about this: no work should be done on B, I don't want to hear about B any more, the discussion is now closed - all of us are now working on A.
Got it? A not B. Not B but A."
My kind of Project Sponsor!
5. No Sponsor? No First Planning Meeting!
Here's a warning sign: your sponsor says "I'm really too busy to attend the project planning meetings - go ahead without me". Best advice? Don't. Be brave enough (seeing a whole 'brave' theme here?) to say: "Your role as Project Sponsor is critically important to the success of this project, and it doesn't make sense to move ahead with the planning without your direct involvement and input - we'll just have to wait to get started until you have the time."
And then you'll want to remind them that, all things being equal, every day you delay the start of planning (that is, planning with the Sponsor), is at least one day later the organization should expect the delivery of the project.
Getting the right Project Sponsor isn't easy: it demands some brave words from the PM, but getting the wrong sponsor is harder and far worse, and often fatal to the project itself.
Ken Hanley, B.A, M. Eng,has been an IT and Program Management Director and Principal in a number of large organizations, focusing on IT organization, strategic portfolio management, technology and strategy, business alignment, advanced project management practices, and teaching and training on program and project management tools, processes, and competencies. He has a Masters degree in Engineering (Project Management) from the University of Calgary.
Ken has extensive experience in information technologies applied to the energy industries, in areas ranging from exploration (international and domestic), marketing, business development and production. Ken can be reached at email@example.com or (403) 605-2800.
This article has been extracted from Ken's upcoming book with the working title, Guerrilla Project Management, to be published next year by Management Concepts http://www.managementconcepts.com