Posts Tagged ‘Scoping’

PostHeaderIcon Program Management Essentials

The world is (slowly) moving toward a shared understanding of the term “program”. There are still widely varying interpretations of project vs program but the most common themes are that programs typically drive significant strategic change, involve the integration and coordination of multiple component projects (and sometimes non-project work too), and focus on outcomes rather than outputs.

Alignment and Integration

Where all these criteria are fulfilled, major problems arise when the program is treated simply as a large project, meaning that planning and oversight is overly tactical to the detriment of the more strategic activity necessary for program success (see Big Programs, Basic Flaws).

Seven Key Elements

Ensuring the program delivers what was intended requires special emphasis given to areas such as strategic alignment, stakeholder management, scope and schedule integration, and benefits planning.

The following major elements of program management help provide appropriate focus:

1 – Business Case

Programs should have a well-articulated justification for the investment, that centers on the estimated costs of implementation and ongoing operations against the anticipated benefits to be gained and offset by the associated risks.  The business case lays out the strategic context of the program and shapes its overall mission and vision. Once approved, the business case provides a point of reference throughout the program (updated as necessary) in order to ensure a continued business rationale for the initiative.

2 – Program Organization

This should comprise a single program manager with unambiguous reporting lines to an executive steering committee (program board) that adequately reflects major stakeholder interests, budgetary control and resourcing. Other advisory committees may be set up to review and guide specific aspects of the program but the board always has ultimate decision-making authority. The program manager should have ready access to an individual program sponsor to resolve issues and obtain guidance not requiring involvement of the other board members.

3 – Stakeholder Alignment

The sheer scale of a program will usually infer involvement of many parties with vested interests. Stakeholder analysis will help to identify individual concerns and parties needing the greatest attention, and subsequently define appropriate response strategies. It also assists in identifying risks associated with (real or perceived) negative outcomes. Properly managing relationships with key stakeholders requires detailed communication plans and, (sometimes forgotten), ensuring adequate time and effort is expended in acting on those plans.

4 – Benefits Realization Plan

Since programs focus on outcomes (vs. projects which focus on outputs), a core element of program setup is the development of a plan that (a) assigns metrics to identified benefits, (b) forecasts when and how those benefits will be realized and (c) maps program deliverables to the benefits which are in turn linked to program objectives. This helps ensure that assumptions in how each benefit will be realized are validated and that all required deliverables are clearly identified.

5 – Program Architecture

The program architecture identifies component projects and the major interfaces between them. A vital aspect of developing the architecture is scope integration, whereby the boundaries of each component are validated to ensure that program objectives can be fulfilled without gaps or overlapping effort among the constituent projects. A high-level program roadmap is an important tool in depicting anticipated sequencing of the projects, target dates for key interfaces, review/approval gates and other milestones, and successive stages of funding.

6 – Integrated Master Schedule

An effective integrated master schedule (IMS) consolidates all component project schedules and links them at the task level with specific, clearly defined interfaces with explicit completion criteria. Depending on the schedule criticality, the use of simulation tools and optimization techniques are often essential tools to properly manage schedule risk and greatly increase credibility of the plan and confidence.  The IMS re-validates the program roadmap and benefits plan and together with an interface tracking log will therefore provide the basis for much of the program manager’s performance monitoring focus during program execution.

7 – Tiered Governance

While project managers within the program will typically track progress against schedule, cost and technical performance, the program manager needs to ensure not only proper roll-up of this data (possibly via a program office) to control overall program progress but also to implement tracking of benefit metrics, as per the benefits realization plan. A well-designed program dashboard reflects both types of metric to provide the board with a holistic view of both the strategic and tactical performance aspects of the program.

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 Defining Scope using Deliverables

The Whole is the Sum of its Parts

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.

PostHeaderIcon Completion Criteria Ensure Done Means Done

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.

PostHeaderIcon Development Methods for the Work Breakdown

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.

PostHeaderIcon The Project Objective Statement

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:


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


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


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


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

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 Credibility requires Detail (the 2nd Law)

Most projects are underplanned. They’re already late before they start. For a host of reasons – the usual suspects include a lack of project management discipline, inadequate tools and training, unclear objectives, top-down influence, overworked and under pressure team members – projects get planned with insufficient detail.

The reality is that detail is the basis for accuracy in all projects. Plans that lack appropriate detail can’t be believed. This is what I call the Second Law of project management.

The consequence of a lack of detail is a project suicide spiral:

Understate what’s needed… Misunderstand what ‘done’ looks like… Miss stuff out… Underestimate time and effort requirements to do the work… Overcommit resources to unrealistic schedules…
Present bad news to customer.

Breakdown Checks

Without a credible plan, a project manager lacks credibility with the team and stakeholders. Only when we get to the detail is the full extent of work revealed, which means developing a great Work Breakdown Structure. Here are a few WBS must-do’s:

  • Ensure tasks are small enough so that-
    • Estimates of effort and duration are as accurate and credible as possible
    • Task durations are typically no greater than the time between progress updates
  • Define explicitly what ‘done’ means-
    • Especially for any task that is unfamiliar, complex or difficult to break down
  • Assign a single owner to each task-
    • Have them verify that the expected workflow minimizes likelihood of any missing tasks
  • Use a checklist of often forgotten tasks-
    • e.g. meetings, defect resolutions, reviews and approval cycles.

They say the devil is in the details – and just looking for a chance to cause trouble. Good process and a little extra planning time will build protection.

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

PostHeaderIcon Ambiguity kills Projects (the 1st Law)

Not so clear

Ambiguity is the enemy of project success. Its one of the first things I instruct new project managers on. I call it the First Law in project management.

Its not hard to find ambiguity in projects. Look closely at the objectives, the requirements, the scope definition and the schedule. Are they each as clear and as accurate as they can be? Most importantly, do we know what “done” really looks like? This is crucial. (Glen Alleman’s prolific and consistently excellent blog at Herding Cats has a host of outstanding posts on this – check it out). Each ambiguity is a potential source of conflict, rework and failure.

Clarity Checks

The antidote to ambiguity is clarity – here are a few items that must be on the ‘Clarity Checklist’:

Leaving ambiguity unchecked simply increases project risk. The pursuit of clarity isn’t always popular because it makes people have to think ahead a little harder. But its necessary. So put on your flak jacket and go on a mission – seek out ambiguity and destroy it… before it does some damage.

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