pm-lotus by Howard Vaughan

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.

Every project eventually comes to an end. That moment is a time for a joyous celebration of collective efforts, for deep reflection on what might have been done differently, and also for letting go – the intensity of commitment, the collaboration with others and the accomplishments of a unique venture that may be comparably repeated but not cloned.

We begin to see that the completion of an important project has every right to be dignified by a natural grieving process. Something that required the best of you has ended. You will miss it.

Anne Wilson Schaef

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.

PMOs need enduring architecture too

The function and practices of a Project Management Office (PMO) lie on a continuum spanning a wide variety of designs. For example, a PMO can exist solely as a passive ‘library’ of some set of project information that it occasionally presents to management; a PMO might also be a highly active enforcer of project management methodology, play a lead role in facilitating planning of all significant projects and make recommendations to management on the optimization of resources across the project portfolio.

The success of any PMO is ultimately governed by how well it is designed and how well it fulfils its mission. The importance of the design part is often underestimated. There are plenty of failing PMOs around, staffed by well-intentioned people, but offering processes and resources poorly matched to the needs of the organization.

Four Major Constraints

Whatever the intent, the form of the PMO needs to be designed with careful consideration of four major constraints:

1—The Perceived Need

Minor issues or big problems? No PMO can succeed without the buy-in and support of the project community it serves. If that community believes project issues are mostly small, isolated occurrences and/or solvable without the overhead of a PMO, then a full analysis of the facts – hard data – will be required before the PMO mission and vision can be defined. If resistance persists, then the PMO will likely have to be designed to start small and earn its credibility progressively, in a step-by-step evolution.

2—The Project Environment

Small projects or large, complex projects? A few projects or hundreds? All local resources or often global? A cultivation or control culture? These are fundamental variables that should determine the shape the PMO. It’s surprising how often this is misunderstood. Deep knowledge of the environmental characteristics and behaviors is a vital design pre-requisite.

3—The Level of Maturity

Does the organization currently exhibit high or low levels of project management capability? Some form of maturity assessment can determine this – but choose the model carefully (see Project Management Maturity Models). An effective assessment helps define the type and form of PMO resources, products and services, and provides a key indicator of the PMO’s performance over time.

4—The Level of Executive Support

Strong, unified commitment or general disinterest? Funding and resources available or hard to get? The broader the PMO’s scope, the bigger the backing it will need. The better the design is aligned to the constraints above, the greater the chance of securing the top-down support it will need. The design itself must also appropriately address the interests of the senior stakeholders, such as the level and type of project portfolio information, and consistency of project planning and reporting.

Important Questions

PMO design needs to answer important questions, such as:

• What are the responsibilities and reporting lines of the PMO?
• What is the scope of PMO operations and authority?
• How many PMO resources and with what skillsets are needed?

Getting the PMO design right should ensure that the answers are properly aligned to the project community’s needs, thereby building a sustainable and valued component of the organization.

Sorting the Best from the Rest

For most organizations, a critical component of portfolio management is a framework for prioritizing project work. This involves evaluating the merits of current and candidate projects against a common set of criteria and using the results to rank-order the importance of those projects for the purposes of optimizing the portfolio (see “The Goals of Portfolio Management”). But which prioritization criteria should be used?

Strategy Drives Priorities

Criteria should be directly driven by strategies – assigning a single criterion for each strategy is a good starting point. They should also be multi-dimensional in the sense that they appropriately balance strategic concerns across differing perspectives, such as financial, technical, commercial, process, people and customer; typical examples include:

Financial

• Revenue, Profitability, Investment cost

Technical

• Solution complexity, Innovation quotient, Technical risk

Commercial

• Market need, Market growth, Commercialization risk

Process

• Efficiency, Quality, Time to solution

People

• Skills development, Existing resource leverage, Functional interdependence

Customer

• Business impact, Customer satisfaction, Image

Note that criteria lie on a continuum of tangibility; while some are easily quantifiable for any project, the more intangible may be challenging to rate.

Keep it Simple

Once established, each project is scored against the prioritization criteria to determine its strategic fit and importance. Well-defined prioritization criteria and scoring models allow for clear differentiation between “clear winners” and “obvious losers”. Too often however, this all gets over-complicated. Here are a few guidelines to ensure that the prioritization framework is practical as well as accurate. Criteria should be:

