Posts Tagged ‘Planning’

PostHeaderIcon The Power of Rapid Planning Workshops

Accelerating Capability...Beyond Training

For all the millions spent on project management education, significant improvement in the way projects are actually planned and managed remains an elusive goal for many firms. While formal training is (or should be) an excellent foundation for improvement, it is not the greatest means of turning knowledge into sustainable, collective action – which ultimately, is what most organizations actually need.

Beyond Training

Rapid planning workshops, in contrast, do just that. They offer one of the single most powerful methods, (especially post-training), of embedding effective project management methods and tools.

Conducted in a live intense planning environment with the project manager and his/her core team, they are explicitly dedicated to evolving a high quality mission-critical project to execution-readiness as fast as possible. Properly designed, skilfully-facilitated workshops can compress planning time from weeks to days, by fully focusing the team on their project without productivity-sapping distractions, and by elaborating overall goals into detailed, tactically-viable, fully-resourced integrated schedules, all under the guidance of an expert facilitator, (ideally from the PMO).

Project planning is an everyday occurrence but the quality of the output is too often suspect – and the stealthy precursor of unnecessary strife, poor productivity or a troubled project. Repeatedly exposing project teams to high impact, structured planning, results in profound acceleration of both their projects and the organization’s project management capability.

Follow the Process

A typical planning workshop agenda should be tailored to the project’s needs and the organization’s own methodology (if it’s adequate) and might include activities such as:

  • Define objectives (tactical targets)
  • Define scope (deliverables, exclusions, completion criteria)
  • Create WBS (tasks, ownership, completion criteria)
  • Assign resources (staffing)
  • Develop schedule (dependencies, estimates, constraints, critical path analysis)
  • Optimize plan (schedule/scope/resource constraints and tradeoffs)
  • Manage risks (identification, assessment, responses)

These are really just standard planning steps but the trick is in how they are actioned in the workshop using a mix of large/small group collaboration, flipcharts/Post-Its, templates/software and real-time analysis/quality control/adaptation for maximum impact. Any project can benefit from these structured sessions; larger projects can typically get to the lowest level of appropriate detail (potentially thousands of tasks) within just a few days. Team alignment, a credible plan and knowledge transfer – for maybe less than 2% of the total effort to execute the project. Its a great return. And done right, by institutionalizing rapid structured planning as an operational norm, the biggest winner is the organization.

The global state of project management would be infinitely improved if just a fraction of organizational training budgets were allocated to properly standardizing high impact planning practices.

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 Principles of Alignment

Team Alignment, not Team Building

One of my favorite blogs is Glen Alleman’s “Herding Cats”. Solid project management commentary, a wealth of experience and expert guidance with no fluff. Glen recently posted on Team Building and like me he doesn’t have too much time for ropes in the forest and artificial partying as a means of ‘building’ teams.

Effective project teams are built on purposeful activities centered on the project in question. Confident facilitation of a clear agenda that engages the team in understanding and elaborating the project mission is a good starting point.

Five Principles for Aligning the Team

If project startup and planning activities are well conceived and facilitated then team alignment should be a natural outcome. Maintaining alignment is subsequently a function of proper control, engagement and communication. Five principles guide the project manager in developing a unified, cohesive and productive team:

1 – Know the Objective

Shared vision and common purpose are the starting points for building an aligned team. Review the project business case, then craft the project mission statement together with the core team. Ask yourselves what’s missing? Is it specific enough? Is it realistic? Does it properly reflect the tactical objectives that should in turn yield the anticipated benefits?

2 – No Moving Targets

Establish clear boundaries. What will be included? What will not be included? What deliverables will be produced? How will we know when those deliverables are complete? If key stakeholders keep moving the goal posts, we’ll never complete the plan. So force agreement on a phased or iterative approach if necessary.  What is needed now? What can be done later?

3 – Lay Out the Detail

Creating alignment means setting expectations – at a deep level. Far too many projects are underplanned and insufficient detail promotes ambiguity, conceals the realities of time, effort and cost, and leads to unvalidated assumptions. Secure ownership and trust among team members by ensuring they are involved in defining the work, agreeing the details of hand-offs and validating completion criteria.

4 – Use a Trustworthy Process

A solid process for defining, organizing, planning, tracking and controlling the project is at the core of good project management. Talking the team through the process builds credibility. Implementing that process (walking the talk) generates motivation and commitment. Recognizing the difference between PMBOK and a practical, step-by-step, end-to-end project management process is a pre-requisite here.

5 – Feedback Smart and Often

Insist on efficient and frequent review cycles. Avoid wasting people’s time in meetings by getting status updates beforehand. Use the meetings to review overall progress, solve problems and decide on adaptive action. Check in with team members regularly and reward good performance swiftly. Keep key stakeholders appraised of progress and ensure bad news is acted on, not hidden.

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 Four Steps to Saving Troubled Projects

    The right people, process and tools to the rescue

    When projects get seriously off-track, normal project management techniques will not be enough to turn things around. Instead, a carefully executed four-phase process offers the best chance of recovery.

    1 – Launch

    The first step is to officially launch a rescue mission and that involves stakeholder recognition of the trouble the project is actually in – and a commitment to do something about it. Evaluating the project against a set of performance metrics can help determine whether a recovery process should be initiated; earned value is a natural choice but others should be considered too, such as issue backlog, change volume, defect rates and customer feedback. If the metrics exceed normal tolerances and/or stakeholder sentiment is a demand for action, then the Sponsor should appoint an individual to lead the assessment and recovery effort.

    Outcome

    • An Assessment Team Lead appointed with clearly defined authority and mission scope.

    2 – Assessment

    The Assessment Team Lead plans and conducts a structured investigation to segregate fact from fiction, and reality from hearsay, i.e. to determine exactly what the status of the project really is. This will involve deep scrutiny of project artifacts, interviewing project team members and analyzing the data gathered. The assessment needs to be fast, accurate and as non-invasive as possible (typically work on the project will continue uninterrupted during this phase).

    Outcome

    • A rigorously prioritized list of findings and a firm recommendation on recovery options and strategy.

    3 – Stabilization

    Unless the project is terminated after the assessment (occasionally the wisest choice), a Recovery Project Manager is appointed to prevent the situation from deteriorating further and to get control of the project. The focus is on resolving the highest priority issues, problems and defects, containing risks and re-planning. Specialized tools and micro-management techniques are deployed here to track progress with extreme intensity, optimize estimating reliability, run schedule simulations and establish a solid basis for the recovery plan.

    Now is therefore the time for making tough decisions on necessary changes in order to salvage an outcome of some desirable value. Consider re-negotiating deadlines, making personnel changes and adjusting budgets, resources, scope boundaries and quality parameters.

    Outcome

    4 – Recovery

    Led by the Recovery Project Manager, the re-baselined plan is now implemented, accompanied by appropriate changes to communications practices and to all processes for tracking and reporting progress and managing issues, risks and changes. Much attention must be given to restoring confidence in the project and its stakeholders and building morale of the team.

    The recovery team may remain in place through to the end of the project or until suitable exit criteria have been satisfied, such that another project manager and core team are deemed ready, willing and able to take over.

    Outcome

    • A recovered project.

    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 Six First Steps for the Project Manager

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

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