Previous month:
May 2012
Next month:
July 2012

Calgary Presentation - Working Effectively with Off-Shored IT Resources

DiversityOn Monday June 25th Calgary’s Agile Leadership Network meeting with feature Dr. Lionel Laroche presenting on “Working Effectively with Off-Shored IT Resources” the session is free, so come along if you can. The slides will be made available to those how cannot attend after the meeting at the Calgary Agile Leadership Network website

Presentation Outline:

"On paper, off-shoring IT work is a no-brainer – the salaries of programmers in India, Panama or Romania are a fraction of the salaries of programmers in Calgary. However, as most people who have worked with off-shored resources have learned, things are not as simple as they may seem, because managing off-shored resources is not the same as managing Canadian resources. Because people in different parts of the world think, communicate and behave differently in the same situations, projects that involve off-shored resources often experience significant difficulties, particularly at the beginning. This presentation examines the root causes of these difficulties and provides practical tips and suggestions that participants can readily implement when working with off-shored resources."

About the Speaker:

Over the past 14 years, Lionel has provided cross-cultural training, coaching and consulting services to over 25,000 people on four continents. Lionel specializes in helping organizations and professionals reach their business objectives in culturally unfamiliar contexts. In particular, he has worked with organizations like Sun Life, CP Rail, Fujitsu, PwC, CGI, AMD, Microsoft, Gennum, and many other overcome the challenges associated with working with off-shored resources and reap the corresponding benefits. Lionel is the author of two books, "Recruiting, Retaining and Promoting Culturally Different Employees" and "Managing Cultural Diversity in Technical Professions"; he and his business partner, Caroline Yang, are working on a third book entitled "Turning Cultural Diversity into a Competitive Advantage."

To register for this even click here. After the event the slides will be posted here.


Collaborative Games for Risk Management

Team_solutionsThis is the third part in a series on agile risk management; Part 1 looked at the opportunities agile methods offer for proactive risk management, while Part 2 examined the benefits of engaging the whole team in risk management through collaborative games and cautioned us about groupthink. This article walks through those games and explains how to engage a team in the first three of the six risk management steps.

The PMI risk management lifecycle comprises of:

  1. Plan Risk Management
  2. Identify Risks
  3. Perform Qualitative Risk Analysis
  4. Perform Quantitative Risk Analysis
  5. Plan Risk Responses
  6. Control Risks

These phases can be addressed collaboratively via the following team exercises:

  • Plan Your Trip (Plan Risk Management)
    • 4Cs: Consider the Costs, Consequences, Context and Choices
    • Are we buying a Coffee, Couch, Car or a Condo? How much rigor is appropriate and what is the best approach?
    • Deposits and Bank Fees – understanding features and risks
  • Find Friends and Foes (Risk and Opportunity Identification)
    • Doomsday clock
    • Karma-day
    • Other risk identification forms (risk profiles, project risk lists, retrospectives, user story analysis, Waltzing with Bears - Top 5-10 for software)
  • Post Your Ad (Qualitative Risk Analysis)
    • Investors and Help Wanted – classification and visualization of opportunities and risks
    • Tug of War – project categorization
  • Today’s Forecast (Quantitative Risk Analysis)
    • Dragons Den – next best dollar spent
    • Battle Bots – simulations
  • Backlog Injector (Plan Risk Responses)
    • Junction Function – choose the risk response path
    • Dollar Balance – risk/opportunity EVM to ROI comparison
    • Report Card – customer/product owner engagement
    • Inoculator – inject risk avoidance/mitigation and opportunity stories into backlog
  • Risk Radar (Monitor and Control Risks)
    • Risk Burn Down Graphs – tracking and monitoring
    • Risk Retrospectives – evaluating the effectiveness of the risk management plan
    • Rinse and Repeat – updating risk management artifacts, revisiting process

We will walk through the first three steps in this article and then the last three steps next month:

1. Plan Your Trip (Plan Risk Management)
This phase is about deciding and defining how to conduct risk management activities for the project. We want to tailor the process to ensure that the degree, type and visibility of risk management is commensurate with both the risks and the importance of the project to the organization. So we do not use a sledgehammer to crack a nut, or undertake a risky, critical endeavor with an inadequate process.

The other goal we have for this phase is to teach some risk basics to the team since they may not be familiar with the concepts or terminology. The name of the first exercise (“Plan your trip”) speaks to the goal of determining the appropriate level of rigor. Most people can associate with planning for a walk or hike, and this is the context we use for the activity called the 4Cs. Early in any collaborative workshop, I like to get people working. If you let them spectate for too long some will retreat into “observer” rather than “participator” mode.

Working individually (again to encourage active engagement, and avoid groupthink), ask the team to consider what they would pack for a two-mile hike in the country on a warm day. Give them a couple of minutes to create lists on Post-it notes and review their responses as a group. Some will suggest taking nothing, others just a bottle of water, rain jackets, bear spray (I live near the Rocky Mountains in Canada) and all sorts of other things. We then review the pros and cons of these items. They are useful if you need them, but a burden to carry. We then repeat the exercise changing some parameters such as making it a 10-mile hike or a multi-day trip in the mountains during winter. Now the lists get longer as people prepare for more eventualities.

For each situation, we review the 4Cs: the Costs, Consequences, Context and Choices. What we bring (and how we prepare for risk management) varies based on the cost of bringing/using it, the consequence of not having it (rain coat: get wet; warm jacket : cold/hypothermia). We also examine the context we are talking about: preparations for elite ultra-marathoners who are hardy, capable and resourceful, or a kids’ group that needs more protection. Finally, the choices we make should be an informed balance of cost versus consequence in the frame of the context.

