pm-lotus by Howard Vaughan

Archive for the ‘Planning’ Category

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.

How do you know for sure when something is declared “Done”, that it really is? By defining completion criteria. These little nuggets are one of the single most important – yet frequently overlooked – aspects of project planning.

Completion criteria root out ambiguity (see The First Law). They align stakeholders, team members and the customer on the conditions for acceptance and validation of the project outputs. And they improve estimating quality by enhancing understanding of the desired work result.

Its a Binary Thing – “done” or “not done”

Completion criteria should be defined first for the project deliverables, which in doing so will actually help identify tasks for the WBS, and second for (ideally) each task in the WBS itself. Well-written criteria:

• Are defined by the deliverable or task owner
• Clearly state the characteristics and attributes of the output  – “what done looks like”
• May include the measurement and validation requirement – e.g. “who reviews what”
• Are defined in a binary way (i.e. totally unambiguous).

Can we really do this for every task? You decide – it’s a tradeoff between increased planning effort vs. increased risk. But consider that while this may initially seem onerous, the reality is that it does not take much more effort to write a statement or a couple of bullets specifying what ‘complete’ means (for example in the Notes field in Microsoft Project). Put in the context of the project overall, it’s a seriously small price to pay for dramatically increased clarity and reduced risk of misunderstandings.

There are several methods for identifying project risks but the best approach involves the team (at least the core team members and any relevant SMEs and/or PMO staff) and considers the following:

• History (review past projects of a similar nature – surprising how often this is missed)
• Context (assess the stakeholders, implementation environment and constraints)
• Boundaries (review the project’s SOW, scope and deliverables)
• Details (review the WBS, dependencies, estimates and resourcing)

The Nominal Group Technique

To get optimum input on possible project risks, there is no better team method than NGT. It leverages the advantage of multiple perspectives, can be done relatively quickly and avoids all the pitfalls of brainstorming, which is over-used and usually poorly facilitated. Here’s how NGT works for risk identification:

1. Each individual reviews history, context, boundaries and details (as defined above) and writes down their own list of possible risks – i.e. with no interaction between members
2. With the team grouped together, all identified risks are then captured by going around the team, taking the first item on each person’s list, then around again capturing the second item and so on until all items have been captured
3. Duplicates are removed from the consolidated list and descriptions clarified as needed
4. Each person reviews all the risks captured and the team decides if any should be removed the listing, on the basis of being extremely unlikely AND with little or no impact

Once this process is complete, the team can move to assessing the severity of the remaining risks, prioritizing them and defining response strategies to manage them.

Lots of Benefits, not much Downside

Using NGT is a great way of aligning the team on project risks. Its thorough, avoids groupthink, rapidly builds awareness, avoids jumping prematurely into risk analysis and prevents outspoken individuals unduly dominating the final risk list.

There is sometimes confusion in approaching creation of the work breakdown structure (WBS). In part this can arise from a misunderstanding of the definition for the WBS as a “deliverable-oriented hierarchical decomposition” of the project work. Use of the term deliverable-oriented is taken by some to mean that the WBS must be generated directly from the project deliverables. In fact there are several ways to develop the WBS, using direct or indirect decomposition, (and clearly acknowledged in the PMBOK actually) – here’s a quick overview:

Start with the Major Deliverables

The starting point for any WBS must be the identification and full description of the project’s Major Deliverables. These are the “Big Pieces” that result from the project work, and that when aggregated, reflect the final and complete scope of the project. Getting a full understanding of the Major Deliverables facilitates comprehensive identification of all the project work required, to ‘deliver the deliverables’. (This is the primary meaning of ‘deliverable-oriented’).

4 Common Methods

There are many approaches for breaking down the work to be performed; however here are four of the most common, along with simple examples, for defining the top level (level 1) WBS components-

By Deliverable

Just take each major deliverable, then subsequently break it down to list the tasks required to create it:

By Lifecycle Phase

Makes sense if you have a standard lifecycle (e.g. for product or software development):

By Geography

Relevant if work is performed in different locations:

By Function

An appropriate choice if you want to sub-plan and track separate functional contributions:

Choices, Choices

So how do we choose which method to use? A good guideline is to choose the method that makes the most sense for planning (organizing the tasks), tracking (collecting status) and progress reporting. Consider where you want the focus to be and verify the top level view is in line with what the sponsor wants to see as well.

All projects have an objective but not all projects have a well-crafted objective statement. Its a simple and elementary thing but deceptively powerful. Creating a high level, overarching mission statement should be among the first 5 things that a project manager does with his or her core team.

Short and Sharp

An objective statement should ideally be written as a single meaningful sentence, comprised of no more than 25 words, that reflect the primary project constraints – schedule, scope, resources.  The word limit deliberately forces focus and ensures we get to the core of the project’s main objective, even if a zillion things will be worked on during the project’s life.

