Archive for February, 2010

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 Project Management and the Four Cultures

Project Management and Culture - not always love at first sight

One of the most critical success factors in implementing project management is ensuring the right fit of processes and systems with the culture of the organization. Yet culture is such a wonderfully complex and seemingly amorphous thing that it can be hard to know what “fit” really means if we can’t define the characteristics and boundaries of the firm’s culture.

The Re-Engineering Alternative by William Schneider provides both a fascinating insight into organizational culture as well as a practical toolkit for determining your own company’s core culture. This is not a new book but it is a gem. Designed as an aid to improving organizational effectiveness by leveraging cultural norms and behaviors, Schneider describes how peeling back the layers of any organization will yield one of four dominant culture types.

Understand Your Culture

Each culture is defined in fine detail by comprehensively describing the leadership and management styles, strengths and weaknesses, structure, relationships and decision-making attributes that characterize them. Discovering the differences will help explain why organizations operate the way they do and, by extrapolation, why project management has to be tailored to be sustainable. Schneider terms the cultures as:

  • Control – structured, domineering, task-oriented
  • Collaboration – trust-based, empowering, people-centric
  • Competence – achievement-oriented, impersonal, excellence-driven
  • Cultivation – potential-fulfilling, creative, informal

If you’ve worked in a variety of culturally diverse organizations, you’ll quickly recognize the distinctive traits of each of these four cultures that are described in the book so clearly and with plenty of examples.

Culture Limits Execution of Strategy

As Schneider rightly points out, culture limits strategy. And since culture sets expectations, priorities, managerial practices and communication patterns, it also limits the execution of strategy – and therefore projects. Culture ultimately defines how work is planned, organized and managed – which is why it is such a crucial consideration in any effort to improve enterprise project management.

PostHeaderIcon Displaying the Late Schedule in MS Project

Knowing the latest dates that we can start and finish tasks without impacting the overall project schedule is key to effective time management, especially for those projects where schedule is the least flexible component (see Flexibility Matrix).

Like the critical path itself however, Microsoft Project does not display this information by default. But we can easily set up the display options to reflect the late dates as in the example below:

Late Schedule Example

Here’s how we configure this. First we display the critical path:

  • From the menu, select View, Gantt Chart
  • Then click the Gantt Chart Wizard button on the Formatting toolbar
  • Select “Critical Path”, then Finish, Format It, Exit Wizard.

The critical path tasks are now visible in red. Next we set up the late schedule for the noncritical (blue) tasks:

  • On the menu, select Format, Bar Styles
  • Then click Insert Row to add a row just above the Critical Path display row (note that inserting a row at the top of the list may not work)
  • Enter “Late Schedule” for the ‘Name’ and select your preferred bar styles for the ‘Appearance’ – (in the example above I used a navy horizontal line bounded by small triangles)
  • Select “Normal, Noncritical” for ‘Show For … Tasks’
  • Lastly ensure that you select ‘From’ “Late Start” and ‘To’ “Late Finish”
  • Click “OK”

Now you should see the late schedule bars showing for the noncritical tasks indicating the latest each task can start and finish.

Useful Information

Showing the columns for Total Slack (the difference between the early and late dates) and Free Slack (how long a task can be delayed without delaying a sucessor task) as in the simple example above tells us the following:

  • The critical path runs through tasks E, G, J
  • The noncritical tasks have varying total slack
    • Tasks B, C, H, L have only 2 days, so are near critical and should be monitored closely for any slippage
    • Tasks A, K have 7 days
    • Task F can be delayed by up to 11 days before the project finish date is impacted
  • Tasks B and C have zero free slack so any delay will immediately impact their successor tasks

Track the Slack

Knowing not only which tasks are critical and which are not, but also how much float or slack there is on each non-critical task, helps us prioritize work (according to slack value) and monitor trends in schedule variance (changes in slack week-to-week).