Managing Projects in Asia

I've had the privilege of working in a multi-cultural environment in Asia for many years. So many times I've seen conflicts arising from a clash of values, practices, and behaviors due to diverse cultures, particularly between people from different parts of the world. The old saying "East vs. West" may be a bit simplistic, but it's not far from the truth that Westerners do not truly comprehend subtleties of Asian culture.

I presented a paper three years ago at the first PMI Asia Pacific Congress in Singapore. The feedback to the session was very good and many people came back to me for more advice. I'll use this blog to share both this paper as well as some new thoughts on this topic.

Introduction

Over the past thirty years, Asian cultures have become a dominant theme when companies are considering business ventures or making investments in Asia. It started with Japan in the seventies, then the four “little dragons” – Hong Kong, Korea, Taiwan, and Singapore in the eighties, and then China, India, ASEAN, and the rest of Asia in the nineties. When managers from the West thought that they’d understood Asia based on their experience in one country, they discovered that in another not-so-far-away country, people with similar color and look think and behave differently. We are talking about a very diverse cultural environment – multi-racial, varied historical background, different values, and multi-lingual, in Asia.

Hand-in-hand with business ventures and investments are projects. So project managers are facing more or less the same, if not more complex, cultural issues. Even experienced managers with good people management skills find it daunting to manage projects in Asia which has more than thirty countries/territories based on geographical classification (excluding Pacific Islands), at least ten major languages spoken, and more than twelve major economies. A project manager typically faces issues like miscommunication, clash of values, disparity in religions and customs, misunderstanding resulting from petty etiquettes, and difficulties in motivating people.

This paper will provide an analysis of Asian culture from four perspectives that a project manager is most concerned with – Authority, Conflicts and Their Resolution, Team Motivation, and Negotiation. Asians exhibit dissimilar behaviors and thinking due to their diverse cultural background, yet on a closer look some commonalities exist in most countries irrespective of their geographies, ethnicities, and languages. Based on real-life experience in managing large and complex projects in Asia, this author will share his views on handling tough cultural issues and conflicts, and offer a list of do’s and don’ts. In particular, he will focus on areas that have prevalent impact on a project, namely stakeholders’ interests and behaviors, team building, and conflict resolution, all under the context of diverse cultures.

To be continued...

Copyright © 2008 Knowledge Century Limited.

A Pragmatic Model for Managing Project Risks （4 and Final）

Execution Phase

During the project execution phase, risks should be regularly monitored and properly controlled. Just like any other activities during execution, this sounds like common sense, and I’ve not seen any organizations that say they are not doing it. There are also no hard and fast rule on who, what, when or how to do it. Overall speaking, we think the following guidelines should add value:

Regular meetings – Most people include risk review as part of the regular progress meeting. For really large projects there may be separate meetings. Sometimes regular meeting may not be able to help the team to deal with some unforeseen and urgent risks. Having said that, this is still the occasion when risks can be detected through discussion with team members.

Alertness to risks and open communication –Most risks can be discovered early if every project team member is alert to symptoms of risk. A seemingly harmless comment from the client, a minor concern expressed by a senior executive, or a report on the newspaper about your client being acquired by another company – All of these can indicate trouble for the project you are currently handling. And one person cannot do it all. If all team members have a high level of alertness to risk that would be a big plus to your project. Sure this sounds easier said than done, or even a bit far-fetched. In real life this differentiates a good team from an ordinary one. The project manager should at least cultivate an atmosphere of open communication and encourage sharing of any signs of risk, no matter how unlikely or remote they look, within the team.

There are a few things that should be consistently and regularly done to properly control risks:

Documentation – This is a very effective impact mitigation measure, in particular if there are external organizations involved. For example, vendors can use documentation such as meeting minutes, project reports etc. to protect themselves in an unfavorable situation. For in house projects, documentation can also be used by the project team to shield themselves from unnecessary accusation, albeit to a lesser extent.

Negotiation – This is a very effective means to avert the course of risk, or at least to reduce impact of certain risks. Before and during negotiation, you need to understand: What is at stake? The degree of criticality of each project objectives to key stakeholders? What are your bargaining chips? Any evidence to support your arguments? (Supportive documents would be very useful here.)

Communication - Information transparency through effective communication is an effective means to:

• Foresee new risks and re-evaluate known risks
• Avoid or control damage from risks
• Get support from senior management
  
• Open communication strengthens team spirit and the sense of being in a team. However, project team needs to be political savvy for external communication.
  

So that’s it. Our discussion of managing project risks stops here. Although we’ve spent 11 posts over a time span of 3 months to explore the subject, this can only represent the beginning of a somewhat long and difficult journey to shape the best risk management methods for projects of various scales.

Copyright © 2008 Knowledge Century Limited.

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.

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.

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.

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.

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.