Posts Tagged ‘Sponsorship’

PostHeaderIcon Seven Habits of Effective Project Sponsors

Is Your Sponsor Qualified?

Much of the dialog and content of project management improvement is focused on increased knowledge, better processes and the right tools for the project manager. Project by project however, there is another, oft-overlooked element – the project sponsor. This leadership role can, quite simply, make or break a project. If you have ever had experience of working with a great sponsor and separately with a poor sponsor, you’ll know what I’m talking about.

Good Behavior for Smoother Projects

The reality is that, much like many project managers, sponsors are frequently unprepared for their role. Yet the quality of sponsorship can make all the difference to a project and its outcomes. Adhering to the principles below can help to steer a smooth course:

1 – Align the Team

Describe the purpose of the project and its context. Articulate the rationale and summarize the business case. Express the vision of what will be different after the project, what the benefits are and how any stakeholder concerns have been addressed. Unify the team around a common goal and avoid being fluffy on what you want (and don’t want). Focus the team on the tactical objectives and be clear about the boundaries – what will and will not be covered. Not getting sufficiently involved and specific up front almost guarantees excessive involvement later on in resolving issues and fixing problems.

2 – Validate the Plan

It’s the responsibility of the sponsor to approve the plan for execution. This means knowing what a good plan looks like versus a bad plan (i.e. don’t sign anything unless you know what you’re signing). Have you reviewed the WBS with the project manager? Is it sufficiently detailed? Does it cover all required aspects of scope? How confident are the team in satisfying the objectives? How were estimates derived? Have all resources and their managers agreed to the schedule? If in doubt on how to validate, seek input from an experienced and trusted project manager or from the PMO.

3 – Demonstrate Commitment

An effective sponsor is THE champion for the project. This means being accessible and available, sticking to scheduled meetings, touching base with the team regularly – even if it’s a working lunch, keeping the project visible with senior stakeholders and advocating the interests of the project in management forums. Clearly explain the rationale for tough decisions that might be misinterpreted or risk alienating the team – (business considerations sometimes outweigh pure project interests). Showing real commitment and a passion for executing the project well, in person, week in, week out – this can be a real energizing force for the team.

4 – Inspect what you Expect

The sponsor should be an advocate for effective project management. Insist that the project team adheres to processes and provides the data that you ask for. This is especially important where the organization’s maturity in project management is still low and new processes are being introduced. Review process issues, for example in planning, technical lifecycles, tracking and reporting. Determine if anything is not working and take action to resolve it. Ensure information is timely and accurate. Poor decisions are a common consequence of bad data resulting from inadequate (or, sometimes, too much) process.

5 – Ask the Right Questions

Ultimately the project needs to deliver results – it’s the job of the sponsor to ensure the project is not only on track to deliver those results but also to verify those results are still relevant and worthwhile. This requires courage to ask tough questions and take adaptive action – possibly changing course, re-planning or even terminating the project. It also means proactively exploring options and alternatives with the project manager and understanding both the business and tactical impact of changes.

6 – Define Success and Measure It

Lay out what ‘success’ will mean for the project right from the outset. What are the ways in which the project can be judged a triumph rather than a failure? Consider who will benefit and how. What does success mean from a people standpoint? A deliverable standpoint? A process perspective? What about for the team? The organization? Use each review meeting as an opportunity to gauge how well the project is tracking to these measures – not just at the end.

7 – Acknowledge Accomplishment

As the overall project leader, the sponsor must be in touch the team’s achievements, especially when the going gets tough – which is no time to be remote. Be interested in progress, recognize both individual and team contributions and express thanks for extraordinary commitment and significant accomplishments, openly and publically. Putting in extra hours is common enough on projects but if your sponsor is an inspirational leader, genuinely empathetic and rewards high performance, it’s a whole lot less painful for the team to go the extra mile.

How effective is your sponsor?

PostHeaderIcon Six First Steps for the Project Manager

How you start determines how you finish

Time is sometimes lost at project startup with lots of talk but not much action (the “fuzzy front end”). Contrast this with the intensity of effort expended by the team near the end of the project – rushing to meet a looming deadline – and the need for some up-front structure and focus becomes clear.

