Posts Tagged ‘WBS’

PostHeaderIcon A Checklist for Team Readiness

Just because the plan seems complete and you think you’re ready to go doesn’t necessarily mean that you are. Apparently small details left unattended as the project is poised for execution can become the source of re-work, frustration, delays, conflict and dysfunctional team behaviors later on in the project.

16 Team Readiness Checks

Here are some of those often forgotten pre-launch checks:

  1. Have the overall project objective and scope boundaries been shared with all team members?
  2. Have all known gaps in resource expertise been resolved?
  3. Have clear roles and responsibilities been defined for each individual?
  4. Has real availability been validated with each team member and relevant line managers?
  5. Have time and effort estimates involved input from the team?
  6. Have the team agreed on who owns which deliverables?
  7. Have those owners specified completion criteria for each of their deliverables?
  8. Is the team aligned on deadlines, dependencies, constraints and risks?
  9. Is the project team ready, willing and able to execute the project according to the baseline plan?
  10. Have initial work priorities been communicated to the project team?
  11. Has a procedure for issuing weekly WBS task lists, actions and priorities to the team been set?
  12. Is the team aware of which tasks are critical and will actual slack values be communicated to task owners each week?
  13. Has the team been informed of how and when they should provide status updates?
  14. Has the team been involved in identifying risks and formulating response strategies?
  15. Have procedures for raising, escalating and resolving issues been defined and communicated?
  16. Does the team know how often project review meetings will be held and who should attend?

    PostHeaderIcon Setting Baselines in Microsoft Project

    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.

    PostHeaderIcon A Checklist for Work Breakdown Structures


    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.

    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 Making Risk Management Real

    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.

    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)