Archive for August, 2010

PostHeaderIcon A Quote for Closeout

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

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.