pm-lotus by Howard Vaughan

Posts Tagged ‘Reporting’

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.

Every project should be closed with a proper review of lessons learned. I’m always amazed at the tremendous amount of feedback, ideas and value that comes out of a well run project closeout review session. Regrouping the team for this one final meeting is one of the most important events in the life of the project.

The agenda for this meeting – best run as a facilitated workshop – should comprise these three items:

1 – What Worked?
2 – What did Not Work?
3 – What must we Do Differently Next Time?

Structure for Best Results

Some structure around each of these will maximize the quality of the output. For example, solicit feedback with respect to specific areas, such as:

• Categories – Planning, Resourcing, Risk Management, Requirements, Technology
• Enablers – Commitment, Competence, Communications (see The Fifth Law)
• Phases – Solution Design, Development, Testing, Deployment.

This provides proper focus and balance for identifying lessons learned. Also, use of the Nominal Group Technique in the workshop ensures the optimal mix of individual contributions and team discussion.

Lastly, just capturing lessons learned is only half the job. In the spirit of ‘kaizen‘ or continuous improvement, they each need to be transformed into action items for implementation, in order to guarantee future projects will use them.

There are countless variations on content for project progress reports but there are ten items that should be on every report:

1 – Business Context
Why does this project exist?
Briefly summarize the desired business outcomes as a reminder to all of the rationale for doing the project – and include the names of the sponsor and customer.

2 – Objectives
What are the project’s tactical objectives?
Always keep the schedule, scope and resource goals in view. The Project Objective Statement provides a concise way of describing these.

3 – Flexibility Matrix
Which is least flexible – schedule, scope, resources?
Reflect the Flexibility Matrix on the report to remind stakeholders of the project priorities.

4 – Schedule
What is the schedule performance of the project?
Identify variance of current progress and forecasts against the baseline schedule for key milestones, phases and/or deliverables. Better yet, include performance trends over the past few reporting periods.

5 – Cost/Resources
Is the project meeting cost and/or staffing targets?
Point out significant variances with the plan such as staffing shortfalls or cost overruns.

6 – Risks
What significant risks exist?
Highlight those risks of highest severity and in particular those with high impact that may occur soon.

7 – Issues
What significant issues remain unresolved?
Identify the key issues and what is preventing their resolution.

8 – Changes
What changes have occurred?
Identify any major changes that were approved and/or implemented since the last progress report.

9 – Accomplishments
What has been achieved?
Capture the most important recent accomplishments such as completed deliverables, milestones that were met, or finished major work components.

10 – Next Steps
What major components of work remain?
Indicate what the focus will be for the immediate future and set expectations of what will be reported on in the next progress report.

Configuring these vital ten into a 1-page format is ideal for executive presentation. These items are of course in addition to the more obvious title and subtitle mentions of project name, report date and author/project manager name. (Surprising how often the obvious gets overlooked).

When I first started in the project management services business, I was repeatedly led to believe that the construction industry was the beacon of leadership in project management maturity. My own experience over the years tended to question that wisdom and now the truth is out that this is indeed all nonsense. According to a recent survey by the Chartered Institute of Building (CIOB), which represents 42,000 members and sets standards for the management of the total building process, the construction industry has much to learn about project management.

The Shocking Truth

Not a towering force in project management

The survey results are based on data from 73 companies and over 2,000 projects. Its conclusions are available on the CIOB website – you can also watch an interesting video of the CIOB president Keith Pickavance presenting the results at the Project Management Asia Conference 2008. They make for a highly uncomplimentary denunciation of the state of project management practices in the industry- for example:

• less than 15% used a linked network to define the schedule
• more than 50% used only simple bar charts
  • (no chance of a critical path)
• more than 50% used paper (not computerized) records
• less than 15% kept logs of changes
  • (not much good in court)
• 95% did not report delays to progress because they:
  • hoped no-one would notice
  • hoped they could catch up
  • did not want to upset the client
  • thought they could blame someone else.

Its not a pretty picture. Little wonder then, that the industry is dogged by delays, compensation claims and disputes.

The Way Forward

Clearly there is a need for some serious project management skills development. In the words of Mr. Pickavance himself:

We have no standards, we have no training, we have no qualifications.

All of which should be manna from heaven for project management educators, particularly in those regions where construction investment is being pumped up to help resurrect limp economies. Assuming of course that the building firms are open to changing their ways.

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’:

• Are deliverables defined with clear boundaries?
  • Are there detailed and explicit descriptions of inclusions and exclusions?
• Are completion and acceptance criteria clearly stated for each deliverable?
  • Do we know what “done” looks like for each deliverable?
• Are tasks defined at an appropriate level of detail?
  • Are most tasks in the range of 4-40 hours of duration? (a useful guide for most projects)
• Are task outputs tangible?
  • Have the outputs been agreed upon by their owners and dependents?
• Is progress tracked at task level?
  • Is evidence of progress validated before being reported upward?

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)

Custom fields in Microsoft Project offer a host of possibilities for tracking and managing schedules. I like to use the indicator functionality to help monitor and control progress. In the example below I’ve used the custom field “Number1″ to indicate task status based on total slack.

Here’s how to set this up-

• Select Tools, Customize, Fields
• Select the field “Number1″
• Click Rename to relabel field as “Schedule Indicator”, then OK

• Click on Custom Attributes, Formula
• Enter the formula:
  IIf([Baseline Finish]>100000,-1000,IIf([Actual Finish]<100000 And [Finish Variance]=0,-998,IIf([Actual Finish]<100000 And [Baseline Finish]>[Actual Finish],-998,IIf([Actual Finish]<100000 And [Actual Finish]>[Baseline Finish] And [Finish Variance]>0,-999,[Total Slack]/480))))
• Click OK

• Click on Values to Display, Graphical Indicators, and set up the images in the order below:
  White = -1,000 (will show tasks that are not baselined)
  Blue = -999 (tasks that finished late)
  Dark green = -998 (tasks that finished on time or early)
  Red <=  -5 (incomplete tasks that are late by 1 week or more)
  Yellow <= 0 (incomplete tasks that are up to 1 week late)
  Green >= 0 (incomplete tasks that are early or on time)
• Click OK, OK

Lastly, we set a Deadline on the Project Complete milestone to provoke negative slack values when behind schedule-

• Double click on the milestone name, then go to Task Information, Advanced, Deadline

That’s about it!