• few in number
• measurable
• mutually exclusive
• linked directly to a business strategy
• appropriately balanced for the portfolio’s type of projects.

To quote Einstein: Keep it as simple as possible – but no simpler.

Not such an easy target

Project portfolio management is gaining traction inside organizations as business imperatives, competitive pressures and the availability of better tools create a compelling value proposition. Effective portfolio management responds to fundamental questions, such as:

• What projects are going on?
• How well do our projects support business strategies?
• Are we investing in the most appropriate way?
• How far are resources overstretched?
• How well are projects meeting performance targets?
• Are project priorities clear and being acted on?
• Are projects delivering anticipated benefits?

Three Overarching Goals

All these types of questions point to measurable indicators of portfolio efficiency, which is itself driven by achievement in meeting the three primary goals of portfolio management:

1 – Align Projects with Strategy

WHY? To validate that each project is evaluated on it’s own merit for contribution to strategic objectives.

HOW? Establish impartial criteria for judging project importance. Strategies must be the starting point for determining these criteria – which naturally implies that strategy needs to be clear. Weight the criteria to reflect the more important strategies and avoid excessive focus on financials.

2 – Maximize Value of Utilized Resources

WHY? To achieve the best return from available funds and people.

HOW? Consider alternative investment options for each individual candidate project. Insist on accurate resource forecasts for all projects. Use phase-planning on major projects with stage-gates to control execution. Optimize project resource utilization in conjunction with strategic importance.

3 – Achieve Balance

WHY? To ensure appropriate attention is given to necessary, internal capability-building projects as well as those exciting, high-earning customer-facing projects.

HOW? Set up separate sub-portfolios or ‘domains’ for projects of a similar nature, each with their own relevant prioritization criteria. Systematically re-assess project investments, execution performance and delivered benefits across domains.

The Bottom Line

Getting all this done requires (a) strong top-down support, (b) the right framework to operationalize portfolio optimization, (c) a highly effective Portfolio Support Office, and (d) proper project management in place across the organization. Deficiencies in any one of these will always compromise success.

Stages of Maturity... depending on how you measure it

Looking for a means of assessing your organization’s project management capability? Maturity models can provide a useful frame of reference and there are plenty of models out there – home-grown in-house models, proprietary models devised by consultancies and training firms, and models developed by project management standards and certification bodies.

Look before you Leap

Unsurprisingly perhaps, not all models are created equal – some are far more useful than others – so here are a few important questions to help ensure real value is delivered:

1 – Does the model provide direct input to a capability development roadmap?

There’s no point doing a maturity assessment if it does not result in an actionable plan for improvement; a well-defined, specific, accurate development roadmap should be derived directly from the assessment model and constitute the final deliverable from an effective maturity evaluation.

2 – Are elements of project, program and portfolio management appropriately represented in the model?

For most organizations, project management capability is dependent on practices in all three of these disciplines, not just the first. Few models give adequate coverage to portfolio and program management; most lack proper process frameworks in these domains and some consider portfolio applies only at higher levels of maturity – both of which result in incomplete and misleading assessments.

3 – Are people skills and toolsets properly evaluated as well as processes?

An assessment of maturity is only valid if it includes a fair evaluation of project management awareness and knowledge (such as through interviews and surveys), its application through tools and templates, and the artifacts that result. The breadth, depth, suitability and quality of know-how, supporting tools and project documentation should all be rated across each of the project, program and portfolio disciplines.

4 – Does the model provide for appropriate discounting of non-relevant areas?

Not all organizations have the same needs; for example, deeper aspects of project planning and control may be of little importance in some research or non-complex service environments; conversely, many components of portfolio management will be unnecessary to an organization that only performs 1 or 2 major construction projects per year.

5 – Does the model assess a reasonable number of maturity attributes and capability indicators?

Too few indicators are likely to omit key areas; too many will result in data overload and an implausible development roadmap; OPM3 from the PMI is a case in point with a ridiculously impractical base model of 488 best practices.  Accurate results and effective improvement plans have more to do with striking a balance between model detail and experienced application rather than analysis-paralysis.

Shaping the Future

Maturity models, combined with their associated assessment techniques and action-oriented outcomes, can offer the best basis for shaping project environments – but only if properly designed and entrusted to experienced hands.

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.