pm-lotus by Howard Vaughan

Posts Tagged ‘Planning’

Baselining a project plan is essential to facilitate accurate tracking of project progress. Project schedules that lack baselines make progress reporting a combination of guesswork and blind faith, yet it is surprising how often this occurs.

Setting a baseline is typically the final act of planning. It should only be done once the sponsor has approved the project plan for implementation, thereby signifying the transition of the project from planning to execution. All documents that reflect the approved project plan should be designated as baseline records, but most importantly it is the detailed schedule that needs baselining to facilitate accurate tracking of progress.

Two Pre-Steps

Before actually setting the baseline, there are two important pre-steps:

1. Ensure the schedule has been quality checked
   This includes validating the WBS (see A Checklist for Work Breakdown Structures), and verifying the integrity of the duration estimates, dependencies, constraints and resource assignments
2. Obtain approval of the schedule from the project Sponsor
   This should include a review of all major incremental milestone dates and the level of schedule risk associated with each – not just the final deadline.

Quick and Simple

Saving a baseline in Microsoft Project is a quick and simple thing to do and here’s how:

• Select either Project, Set Baseline… (Project 2010), or
  Tools, Tracking, Save Baseline… (Project 2003/7)
• Click to select Baseline
  (rather than Interim plan which is normally used for saving draft versions of plans)
• Select Entire Project
  Microsoft Project now copies all current schedule information such as Start/Finish dates, estimates and costs into Baseline fields so they can be used as comparisons with Actual information once the project gets underway (see image below).
• Select View, Tracking Gantt to see the baseline schedule displayed together with the current schedule.

An updated project schedule showing current progress on each task (Start/Finish columns, blue/red bars) compared with the original baseline (Baseline Start/Baseline Finish columns, light grey horizontal bars). Also shown is the total slack on each task (positive slack/blue horizontal lines displaying the late schedule, negative slack/red horizontal lines).

Re-Baselining

Microsoft Project provides for re-baselining via the “Baseline 1”, “Baseline 2” etc. dropdown selections in the Save Baseline dialog. The options for displaying the Gantt bars for any baseline can be set up in Format, Bar Styles (click Insert Row to assign bar and color options for any re-baseline, e.g. for Baseline 1 select “From” as Baseline1 Start and “To” as Baseline1 Finish).

However, once set, the baseline schedule should only be altered (re-baselined) under extreme circumstances (such as a Sponsor-approved major scope change), that render the original baseline schedule obsolete and no longer a meaningful target to aim for and report progress against. Continually re-baselining is not project management – it’s playing politics.

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

Whether checklists are retained as tacit knowledge, explicitly documented for personal use or defined as an organizational standard, they can be invaluable aids to ensuring quality and consistency (see Project Management Checklists). Checklists can be used for any and all aspects of project management but generally have most value in those major areas of project planning that are most frequently defective, such as scope management, scheduling and risk management.

Ten WBS Checks

 Here’s a checklist for that cornerstone of all detailed planning, schedule optimization, proper risk identification and effective change management – the work breakdown structure (WBS):

1. Is the WBS organization method appropriate?
   - The chosen level 1 grouping method should reflect the focus needed for tracking and reporting
2. Is the project scope fully reflected in the WBS tasks?
   - The scope definition of each deliverable should be reflected in all tasks that accomplish that deliverable
3. Do all task names have verb/noun descriptions?
   - Action-oriented task names reduce ambiguity and minimize potential misunderstandings
4. Do all tasks have correct coding?
   - Unique WBS codes should correctly identify the hierarchy of each task
5. Do tasks aggregate correctly?
   - All lower level tasks should roll up to the next highest level
6. Are tangible outputs evident for each task?
   - Establishing measurable outcomes enhance understanding of a task’s purpose, scope and progress
7. Does each task have one single owner?
   - The project manager needs to know who is accountable for ensuring the task gets done – that’s one single individual (multiple owners = zero owners)
8. Do the lowest level tasks have appropriate duration?
   - Task durations should be consistent with tracking frequency (e.g.. weekly tracking would demand task durations of typically between 1-8 days)
9. Do tasks have clear, agreed upon completion criteria?
   - Completion criteria ensure there is no ambiguity in understanding what “done” means
10. Does the WBS include adequate milestones?
    - Milestones should be present to help set schedule targets and track progress against the completion of key deliverables and major project events.

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.

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.

Plans are not crystal balls. They are at best a logical and reasonable perspective of the future but no more. Every project involves uncertainty and uncertainty implies risk. And there is no such thing as a risk-free project. I call this the Fourth Law of project management.

All of which has a serious implication for project managers – the need to properly account for risk. The fact that plans are incomplete views of the future means they are always at least slightly wrong. Even if we correctly identify all the tasks and activities to be performed, errors will always exist in assumptions, duration and work estimates, task dependencies and so on.

Most project managers appear to ignore most risks (witness the lack of risk readiness as evidence) . Yet threats can and do suddenly materialize. But sudden does not necessarily mean unpredictable. Experience and a little structured thinking can expose potential threats that we can get ourselves prepared for:

5 Essential Steps to Managing Risk

1 – Get Prepared

• Determine how complex your project is and how much unmanaged uncertainty you (and the project sponsor) can tolerate, i.e. how important is risk management for your project? Then decide on the process you will use and brief your core team accordingly (risk management is not a solo effort).

2 – Identify Risks

• Review project documentation – business case, SOW, charter, plans (WBS especially) and assumptions to seek out sources of uncertainty, potential error and change. Wear the hat of Murphy – “If it can go wrong, it will go wrong.” Remember, this involves core team members, not just the PM.

3 – Assess Risks

• Evaluate each risk for (a) the likelihood of the risk occurring and (b) the potential impact to the project if the risk does occur. Rate the severity of each risk on these two dimensions. High likelihood and high impact means for those risks at least, response plans will be a necessity.

4 – Develop Risk Response Plans

• Evaluate alternative response strategies. Ask these questions: How could you avoid the risk? How could you reduce likelihood? How could you reduce impact? How could you transfer the risk to another party? Could you accept the risk with a just-in-case contingency or backup plan? If so, how would it work?

5 – Monitor Risks

• As the project progresses, risk monitoring should be a regular item on the agenda, week after week. Have any risks occurred? Are the response plans working? What has changed that might cause new risks?

These are the essentials. Large complex programs will take these steps to a very deep and sophisticated level. But even the simplest of projects will benefit from the same basic steps. Scalability, as ever in project management, is the key.

Here’s a good way to think about all this-

Ignoring project risks is the first and biggest risk to the project.

(See all 5 Laws summarized in The 5 Laws of Effective Project Management)

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.