Wednesday, September 10, 2008

A Pragmatic Model for Managing Project Risks (3)

Project Kickoff/Planning Phase

Project Risk Review

Key Activities
  • WBS
  • Stakeholders
  • Requirements
  • Resources
  • Solution/Technology
  • Environmental

While performing project risk review:
  • Focus on risks that could affect the satisfactory completion of the project. The key objective at this stage is to ensure successful project delivery, as compared to Concept stage which is to decide if a project should go ahead.
  • The team better refer to a framework of risk sources or risk checklist based on past experience.
  • This can be an individual or group exercise, depending on the size of the project.
  • In general the more experienced the project team the easier they can develop counter-measures and response plan.

What to review?
  • WBS & Schedule – Too tight? Unrealistic?
  • Requirements – Unspecific? Unclear?
  • Stakeholders – Who? Participation/Commitment? Hidden agenda? Resistance to change?
  • Resources – Sufficient? Probability of change?
  • Solution/Technology – Too new? Interface? Compatibility with existing platform?
  • Environmental – Compliance? Org change?

The outcome of the review is a short list of risks (no more than 10!) with high priority and their mitigation plan. The list typically consists of some common risks such as:
  • Unclear scope – Early user involvement, systematic approach in requirement gathering & analysis, change control formulation & buy in etc.
  • The end users do not know what they want - Perform focus group analysis; Formulate a more detailed user requirement gathering exercise with 2 prototype stages planned;
  • The user division keeps changing their requirements - Set up a change control system, and get their buy in from user division.
  • Unrealistic Schedule - Negotiate for a better schedule; Identify areas that can be outsourced.

The list may also contain some specific risks that require special attention and mitigation strategy. For example:
  • Use of new technology – Training; delivery in phases (pilot and full).
  • Regulatory compliance issues – Have compliance division check current status.

There are two overall risk control strategies that should be applied for every project:

Change Control

A well communicated and agreed upon Change Control Process is very effective in:
  • Reducing unnecessary changes;
  • Encouraging user groups to think carefully about requirements in early stage of the project;
  • Balancing scope change with other success criteria such as cost and schedule.

Negotiation
  • Negotiate everything – schedule, resources, $$, people, requirements, deliverables…
  • Negotiate early.

To be continued…

Copyright © 2008 Knowledge Century Limited.

Friday, August 29, 2008

A Pragmatic Model for Managing Project Risks (2)

After a two-week summer break, let’s get back to our pragmatic model for managing project risks.

First a few rules:
  • Apply 80/20 - By 80/20 we mean this model does not try to do everything. Instead we focus on the activities that yield the most results.
  • Optimize total cost of risk management – We try to optimize the cost of prevention, mitigation, transference and acceptance. We even allow passive acceptance as a valid response if it generates less cost that doing something else. Passive acceptance means doing nothing, and if those risks happen, they happen.
  • Target small and medium projects – A significant proportion of business and technology projects are small and medium projects. Well we admit that the definition is not clear. Let’s just say any projects less than US$ 1m value are considered small and medium. Our argument is there is no need to apply everything in those formal methods to these projects.

An outline of our pragmatic model is shown below:














We divide a project into three distinct phases: Concept/Approval, Kickoff, and Execution. We propose several key risk activities during these three phases.

Concept/Approval Phase

Business Risk Review
Key Activities
  • Business Case
  • Stakeholder Analysis
  • Scenario Analysis
  • NewspaperTest

Project sponsors and top management reviews the project’s business case, potential financial return, tangible and intangible benefits, and risks involved. Risks can come from financial impact, stakeholders’ responses, and potential damage to organization’s public image if anything goes wrong, and so on.

Particular attention, in my opinion, should be paid to negative publicity generated. There have been several recent business projects that went out of hand, eventually leading to extremely damaging responses.

A local supermarket chain launched an initiative to charge 50 cents for each plastic bag handed out to their customers. Customers’ feedbacks were extremely negative. There were even reports of sporadic instances that some customers quarreled with cashiers trying to get free plastic bags. The initiative was eventually cancelled one week later by the supermarket chain without proper explanation, resulting in even bigger outcry from the public. From a project management perspective, we would argue that implementation plan had not been well thought out (measures such as phase lead-in and publicity campaign were missing). More importantly, risk of possible poor publicity had not been highlighted to senior management. Had scenario analysis been performed, senior managers surely would have been brought to this likely outcome. The likely decision would have been a no-go.

