pm-lotus by Howard Vaughan

Posts Tagged ‘Stakeholders’

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).

The Whole is the Sum of its Parts

Project scope is most frequently described in a narrative format, often termed a scope statement. While this may convey a broad sense of what the project will set out to accomplish, a narrative alone runs the risk of being at best insufficiently detailed and at worst ‘fluffy’ and incomplete with all the inherent dangers of ambiguity (see Ambiguity Kills Projects).

3 Steps to Clarify Scope

An effective definition of scope needs to include a formal description of the project deliverables. These are the primary outputs that result from the work performed – what will be there at the end of the project that is not there at the beginning. There are three steps to describing the deliverables completely:

1 – Identify the Major Deliverables
What are the largest, most significant outputs of the project?
These are the major deliverables, that when combined, should comprise ALL delivered outputs and reflect the full scope of the project. Since deliverables are “things” they should have noun or noun/adjective titles, e.g:

Release-Ready Software  |  Prototype Hardware  |  Trained Staff  |  Assessment Report etc.
– they are not activities with verbs (those will be defined later in the WBS).

2 – Describe Deliverable Features and Exclusions
What exactly will be delivered? What will not be included?
The Is/Is Not technique is the best way to define deliverable boundaries, by capturing the attributes that a deliverable “is” (or includes) and those that it “is not” (or does not include); e.g. for a deliverable “Business Model Analysis Report” we might have:

IS – Current marketing assessment, Competitor analysis, Customer needs study, etc.
IS NOT – Plan for an alternative business model, Supplier capability study, etc.

3 – Define Deliverable Completion Criteria
How will you know when the deliverable is finished?
These criteria are crucially important (see Completion Criteria ensure Done means Done); aligning expectations up front among customer, stakeholders and team will avoid painful conflict later in the project. For example:

- Six copies of report in spiral-bound hardcopy provided to Steering Committee for review
- Key findings presented in PPT format to Executive Management in a half-hour briefing.

Bridging the Gap between SOW and WBS

Deliverable descriptions make for sound scope management and effective change control. They exploit and enhance the Statement of Work narrative to provide real benefit in several ways:

• Give the project scope some solid structure
• Align expectations among stakeholders
• Establish the basis for customer validation of outputs
• Bridge the gap between the initial scope narrative and the detailed WBS
• Help ensure that all WBS tasks are comprehensively identified (e.g. completion criteria will often point to needed WBS activities).

Undefined deliverables => unclear scope => undeliverable project.