We need to understand these same elements in planning our risk management approach, too. Is this project domain our core competency? What are the costs and consequences of project risks occurring? What is our company’s risk tolerance and preferred risk management approach? Make sure people understand the environment.

Another tool to relate the need to tailor the process appropriately is to ask the team to consider the decision rigor they put into their purchases. The way we consider buying a coffee ($2), a couch ($2,000), a car ($20,000) or a condo ($200,000) varies as the figures involved escalate. For a coffee, we probably just find something close, maybe at our favorite store. For a couch, people will shop around and likely buy the one they like the best without much further research. When it gets up to car territory, safety, economy and resale factors are routinely examined. For a condo purchase, the stakes are so high that most people engage professional help from home inspectors and condo document review companies. We need to do the same for our projects, asking what is appropriate for the endeavor.

Finally, if the team is new to risk management then a discussion on the tradeoff between business value and risks might be necessary. We undertake projects usually for the potential upside (or for compliance projects to avoid the downside)--we are hoping for business benefits. Agile projects use business value as an input into work prioritization; we do the high-value items first. We want to deliver business value, and getting business value out of a project is like receiving deposits into our bank account--we want them as often as possible, and preferably as large as possible. Given the uncertainty in the world, we want the biggest gains as soon as possible before anything changes that may threaten future deposits.

In this bank analogy, risks are like withdrawals or bank fees--should they occur, they set the project back, take away resources from delivering business value and threaten the delivery of future value. So to get the most out of a project we need to maximize business value while avoiding or reducing risks. These exercises and discussions aim to get the team thinking about the appropriate level of risk management for the project and gain consensus and support for the strategy that is agreed upon. Without this shared understanding of “Why?” we will not get people invested in the process.

2. Find Friends and Foes (Risk and Opportunity Identification)
The next step in the process is to identify potential risks and opportunities. Opportunities are the “good” risks or fortuitous events that have a positive impact should they occur. We want to avoid risks and exploit opportunities. The IEEE have some good risk profile models for software projects. They were created by collecting risk information from thousands of completed software projects, then categorizing and ranking the common ones. These models can be used in a group setting or, as I prefer, used as the inspiration for a collaborative game. The “Doomsday Clock” exercise is based on a risk profile tool I have written about previously.

Using a clock view pre-drawn on a white board or flip chart, we ask team members to think of project risks associated with each of the topics represented by an hour line on the clock--12 in total. (For a detailed description of the types of risks within each category we would be asking the team to identify, see the spreadsheet attached to the risk profile article.)

This is the doomsday part: Wwe encourage the team members to think of and record as many risks as they can about that topic. We work topic by topic, but if thinking of risks triggers ideas in other areas as we progress, it is not unusual to get risks being added to previously discussed risk lines. Again, I prefer having people working individually for coming up with ideas. Then we put them all on the wall and consolidate and remove duplicates as a group, which also sometimes identifies new risks.

This process takes a while; spending just five minutes on each topic requires an hour to go through them. Discourage people’s tendencies to want to score, rank and solve the risks. This is risk identification--we will have plenty of time to process them later.

Doomsday Clock

Continue reading "Collaborative Games for Risk Management" »


Agile Risk Management – Harnessing the Team

Team ideasLast month we looked at how agile methods provide multiple opportunities for embracing proactive risk management. The prioritized backlog, short iterations, frequent inspections and adaptation of process map well to tackling risks early and checking on the effectiveness of our risk management approach.

We want to overcome many of the correct-but-not-sufficient aspects of risk management seen too often on projects:

    Poor engagement - dry, boring, academic, done by PM, does not drive enough change
    Done once – typically near the start, when we know least about the project
    Not revisited enough – often “parked” off to one side and not reviewed again
    Not integrated into project lifecycle – poor tools for task integration
    Not engaging, poor visibility – few stakeholders regularly review the project risks

This month’s article extends risk management beyond the project manager role and introduces the benefits of making it more of a collaborative team exercise. Next week we will walk through the team risk games one by one.

First of all, why collaborative team games? Just as techniques like Planning Poker and Iteration Planning effectively make estimation and scheduling a team activity and gain the technical insights of engaging people closer to the work. So too do collaborative games for risk management; after all, why leave risk management to the person who is furthest from the technical work – the project manager?

"...why leave risk management to the person who is furthest from the technical work – the project manager?"

Before I upset project managers worried about erosion of responsibilities we need to be clear on what the scope is here. I am advocating the closer and more effective engagement of the team members who have insights into technical and team related risks. I am not suggesting we throw the risk register to the team and tell them to get on with it. Instead we are looking for better quality risk identification and additional insights into risk avoidance and mitigation, not the wholesale displacement of the risk management function.

So why should we bother to engage the team? Why not let them get on with doing what they are supposed to be doing, namely building the solution? Well there are some reoccurring problems with how risk management is attempted on projects. Most software projects resemble problem solving exercises more than plan execution exercises. It is very difficult to separate out the experimentation and risk mitigation form the pure execution. Team members are actively engaged in risk management every day. We can benefit from their input in the risk management process and if they are more aware of the project risks (by being engaged in determining them) how they approach their work can be more risk aware and successful.

The benefits of collaboration are widely acknowledged, a study by Steven Yaffee from the University of Michigan cites the following benefits:

Continue reading "Agile Risk Management – Harnessing the Team" »