Each project manager may have their own take on this, (and the actual first steps will be somewhat dependent on the particular situation) but these six should be at the front end of any list:

1 – Read the Business Case

If it doesn’t exist, get one done. There’s no point embarking on a project if the rationale for WHY we’re doing the project and WHO it’s for hasn’t been clearly laid out and signed off. If it does exist, identify who developed it, who was consulted and who approved it. Lastly, is it still current? Has anything changed in the environment that might affect realization of the anticipated benefits?

2 – Identify the Key Stakeholders

Who benefits from the project? Who can influence the outcomes and who might be impacted by them? The business case should be a guide but performing a thorough stakeholder analysis is essential before the next step is finished. Identify the project sponsor and set up an early “mind-meld” meeting to establish Sponsor-PM rapport (see Eight Questions to Ask Your Sponsor).

3 – Determine the Requirements

What does the customer actually need? What do other key stakeholders want? What has to be delivered in order to achieve the target benefits? Detailed requirements gathering and analysis may need to occur later as part of the project scope but the high-level needs at least should be established here. Determine what constraints will influence how the requirements might be met – these will impact project scope, quality, schedule, costs and resources.

4 – Identify Similar Projects

Has anything similar been done before? If so, what lessons were learned from that project (see Three Agenda Items for a Lessons Learned Review). Is there anything similar, or somehow related, going on currently? If yes, might there be potential overlap or dependencies? Can any artifacts from similar projects (e.g. plans, actuals, risk data) be re-used?

5 – Identify the Core Team Members

Which functions need to be involved to define and generate the project deliverables? Who specifically should represent those functions in the project? Who do you need on board to help generate a complete, reliable plan? Who should oversee the various workstreams? Limit the core team to no more than 8 people to promote efficient meetings and decision making.

6 – Create a Project Objective Statement

WHAT will be done, by WHEN and for HOW MUCH? The project should have a concise, over-arching declaration of intent (see The Project Objective Statement). Doing this (ideally as the first activity involving the core team) quickly shifts the focus away from the strategic (business case) and onto the tactical aspects of the project; it also helps to highlight potential issues early on, and ensures high level clarity and alignment as a precursor to elaborating the details of the project plan. Validate the POS with the Sponsor.

Begin with the End in Mind

The step numbering here indicates only the general flow – it is not a prescriptive project startup sequence as oftentimes a degree of iteration will occur among the six before they can all be checked off as ‘done’. These first steps neatly embody the adage “Begin with the end in mind” and initiate a response to the Five Laws (see The Five Laws of Effective Project Management).

PostHeaderIcon Project Management Checklists

Much more than a Memory Jogger

Much more than a Memory Jogger

Among all the tools at our disposal for managing projects, programs and portfolios, checklists are perhaps the simplest and most productive means of building consistency in work practices. Checklists are useful in almost every field of human endeavor, and in particular where repeatability and systematic action drive performance. Yet they are still much under-used in the planning and managing of projects.

As a good friend of mine, Nick Gogerty, recently posted in Checklists, hedge funds and human behaviour, checklists provide for better outcomes – both individual and team. And the more collective experience that goes into the creation of a checklist, the more value it will have. Well thought-out checklists are indispensable wherever there is a need for control, risk reduction, rapid response or safety – as doctors, flight crew, investors and others the world over can testify, the checklist provides efficient guidance, increased confidence and focus under stress (see The Checklist Manifesto – How to Get things Right – a great-sounding read that Nick highly recommends).

Twelve Checks for Planning

Likewise for project managers – checklists can be used for all manner of things. Where training builds knowledge, checklists facilitate application.  Here is a high level twelve-point checklist for use during project planning:

  1. Have the needs and concerns of all key stakeholders been considered and resolved?
  2. Does the project have an overall approved mission statement defining the scope, schedule and resources/budget?
  3. Has the relative flexibility among scope, schedule, resources and budget been determined?
  4. Have all project deliverables been identified and described in detail with unambiguous completion criteria?
  5. Are roles and responsibilities defined and agreed upon for all project team members?
  6. Has an appropriately detailed work breakdown structure been created with input from key team members?
  7. Has a credible schedule with identifiable critical path and late schedule been developed from the WBS and optimized within the project constraints?
  8. Have milestones been included in the schedule to track major events, completed phases and/or deliverables and external dependencies?
  9. Have workload commitments been identified for each week of the project and agreed to by team members and their managers?
  10. Have response plans been developed for the most significant threats to project success?
  11. Has a change management process been defined and agreed to by all key stakeholders?
  12. Has the governance structure for the project been established with an agreed sponsorship role and expectations set for review frequency and format?