The key objective of performing risk activities during this stage is to make go/no-go decision for the project.

To be continued…

Copyright © 2008 Knowledge Century Limited.

Saturday, August 9, 2008

A Pragmatic Model for Managing Project Risks

So now what? If our daily experience and even a research report shows that formal risk management methods are not applicable to small and medium size projects, are there any alternatives available?

Well let’s explore a pragmatic model for small & medium projects. First let’s consider a real life situation of moving you home.

Just say you bought a new apartment from a property developer 9 months ago. It’s scheduled to close 3 months later. You plan to move to the new apartment as soon as possible. What’d you do to minimize risks for this project?

Below is a list of typical tasks for your home relocation project:

  1. Hire a solicitor
  2. Negotiate and confirm a bank mortgage
  3. Perform pre-closing examination of the apartment
  4. Conduct formal closing
  5. Select and hire a contractor for minor renovation
  6. Contractor performs renovation
  7. Order and install utilities such as electricity, gas, phone, internet, TV
  8. Buy and deliver furniture
  9. Move to the new apartment


Examples of risk include:

  • Bank mortgage cannot be secured;
  • Apartment quality not up to expectation;
  • Developer postpones closing date;
  • Contractor fails to perform;
  • Renovation requires longer time due to contractor failure or unexpected events;
  • You are made redundant by your employer before closing;
  • You move to a new job, and so on.

There are also risks that are quite unlikely to happen, but still exist:

  • Developer bankrupt; bank withdraws mortgage;
  • Contractor sick or other accidents; and so on.

Typical approach for dealing with risks of this scale:

  • Gain as much knowledge and lessons learnt by talking to your friends who have previous experience or professionals such as property agents or solicitors.
  • Identify critical tasks and milestone dates (e.g., “Secure bank mortgage”, “Formal closing”, “Renovation complete”, “Move to the new apartment”). Try to schedule them in proper sequence and with as much buffers as possible.
  • For non-critical activities (such as “Buy and deliver new furniture”), try to schedule them with a large comfort margin or better with no dependency to other tasks.
  • During the project, monitor closely the progress of critical activities, and control them carefully.
  • Minimize changes (e.g. a new design proposed by your contractor in the middle of renovation, changing your job etc.) within the life cycle of the project.
  • For risks that are unlikely to happen (e.g. Developer bankruptcy), do nothing until they happen.

Note that (1) we start identifying risks and countermeasures by focusing on the WBS or task list; (2) we don’t apply a risk-by-risk analysis and response planning approach, instead we just apply an overall framework of careful WBS planning and close monitoring during execution; (3) we adopt reactive approach for those unlikely risks.

Hey, isn’t this common sense? Yes this is exactly the point we are trying to bring up. Risk management is not rocket science. Although there are all those formal methods, projects of smaller size only require some careful planning based on past experience and common sense. This is the first step to take away the myth surrounding risk management.

We’ll argue later that the same approach can be applied to projects in a business setting.

To be continued…

Copyright © 2008 Knowledge Century Limited.

Monday, August 4, 2008

A Risk Management Research Report in Hong Kong (2)

Let’s continue with the results of the research paper. Interviews with the 25 experienced project managers revealed their FOUR risk response strategies – Control, Negotiation, Research, and Monitoring.


Control Strategies

Control Strategies

Descriptions


WBS

- Understanding requirements
- Assessing staff skills required, technology & solution etc.
- Detecting and negotiating over-ambitious target schedule

Progress Control

- Close monitoring and control of each task’s progress

Change Control

- Tightly controlling clients’ change requests, sometimes through contract T&Cs


Documentation

- Documenting all changes
- Controlling all documents for advantageous position in disputes


Reactive Problem Solving Strategies

- Increasing available person-hours (OT)
- Rescheduling and problem isolation


Negotiation Strategies

Negotiation Strategies

Descriptions


Change Control

- Assessing clients during pre-sales to determine the best approach
- “Hard” vs. “Soft” approach


Trust & Relationship Building

- Mitigation for all relationship risks
- Trying to put self into others’ shoes


Managing Client Expectations

- Recalibrating client expectations from the start
- Being honest


Balancing Cost, Schedule, and Scope

- Reprioritization of time, budget, or quality, e.g., postponing less critical req. to 2nd phase
- More resources or lower profits

Escalation

- Last resort

Team-building

- Building and maintaining commitment through lead-by-example & sharing decision making


Research Strategies

Research Strategies

Descriptions


Studying & Self Education

