The Traditional Sponsor Role

April 29, 2008 | Author: admin | Filed under: Project Stakeholder Mgmt, PRINCE2

The Traditional Sponsor Role
(#1 in the series Looking for Your Sponsor? The PRINCE2™ Project Board Approach to Senior Management Engagement)
By Jay Siegelaub - MBA, PMP, PRINCE2

The project Sponsor is identified as a crucial role in commissioning and authorizing projects. Yet in most environments that role and its accompanying responsibilities are often poorly defined, and it is left to Sponsors to establish what work they will actually take on. Unfortunately, many project managers find that those assumed responsibilities frequently fall short of what they really need to complete their projects successfully.
This paper will review several common approaches to senior management engagement in projects, along with their strengths and weaknesses, and explain how the PRINCE2™ approach to the Sponsor role addresses those weaknesses. The series includes the core principles of the PRINCE2™ Project Board, how those principles contribute to project success, and how a project manager benefits from having a Project Board.

While the role of project Sponsor is considered by most in the project management profession to be critical to achieving success in any project of significance, this role is frequently poorly defined and poorly understood. A Guide to the Project Management Body of Knowledge (PMBOK® Guide), which offers itself as a “descriptive general resource,” does not prescribe what the responsibilities of a project Sponsor might be in any particular project environment. It defines the Sponsor in very general terms. In the glossary the Sponsor is described as “the person or group that provides the financial resources, in cash or in kind, for the project.” According to the PMBOK® Guide (PMI, 2004), the project Sponsor also may issue the project charter (p. 81), provide the statement of work (p. 82), be the source of information to develop the preliminary project scope statement (p. 86), influence others in order to benefit the project (p. 199-219), or officially accept deliverables (p. 102). This is a rather comprehensive list of responsibilities to attach to a single resource. Described in this manner, the project Sponsor carries a great weight – seemingly the only member of management demonstrating a formal interest in the project. Under PMBOK® Guide guidance, the Project Manager would look to the identified project Sponsor as the source for all funding, for core information about the project, the resource to call on if there are any problems, and the person who ultimately signs off on deliverables.

From this definition of the Sponsor role, we can see the first of the weaknesses associated with the PMBOK® Guide approach: the breadth and lack of specificity of the role. As defined, it is a great deal of work for one person and covers a broad range of disciplines and knowledge sets. Given the variety of responsibilities, it may be difficult for the project manager and Sponsor to determine exactly what needs to be done, how it might be done, and by whom. Should this work be the responsibility of the Sponsor (finances and charter and preliminary scope statement and whatever else is needed), with the Sponsor delegating the work out as needed? Should some (or all) of it be done by the project manager, with the Sponsor providing sign-off? Perhaps others need to be involved at a decision-making or oversight level to make the project happen, to provide the varied knowledge, resources, and understanding for effective decision-making and action. The general nature of the PMBOK® Guide doesn’t (and isn’t meant to) provide for more specifics – but its vagueness calls for great deal of clarification before a collaboration between the Sponsor and the project manager can occur.

One alternative approach that is taught in the project management curriculum comes closer to solving the problem: dividing responsibilities between a project “Sponsor” (who wants the project performed, and is willing to pay for results), and a project “Champion” (who is the primary interface with the customer – those who will actually use the outputs). In this alternative model we begin to get more clarity as to the very different needs that a “sponsor” has to fulfill: representing both the business perspective (looking for results) and the customer point of view (functionality and usability). In this model, the Sponsor focuses on “objectives”, while the Champion addresses “requirements”. It may be difficult in an organization, depending on the project size, to find one individual who can provide leadership for both those dimensions. After all, how many senior managers – with the level of authority to “provide financial resources” – would also be willing (or able) to generate a Project Charter or a Preliminary Scope Statement? A second weakness emerges and is addressed: realizing that what is needed from a project Sponsor may not be found in one individual.

But even in this model, there is a missing point of view: the perspective of the technical skills and resources that will construct the project’s outputs. A business-oriented Sponsor doesn’t work in that realm, and a Champion/ customer doesn’t know (and often doesn’t want to know) what goes on inside the black box of the product. But why is this perspective needed? Isn’t that the project manager’s job – assembling, defining and validating the technical construction of the project’s products? Actually – no! The project manager’s skills are in managing projects – not in being a lead technician. The project manager’s expertise is in – and needs to be on – project management. In addition, the project manager often does not control the resources he will need to manage, so other organizational (or extra-organizational) bodies will need to be engaged and involved with the project. Otherwise much of the project manager’s time will be consumed with finding and keeping resources, when that is only part of the job requirements. Hence, some type of overview “delivery” Sponsor will be needed when those development resources are not under the direct control of the project manager.

Jay Siegelaub has over 30 years of professional experience delivering and supporting projects in information technology, insurance systems, banking, and nonprofit strategic planning, as well as in the pharmaceutical, financial service, consulting, and consumer products industries. As a recognized educator he has trained thousands of project managers over the past 23 years, including 13 years as the Project Management tutorial instructor for the Drug Information Association.

Jay’s recent responsibilities included leading the North American Change Management and Training practices for a UK-based management consulting firm, training corporate consulting professionals in project and program management, and supporting clients in managing the “people” issues of their business change initiatives. He has authored articles on training, project management and information technology for various publications, and often presents at conferences, including the PMI North American Congress (1999, and 2004 – 2007), ProjectWorld and ProjectSummit.

In addition to his PMP® certification, Jay has his MBA in Organization Management from New York University’s Stern School of Business, and is an accredited PRINCE2™ Practitioner, Instructor and Examiner. He has taught and consulted in PRINCE2™ in North America for 10 years (the first US-accredited PRINCE2™ instructor), and worked for the company (and with the authors) that wrote the PRINCE2™ Manual for the UK government.

He has provided Change Management and Project Management consulting and training (including PRINCE2) to companies such as Sun Microsystems, NATO, the United Nations Development Programme, Bechtel, IBM, Philip Morris, Credit Suisse, JPMorganChase and Diageo.

Jay also consults in Organizational and Professional Development.

Share this article:

Related Articles

This entry was posted on Tuesday, April 29th, 2008 and is filed under Project Stakeholder Mgmt, PRINCE2. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

No comments yet.

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>

All fields marked with " * " are required.

Initiating Phase - Introduction

Balanced and Strong Matrix Authority - Resource Management

Estimating and Forecasting Biases in Projects - Part I

Plan Time for Process Improvement

Project Planning Process - The WBS

Risk Management Plan

13 Ways to Guarantee Project Failure - Part V

An Alternative to EVM: The Zone Method

Project Phases

Work Breakdown Structure Was Shallow - Project Management Mistake # 7

The Traditional Sponsor Role

feel free to leave a comment