One of the features of checklists is that they can be designed to extend hierarchically, such that a sub-checklist could be developed to facilitate any or all of the checks above (e.g. a stakeholder analysis checklist or a risk management checklist). The PMI, training firms and PMOs would do well to promote checklists more strongly – project managers like to use checklists; not many want to read through an overweight methodology. And managers like checklists because they improve quality and instill consistency. For the converted, I’ll have more checklists in future posts.

PostHeaderIcon The Flexibility Matrix

An important aspect of the project manager’s role is the appropriate balancing of trade-offs among the primary project constraints. In most cases this means determining priorities among schedule, scope and resources. The relative importance of these should be defined unambiguously by the project sponsor and then reflected by the PM in a matrix:

Forcing clarity on project constraints and priorities

Forcing clarity on project constraints and priorities

In the example above, schedule is deemed to have the least flexibility, meaning that everything possible shall be done to meet the target completion date, even if scope has to be compromised in some way, or more preferably, by adding resources to expedite the schedule. It is important to state WHY a particular constraint is either least, moderately, or most flexible, according to the sponsor’s priorities, with guidance on the relative limits of flexibility (so no blank cheques).

This little tool is invaluable to the project manager during both planning (in ensuring the right focus in optimizing the project plan before baselining) and execution (in guiding both the tracking effort and corrective action in the event the project deviates from the plan).

While the relative priorities can be changed by management as desired, a simple rule must be followed to prevent insistence that everything be least flexible – only ONE check allowed per column and ONE check allowed per row.

PostHeaderIcon Eight Questions to ask your Project Sponsor

This might have been alternatively titled “Questions we are Occasionally Afraid to Ask”. Here’s the situation:

You’ve been appointed to project manage a new initiative. You know that effective project sponsorship is a critical success factor and so you set up a meeting with the project sponsor.  You want to be sure you’re starting out with the right kind of backing. The sponsor wants to discuss the budget (or maybe golf) but first, you have some big questions you need answers to…

1 – Do you understand your role?
Its a fact – many project managers I meet complain that their sponsor has little idea about their role and responsibilities. You may need to help them out here.

2 – Do you know what you want?
There’s not much more frustrating than a sponsor who isn’t sure about what should or should not be included in the project. A fuzzy sponsor means you could be in for a long road trip of about-turns – do, undo, redo, …

3 – Can I count on your support?
Or more specifically – will you truly champion our project? This means advocating the project at higher levels, helping maintain visibility and interest in the project with key stakeholders, providing adequate funding and obtaining resources.

4 – Will you be available?
No doubt about it, sponsors are typically busy executives. This means their time is limited and they may be hierarchically or geographically remote. You DO need those face-to-face meetings. Lock them into their calendar.

5 – Can you give me clear priorities?
What are the primary project objectives? Which is least flexible – schedule, scope or resources? (Hint to sponsor- you can choose only one). Which is most flexible? Why?

6 – Do you understand that project management is a discipline?
In pushing to ‘just get it done’, countless projects ignore the importance of proper planning and systematic tracking… and pay a high price. A sponsor who doesn’t appreciate this means we’re already in trouble.

7 – Do you know what a solid project plan looks like?
The sponsor has to approve the plan that lays out what will actually be done- so it might make sense to ensure they actually have an understanding of what a good plan looks like. If necessary, give them a Plan Review checklist and an ‘Executive Briefing on Tactical Planning’ (so they know a WBS from a critical path).

8 – Will you inspect what you expect?
Not much point in a sponsor’s list of expectations if the relevant questions are never going to be asked. Generating information, reports and updates that don’t get reviewed is a fast track to morale hits and trust breakdown.

If the sponsor answered these questions correctly, you’re likely to be in good shape. (Hint for sponsors- the correct answer is “Yes” to all questions). If not, then you just identified some additional risks to the project…