- Forming special team researching and studying new technology issues
- Requirement study trying to identify potential pitfalls in solution or technology


Monitoring Strategies

Monitoring Strategies

Descriptions


Constant Surveillance

- Paying special attention to potential problem areas identified during implicit assessment and evaluation of the project surroundings and contexts
- No preventive action
- Helping to shape negotiation strategies

In summary, these project managers:

  • Relied on contingencies built into the schedule (by pre-sales)
  • Applied broad project management strategies, regardless of specific risks identified

There is little evidence that they:

  • Revisited pre-sales risk checklist
  • Made own independent risk assessment


This is in complete contrast to formal Risk Management methodologies that emphasize on risk-by-risk analysis and response. Neither do the findings match recommended practices of proactive planning – Negotiation strategies, based on good relationship, were usually adopted in a reactive manner. Some practices such as Overtime (OT) are not completely in line with best practices.

There is NO risk quantification at all, as recommended by formal methods.

In the beginning of the research, it’s already established that this group of project managers were competent and knowledgeable in formal PM methodologies. So why were they not using formal risk methods? Is using broad risk strategies more effective than risk-by-risk approach for small/medium size projects?

To be continued…

Copyright 2008 Knowledge Century Limited.

Tuesday, July 15, 2008

A Risk Management Research Report in Hong Kong

In our previous articles, we’ve discussed the importance of risk management in daily life. For corporate projects, risk management is a discipline that draws a lot of attention and executive effort. Formal methods for project risk management have been well established by organizations like PMI. However we’ve pointed out some of their limitations in applying to projects. So are there any research reports that tell us the current state of risk management in projects?

“Risk Management and Problem Resolution Strategies for IT Projects: Prescription and Practice” by Hazel Taylor of University of Washington was published in Project Management Journal, Volume 37, Number 7 in Dec 2006. The paper is based on research done in Hong Kong in the IT sector for large-scale IT projects. Twenty-five project managers were selected from twelve companies for interview. A total of 60 implementation projects involving extensive customization, development, and consulting work were discussed.

It’s essential to look at the profiles of interviewees in the research. Information collected from this group of project managers has to be representative and their competence and experience directly affects the credibility of the research results. Below is some background information of the interviewees:

  • Recognized by their respective organizations and peers as proficient and experienced in PM
  • Demographic information: 18 Chinese, 7 foreign
  • All well-versed in typical project management methodologies such as PMBOK
  • All had trained or worked abroad, and all had experience working with people from other cultures

So they were not rookie project managers. Instead they were all well-established professional managers within their own organizations, and knowledgeable about PM methodologies.

The paper tries to identify risk sources in typical IT projects. The response strategies and counter measures this group of project managers adopted are further investigated. The goal is to understand what risk management practice is used in real life situations.

Risk Factors Identified

There risk factors identified are classified into four main themes – Project Management, Relationships, Solutions ambiguity and Environment. Below are sample risk sources associated with each theme. For a full list, please refer to the original paper.

  • Project Management – Staffing resources, change management, schedule and budget, sign-off control
  • Relationships – Team morale, expectation management, management support
  • Solutions Ambiguity – Newness and complexity, technical environment, functionality
  • Environment – Reputation, legal and credit risk, contract terms and conditions


To be continued…

Copyright 2008 Knowledge Century Limited.

Wednesday, June 25, 2008

Formal Risk Management Methods (2)

In our last article, we've discussed a basic framework of all formal project risk management methodologies. They basically follow a life cycle of Identification -> Analysis -> Response Planning -> Monitoring and Controlling. Below we discuss some common techniques throughout this cycle.

Risk Identification

Document review is a common technique for identifying risks at the early stage of a project. Review of project plan, schedule, WBS, resource plan, cost budget, quality plan and so on can generate useful ideas about where the risks lie.

Other meeting-based risk identification tools include interviews, brainstorming, and Delphi technique. Interviewing is very common in real life. A project manager would try to gather as much information about the project through talking to other project managers, the customer, other team members, internal units, vendors or anyone who would be involved in the project. Risks would be identified along the way.
Risk Analysis

There are basically three elements of risks - Event, Probability, and Impact.
















The above framework is very popular in analyzing risks and their associated priority. There are many variations depending on the level of granularity required. In my opinion, however, a 3x3 table is sufficient for most purposes. I've seen company using a 7x5 or 7x7 scale. There is a false sense of accuracy when people are using a more granular scale. However, bear in mind that any estimate of the probability and impact of a risk, especially probability, is only an 'educated guess', and may deviate from the true picture by a wide margin. So what is the point of using a seemingly fine and accurate scale? Garbage in, garbage out, right?

