pm-lotus by Howard Vaughan

Posts Tagged ‘Risk’

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

There are several methods for identifying project risks but the best approach involves the team (at least the core team members and any relevant SMEs and/or PMO staff) and considers the following:

• History (review past projects of a similar nature – surprising how often this is missed)
• Context (assess the stakeholders, implementation environment and constraints)
• Boundaries (review the project’s SOW, scope and deliverables)
• Details (review the WBS, dependencies, estimates and resourcing)

The Nominal Group Technique

To get optimum input on possible project risks, there is no better team method than NGT. It leverages the advantage of multiple perspectives, can be done relatively quickly and avoids all the pitfalls of brainstorming, which is over-used and usually poorly facilitated. Here’s how NGT works for risk identification:

1. Each individual reviews history, context, boundaries and details (as defined above) and writes down their own list of possible risks – i.e. with no interaction between members
2. With the team grouped together, all identified risks are then captured by going around the team, taking the first item on each person’s list, then around again capturing the second item and so on until all items have been captured
3. Duplicates are removed from the consolidated list and descriptions clarified as needed
4. Each person reviews all the risks captured and the team decides if any should be removed the listing, on the basis of being extremely unlikely AND with little or no impact

Once this process is complete, the team can move to assessing the severity of the remaining risks, prioritizing them and defining response strategies to manage them.

Lots of Benefits, not much Downside

Using NGT is a great way of aligning the team on project risks. Its thorough, avoids groupthink, rapidly builds awareness, avoids jumping prematurely into risk analysis and prevents outspoken individuals unduly dominating the final risk list.

Plans are not crystal balls. They are at best a logical and reasonable perspective of the future but no more. Every project involves uncertainty and uncertainty implies risk. And there is no such thing as a risk-free project. I call this the Fourth Law of project management.

All of which has a serious implication for project managers – the need to properly account for risk. The fact that plans are incomplete views of the future means they are always at least slightly wrong. Even if we correctly identify all the tasks and activities to be performed, errors will always exist in assumptions, duration and work estimates, task dependencies and so on.

Most project managers appear to ignore most risks (witness the lack of risk readiness as evidence) . Yet threats can and do suddenly materialize. But sudden does not necessarily mean unpredictable. Experience and a little structured thinking can expose potential threats that we can get ourselves prepared for:

5 Essential Steps to Managing Risk

1 – Get Prepared

• Determine how complex your project is and how much unmanaged uncertainty you (and the project sponsor) can tolerate, i.e. how important is risk management for your project? Then decide on the process you will use and brief your core team accordingly (risk management is not a solo effort).

2 – Identify Risks

• Review project documentation – business case, SOW, charter, plans (WBS especially) and assumptions to seek out sources of uncertainty, potential error and change. Wear the hat of Murphy – “If it can go wrong, it will go wrong.” Remember, this involves core team members, not just the PM.

3 – Assess Risks

• Evaluate each risk for (a) the likelihood of the risk occurring and (b) the potential impact to the project if the risk does occur. Rate the severity of each risk on these two dimensions. High likelihood and high impact means for those risks at least, response plans will be a necessity.

4 – Develop Risk Response Plans

• Evaluate alternative response strategies. Ask these questions: How could you avoid the risk? How could you reduce likelihood? How could you reduce impact? How could you transfer the risk to another party? Could you accept the risk with a just-in-case contingency or backup plan? If so, how would it work?

5 – Monitor Risks

• As the project progresses, risk monitoring should be a regular item on the agenda, week after week. Have any risks occurred? Are the response plans working? What has changed that might cause new risks?

These are the essentials. Large complex programs will take these steps to a very deep and sophisticated level. But even the simplest of projects will benefit from the same basic steps. Scalability, as ever in project management, is the key.

Here’s a good way to think about all this-

Ignoring project risks is the first and biggest risk to the project.

(See all 5 Laws summarized in The 5 Laws of Effective Project Management)

Its always amazing how small things can make a big difference in the world of project management. Consider the describing of a risk:

The Wrong Way

Oftentimes we see a ‘shorthand’ approach used – for example, a risk captured simply as “Insufficient resources”. The danger (the risk?) of such a brief description is that it creates three problems:

• We misinterpret what exactly was meant (Which resources? On which tasks? With what consequences?)
• We may not correctly assess the risk’s importance because of the description’s ambiguity
• We can’t remember what we meant when we revisit the risk log at a later date

For these reasons, it makes good sense to describe a risk in a way that clearly states the possible situation and its effect.

The Right Way

A recommended approach is to write a risk like this:

EVENT may occur WHEN, thereby causing IMPACT

So rather than a bland, ambiguous risk statement such as “Lack of training”, we drill down and explain clearly what is meant – maybe:

“Competing work commitments may prevent staff attending the training, thereby slowing adoption of the enhanced project planning process.”

Now its clear. We understand both the effect and its root cause. Clear statements of what we really have in mind when we identify risks promotes consensus in (1) understanding the risk, (2) assessing its importance, and (3) generates more creative thinking in the development of risk responses. A little extra effort for a big benefit.

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.

This might have been alternatively titled “Questions we are Occasionally Afraid to Ask”. Here’s the situation:

You’ve been appointed to project manage a new initiative. You know that effective project sponsorship is a critical success factor and so you set up a meeting with the project sponsor.  You want to be sure you’re starting out with the right kind of backing. The sponsor wants to discuss the budget (or maybe golf) but first, you have some big questions you need answers to…

1 – Do you understand your role?
Its a fact – many project managers I meet complain that their sponsor has little idea about their role and responsibilities. You may need to help them out here.

2 – Do you know what you want?
There’s not much more frustrating than a sponsor who isn’t sure about what should or should not be included in the project. A fuzzy sponsor means you could be in for a long road trip of about-turns – do, undo, redo, …

3 – Can I count on your support?
Or more specifically – will you truly champion our project? This means advocating the project at higher levels, helping maintain visibility and interest in the project with key stakeholders, providing adequate funding and obtaining resources.

4 – Will you be available?
No doubt about it, sponsors are typically busy executives. This means their time is limited and they may be hierarchically or geographically remote. You DO need those face-to-face meetings. Lock them into their calendar.

5 – Can you give me clear priorities?
What are the primary project objectives? Which is least flexible – schedule, scope or resources? (Hint to sponsor- you can choose only one). Which is most flexible? Why?

6 – Do you understand that project management is a discipline?
In pushing to ‘just get it done’, countless projects ignore the importance of proper planning and systematic tracking… and pay a high price. A sponsor who doesn’t appreciate this means we’re already in trouble.

7 – Do you know what a solid project plan looks like?
The sponsor has to approve the plan that lays out what will actually be done- so it might make sense to ensure they actually have an understanding of what a good plan looks like. If necessary, give them a Plan Review checklist and an ‘Executive Briefing on Tactical Planning’ (so they know a WBS from a critical path).

8 – Will you inspect what you expect?
Not much point in a sponsor’s list of expectations if the relevant questions are never going to be asked. Generating information, reports and updates that don’t get reviewed is a fast track to morale hits and trust breakdown.

If the sponsor answered these questions correctly, you’re likely to be in good shape. (Hint for sponsors- the correct answer is “Yes” to all questions). If not, then you just identified some additional risks to the project…

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)

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)