By Kevin Korterud
I’m amazed at how often I receive requests for help creating an effective risk management process. These inquiries usually come from organizations with a risk management process that hardly anyone uses. Stakeholders, program managers, department heads and executives are mystified about why nobody is declaring risks on their projects, which can create the false perception that everything is going fine.
Why does this happen? One reason is that project managers believe making risks visible to leadership could impair their efforts. Another reason is an organizational culture that creates a negative perception of risks. For example, I have seen some highly entrepreneurial companies foster a mindset of rugged heroism, which causes project managers to think they have to fix everything themselves. In this project environment, project managers worry that escalation to leadership will be seen as a sign of weakness.
In fact, there’s no use pretending any project is risk-free. Risk management is an essential part of any project: Whether you’re climbing a mountain or changing a light bulb, there are always risks. For anyone who’s ever been leery about flagging risks, or is just looking for some new approaches, here are five tips.
1. Think of risk management as a way to get what you need, when you need it.
Project managers rarely have the financial or command authority to change schedules or release additional funding—that’s leadership’s job. For this basic reason, declaring and escalating risks enables leaders to provide risk mitigation assistance.
Making risks visible to your leadership gives them enough lead time to provide relief when it is needed, not weeks or months later when unmitigated risks turn into project problems.
2. Don’t forget: People can be risks, too.
I have seen many risk management plans focus entirely on things: systems that might not be ready, processes affected by outside regulatory bodies, estimates that were done in a hurry at year-end budget cycles, etc.
What project managers often fail to consider in their risk planning is that people can also be risks.
For example, let’s say your project sponsor is replaced by someone who has no experience in the subject areas of your project. This lack of experience initially will cause longer decision-making cycles as the new sponsor comes up to speed in the subject areas.
So be sure to include people risks in your risk register—they can affect your progress as much as more inanimate factors.
3. Create guiding principles for risk management.
While there may be a process in place for managing risks once they appear, quite often it is unclear to project managers when and how to escalate risks to higher levels in an organization based on their potential impact.
To create clarity and promote transparency around risk management, the best approach is to set guiding principles that govern the process. The rules should be simple and broadly communicated throughout an organization.
Examples of guiding principles include:
· Declaring project risks demonstrates professional discipline that will be recognized by leadership.
· A potential mitigation approach should be prepared for every identified risk.
· Risks with greater potential impact need to be made visible at higher levels in the organization.
4. Use the 30/20/10 rule of thumb.
In my experience, the most frequent question asked by project managers is how many risks should be identified on a project. For example, a person might feel that a small project should have a small number of risks. But that’s not necessarily true, especially if a small project impacts a large population of people.
One risk management approach I recommend to project managers is the 30/20/10 rule, which starts with a broad slate of risks and narrows them down throughout the life of the project.
Here’s how it works: Identify risks at the beginning of the project that, if realized, would affect 30 percent of the schedule, budget or results. Midway through the project, the goal is to lower the potential impact of risks to 20 percent of the schedule, budget or results. By the end of the project, the project should carry risks containing no more than a 10 percent impact.
5. Don’t forget the bigger picture.
Project managers frequently tell me they would have finished a project on schedule, but team members were pulled into another project. Translation: another project was more important. And the strategic relevance of your project matters just as much as how you manage that project on a day-to-day basis.
To manage the risk of irrelevance, conduct an assessment on a recurring basis of how your project fits into your organization’s strategy and portfolio. Validate the relative priority of the project against other active and pending projects, and check on potential scheduling dependencies that may impact your plans, as well as any resource conflicts that may be triggered by other projects.
What techniques do you use to identify and mitigate risks on a project? If you’ve worked at an organization where flagging risks attracted negative attention from higher-ups, how did you deal with this challenge?
The yellow rubber duck that floats in baths of families the world over started appearing in harbors around the globe in 2007 — but not in their usual small size, but as giant floating structures. To the delight of many, waterways worldwide were being turned into a huge baths. Bath time reached Taiwan officially in 2013 at Kaohsiung City’s Glory Pier.
This traveling sculpture display Rubber Duck was an international art show by Dutch artist Florentijn Hofman. It has been built and displayed worldwide with the aid of two volumes of installation guides and specifications. The books offered details ranging from the materials of the sculpture's construction to the patterns those materials needed to be cut into and how they should be sewn together. They also included calculations of the sculpture's buoyancy and weight to help with moving and securing it.
In addition, these books recorded the best practice of each construction of the Rubber Duck. In each new city the sculpture appeared, lessons learned were recorded. This meant that each new appearance of the sculpture would feature an accumulation of experience and insight in how best to manufacture and exhibit it.
Regardless of where it appeared, the Rubber Duck technically should have looked the same. But in reality, some cities’ ducks just looked prettier; while others’ had crooked mouths, tilted bodies or looked lethargic overall. Even if you have extensive lessons learned in hand, as well as basic guides to materials and construction, success comes down to the local project managers’ precision and quality control.
In the case of Taiwan’s Rubber Duck, erecting and placing the sculpture would be a challenge due to its size: At 18 meters (59 feet) high and 1 metric ton (2,205 pounds), it was the biggest in Asia at the time. Even more challenging were the threats of typhoons and earthquakes. Ayu Cheng, the project manager of the Taiwanese team, said they had to work on several issues, including:
The Ching Fu Shipbuilding Co. Ltd. and Airglow Co. Ltd. worked together to overcome these challenges. All the production teams, the project manager and the Kaohsiung Municipal created two precedents:
Have you worked on a program where you had to use lessons learned, requirements management and risk management together?
Manage Risk Like a Formula One Driver
Categories: Risk Management
I attended my first Grand Prix in 2000 at the Indianapolis Motor Speedway, and quickly became a Formula One (F1) enthusiast. I have attended several Grand Prix races in Asia, North America and South America; visited iconic F1 destinations such as Autodromo Nazionale di Monza and the Ferrari factory in Italy; and even met a few World Drivers' Champions.
Over the years, I have noticed that F1 and project management are very similar. Every race of the season is a milestone. Engineers, designers and mechanics work for the driver, who is always looking to minimize risk and maximize opportunities -- just like the project team and a project manager.
Mr. Lauda, with 25 wins, one of the greatest F1 drivers, is well-known by racing fans for two things: his rivalry with James Hunt and his accident on 1 August 1976, during the German Grand Prix NÃ¼rburgring.
During the 1970s, NÃ¼rburgring was the season's most dangerous circuit. It was known as "the Graveyard" and had claimed the lives of five drivers. In the 1976 race, the weather conditions were far from ideal. Mr. Lauda called a meeting with the rest of the drivers to vote to cancel the race. The drivers understood that the NÃ¼rburgring ring required perfect weather conditions to be even remotely acceptable in terms of risk. Due to Mr. Lauda's position in the F1 standings, canceling the race would've benefited him, but he was more concerned about the danger.
The race went on despite the rain. During the race, Mr. Lauda's car went off the track and his fuel tank punctured, setting his car on fire. He was trapped for almost a minute in a searing inferno before other drivers could rescue him. Mr. Lauda suffered burns to his face and smoke inhalation.
As with race car drivers, project managers face risk with different levels of severity. A project manager's risk tolerance level depends on different factors: organizational culture, national culture and experience. It's not only imperative that we provide early identification and assessment of risks -- the point is to know and stick to a risk threshold. We may face hardship for accepting the risk and not being successful, but we need to learn the lesson and move on. As Mr. Lauda said: "I accept every time I get in my car that there is a 20 percent chance I could die, and I can live with [that risk] -- but not 1 percent more."
Another lesson in risk management from Mr. Lauda comes not long after his crash. Like a phoenix, 42 days after his near-fatal accident, he went back to the track and kept fighting Mr. Hunt for the championship. The Japan Grand Prix, the last race of the season, would crown the next World Drivers' Champion. Again, weather conditions were poor, delaying the race for several hours. While it was still raining, Mr. Lauda started the race but quit after a few laps. His team was surprised to see him coming back to the pit stop and asked him what was wrong with the car. Whie the car was in perfect condition, Mr. Lauda assessed the risk as too high. And when the team tried to present a technical justification for his quitting, Mr. Lauda told them to tell the truth: that he made the decision based on the weather. He had reached his risk threshold and decided to leave his championship hopes to other drivers -- including Mr. Hunt, who garnered enough points to beat Mr. Lauda and take the top prize.
We project managers are paid to decide the future of projects, programs and portfolios. Sometimes, those decisions are difficult to accept -- by sponsors and stakeholders, not to mention ourselves -- but will provide long-term benefits to our organization. And canceling or postponing a project, program or portfolio will not prevent our professional career from progressing -- on the contrary, it can reinforce our knowledge and experience. After the Japan Grand Prix, Mr. Lauda continued his successful racing career and became champion in 1977 and 1984.
I have my own experience of approaching risk management by determining the environment and sticking to thresholds. When working on a regional project in Central and South America in 2010, the project faced a geopolitical risk that slowed down progress. But in many countries in the region, 2010 was a presidential election year. This event usually contracted economic activities months before the election and sometimes even after. As elections impacted different countries at different levels, we had to define and implement contingency plans for some; for others, we accepted the risk, and yet for others, we didn't accepted the risk and suspended the project temporarily.
How do you face risk? Are you a risk taker or a risk-averse project manager? And how do you define acceptable risk?
In the early days of my career as system analyst, I had my first assignment working directly for a project manager.
My project manager -- let's call her Rita -- was assigned to turn around a failing software package project. Over the next several months, under Rita's direction, the project was implemented with great success.
When we parted ways at the completion of the project, I asked Rita for her keys to project management success. While tools and processes have changed over the years, what she said has served me well managing all types of projects.
Following her advice has led to successful delivery outcomes and helped me mitigate risks along the way:
1. Schedule project meetings on Mondays
Rita maintained that Mondays are better than Fridays to catch up on project progress. Her rationale was that you could better forecast and make the work for the current week visible. It also had the extra benefit of re-charging our minds for project work after a weekend.
2. Enable progress
Instead of providing input on how the system would function, Rita spent time orchestrating the actual work of the project to enable progress. For example, during the project's design phase, she provided useful requirements and design templates that allowed us to better organize and align our efforts.
In addition, rather than assigning risks and issues to others on the team, Rita took personal ownership of solving them. This allowed team members more capacity for work while Rita worked in parallel to mitigate issues.
3. Functional design is everything
Rita always stressed that it was essential a project have sufficient time to complete a full functional design process with no shortcuts. She mandated that a full functional design process would also include the tracking of the design back to the requirements. On the project I worked on with Rita, this additional focus ensured that the software package was configured properly to meet all requirements.
Rita also directed us to exhaustively pursue the design of interfaces. One of her constant comments was, "The value of what we implement is tied to the success of how it interfaces with everything else."
4. Use prototypes where possible
Rita often said, "It's easier to see a system than to talk about it." Presenting system functionality by drawing pictures on a marker board is not an effective method of conveying how a system will work. Rita acquired access to a prototype software installation. This prototype not only allowed the project team to readily show what the software would do, it also enabled quicker design of the software configuration.
5. Manage delivery first, then costs
Presenting a complex analysis of project budget during steering committee meetings is okay sometimes, but you must be able to answer fundamental questions around project progress.
During her steering committee meetings, Rita would present escalated risk, issues and mitigation strategies for review and approval. This shifted discussion to delivery-related topics, which accelerated the progress of the project. "If you deliver successfully, the costs take care of themselves," she said.
What are some project management principles you learned from your first project manager?
|The agile process helps reduce such risks as poor product quality or building the wrong product entirely. Though agile and Scrum were originally designed for software projects, their iterative process and techniques apply beyond their initial intended industry.|
Here are five ways agile and Scrum techniques can curtail project quality risks:
1. All practitioners must review project requirements with the client.
In agile, the "user story" is the basic building block for agile requirement lists. A formal "acceptance test" is an integral part of that user story, as is explicitly reviewing it with the client to verify you have customer concurrence on the deliverable.
2. Agile teams collaborate while creating project components.
Inspections or pairing can prevent up to 50 percent of possible defects, according to research I conducted with colleagues. In addition, collaborating helps team members share other knowledge about the product or tools used to meet project needs at a critical stage.
3. Authors create a consistent set of verification measures.
Ideally, this takes the form of automated verification tests designed to catch missing functions or incorrect product behavior. These tests are run by the original author, as a sort of control against variables, and also used for regression testing by other team members. Yet even if a project passes these tests, it's also crucial that the product components are streamlined from the get-go so they can be easily maintained or extended in the future. This is called "refactoring."
4. Quality teams test small project deliverables as they are written.
Since the deliverables have been inspected or pre-tested, at this point you should expect few errors.
5. Feedback from a demonstration.
Agile teams hold demonstrations for their stakeholders, showing items completed since the last demonstration. The key is to elicit feedback from stakeholders and use it to improve the product. This provides one final chance to confirm that what the team produced was what the customer wanted. In this way, ideas and changes can be addressed before the completion of the project.
In addition to the following checklist for agile and Scrum risk reduction, it never hurts for teams to employ risk lists to further improve project performance:
How else do you think agile helps mitigate risk? What steps do your teams take to mitigate risk?
Read the Organizational Agility report for an in-depth look at how agile organizations increase their success rate on new projects, even in a volatile global economy.