Risk Response

The risk response strategies of different formal methods are surprisingly, or shall we say unsurprising, similar. For example, PMBOK published by PMI enlists four strategies for negative risks or threats: Avoid, Transfer, Mitigate, Accept. In the NIST 800-30, they are Assumption (a form of Acceptance), Avoidance, Limitation (similar to Mitigation), Planning, Research & Acknowledgement, and Transference. For the Risk Management Standard published by IRM, AIRMIC and ALARM in the UK, the risk treatment approaches are Control, Mitigation, Avoidance, Transfer and Financing. You can see they refer more or less to the same set of strategies, and stay at a high level without going into details how you can apply them in real life.

Risk Monitoring

Again the formal methods lack in-depth guidance here. Most of them ask you to keep monitoring status of existing identified risks, and take heed of any possible new risks. Should any risks materialize even after mitigation or limitation measures have been applied, the pre-meditated contingency plan should be carried out.

One tool that is useful for keeping track of risks, as well as for communication with stakeholders, is Risk Register. It's basically a list of identified risks with correponding attributes such as Category, Probability, Impact Level, Impacts (qualitative analysis such as scenario, or quantified measures such as financial loss), Proposed Action, Owner, and so on.













A Critique of Formal Methods

o
Formal methods share the following characteristics:
  • Risk-by-risk approach
  • Emphasis on proactive and preventive planning
  • Regular formal meetings for monitoring and review, likely at different levels
  • Formal documentation and reporting (risk register/ risk log, risk report)
There are a few observations about the limitation of formal Risk Management methods:

o
  1. Definition of Risk too narrow - All focus on the success of the project, instead of expanding the definition to include impacts on the organization and stakeholders involved.
  2. Highly dependent on organization culture, formal structures and processes - If the organization or client do not support these methods, there is no way a project manager can apply them.
  3. Heavy on planning, light on follow-up action - Just like any existing methodologies, the processes and tools & techniques included for Risk Planning are the best written and provide the most insights. Comparatively, the Control & Monitoring section is rather weak and lacking details.
  4. Difficult to quantify probability and impact, hence risk level is only an educated guess.
  5. Show me the money! Is it more expensive to apply formal risk methods, in particular for small or medium projects, than simply take a reactive approach?
Next, we'll share with you insights provided by a research paper in Project Risk Management done in Hong Kong.

To be continued...

Copyright 2008 Knowledge Century Limited.

Monday, June 23, 2008

Formal Risk Management Methods (1)

What are the popular formal Risk Management standards nowadays?

There are different standards for different industries and functional areas. Since our theme is about project management in the business and technology sectors, we just list several standards that are well accepted in these sectors and relevant to our discussion. These include PMBOK 2004, AS/NZS4360:2004-Risk Management, UK Risk Management Standard by IRM/AIRMIC/ALARM, and NIST 800-30 Risk Management Guide for Information Technology Systems.

We do not intend to go through them one by one. Instead we want to highlight some commonalities among them.

Definition of Risk

PMBOK: An uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives.

Risk Management Handbook by Max Wideman: The cumulative effect of the chances of uncertain occurrences which will adversely affect project objectives.

APM / BS: Combination of the probability or frequency of occurrence of a defined threat or opportunity and the magnitude of the consequences of the occurrence.

RUP: An ongoing or upcoming concern that has a significant probability of adversely affecting the success of major milestones.

Notice that all definitions focus on impacts on the successful delivery of a project. This definition may not be entirely relevant to the business world. For a real-life project, anything that can jeopardize the organization, stakeholders, or even the project manager herself, should be considered risks. The project itself is just a means to an end - the ultimate business objectives of the project, which is usually some tangible/intangible benefits to the organization or a group of stakeholders. If something bad may happen to them as a direct or indirect results of the project, they are to be considered risks and be probably managed.

Common Logic of Formal Risk Methods













All formal methods follow more or less the same logic.

Step 1: Identify risks
Step 2: Analyze risks (can be both qualitative and quantitative)
Step 3: Plan risk responses
Step 4: Monitor and control risks

In the next article, we will continue to explore formal methods for handling project risks. Some of their drawbacks and practicalities in the real world will also be discussed.

To be continued...

Copyright 2008 Knowledge Century Limited.