To re-quote President J.F. Kennedy as an example:

Put a man on the moon and return him safely back to Earth, completed on December 31, 1969, for US$531m

Call it what you will – a Project Objective Statement (POS), a Project Mission Statement (PMS – less popular), or PROject MISsion Statement (PROMISS) – this declaration is crucially important for a host of reasons:

Clarity

• It is THE stake in the ground that lays out exactly WHAT will be done, by WHEN and for HOW MUCH.

Alignment

• Securing sponsor input and involving the core team in crafting this statement ensures buy-in, commitment and a sense of real purpose. It should NOT be done by the PM alone.

Validation

• It should be formally approved by the sponsor prior to detailed planning and re-validated again before execution begins, i.e the plan MUST demonstrate tactical viability by meeting this target.

Tracking

• It communicates an ongoing point of reference for management and the team throughout execution. The project mission changes only if explicitly required and agreed to by management.

The process of creating this statement is as important as the statement itself. Done right, it begins the development of a performing team and the resultant discussions help identify project boundaries, assumptions and issues early on. Put this as one of the first agenda items in your planning sessions.

Its always amazing how small things can make a big difference in the world of project management. Consider the describing of a risk:

The Wrong Way

Oftentimes we see a ‘shorthand’ approach used – for example, a risk captured simply as “Insufficient resources”. The danger (the risk?) of such a brief description is that it creates three problems:

• We misinterpret what exactly was meant (Which resources? On which tasks? With what consequences?)
• We may not correctly assess the risk’s importance because of the description’s ambiguity
• We can’t remember what we meant when we revisit the risk log at a later date

For these reasons, it makes good sense to describe a risk in a way that clearly states the possible situation and its effect.

The Right Way

A recommended approach is to write a risk like this:

EVENT may occur WHEN, thereby causing IMPACT

So rather than a bland, ambiguous risk statement such as “Lack of training”, we drill down and explain clearly what is meant – maybe:

“Competing work commitments may prevent staff attending the training, thereby slowing adoption of the enhanced project planning process.”

Now its clear. We understand both the effect and its root cause. Clear statements of what we really have in mind when we identify risks promotes consensus in (1) understanding the risk, (2) assessing its importance, and (3) generates more creative thinking in the development of risk responses. A little extra effort for a big benefit.

Of all the processes within project management, it would seem that risk management is the one that most often turns into a paper exercise. Lots of projects have lists of identified risks, some have plans to manage those risks but only a few properly integrate risk responses into the overall project plan.

A Small but Crucial Step

Creating risk logs and defining response strategies is a ‘non-productive use of valuable time’ if performed merely to satisfy management, increase comfort levels or just conform to company policy. Those documents will gather plenty of dust. What’s needed is for that information to become an essential component of the detailed schedule. This is a small but crucial step – and often missed.

Here’s how to do it-

1. Once the project risks are identified, define clear mitigation strategies – i.e. specific actions to proactively (a) reduce probability or (b) minimize or alter the impact of the risk occurrence.
2. These actions can then easily be defined as “tasks” in a verb/noun format – which means they can, and should, be added to the project Work Breakdown Structure (WBS).

In the example above, a section for Risk Management has been added to the end of the WBS task list in the Microsoft Project plan. Each of the tasks within that section is an explicit risk response activity. Each task will therefore be assigned an owner, linked into the schedule with appropriate duration and resource estimates, and then executed and tracked in just the same way as any other task in the schedule.

Now, we have made risk management real. Its an integral component of the execution plan – not a paper exercise. Remember – if its not in the WBS, its not in the project.

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

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.

A hammock task can be defined as either a summary task that aggregates a related set of activities, or an actual ongoing activity whose start and finish is driven by other tasks or milestones that may or may not be related. In the first case, summary tasks are easily created using the outline feature in Project of course but the second case can present more of a challenge.

In the simple example below, two non-summary hammock tasks are shown.

Both hammocks reflect ongoing activity from the start to the finish of the project. To create Hammock A:

• Click in the Start cell for the project “Start” milestone and choose the Copy command
• Click the Start cell for “Hammock A” and choose Edit, Paste Special, Paste Link, and click OK
• Click in the Finish cell for the project “Finish” milestone and choose Copy
• Click in the Finish cell for “Hammock A” and paste as a link again

A problem with hammocks is that they may show up as critical items (as here with Hammock A) whereas in reality they do not actually drive the project schedule. Hammock B shows how we can avoid this by linking the finish date to a ‘dummy’ milestone “Finish -1″ that we set to finish just before the project finish (predecessor is Finish milestone SF-1).

Using either approach above will allow the hammock to ’stretch’ or ’shrink’ as the durations of the other tasks change, during plan updates for example. If necessary, a manual click on the F9 key will force a correct recalculation of the hammock’s duration.