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.
|Starting out as project managers, we begin to recognize the signals that point to project risks. Initially, these signals come in the form of status reports, work plans and delivery metrics. As we gain experience, we learn to sense additional risk signals that come from observation and dialog. And those signals originate from project managers themselves. |
These signals sometimes go unheeded because the ability to act on them can typically be constrained. For example, there is fear of making project customers unhappy if you raise objections, unrealistic expectations and a false belief that these types of messages will somehow motivate the project team.
In my experience, here are some of the signals that have pointed to a project headed down the wrong path:
1. "We'll start the project at the kickoff meeting."
Many times, important project mobilization activities tend to be ignored in the haste to begin a project with a large group meeting. This fixation on the kickoff meeting causes key mobilization tasks to fall behind. Early action on staffing plans, on-boarding processes and communication mechanisms before the kickoff meeting are more important than making sure the chocolate chip cookies arrive in time.
2. "This project WILL finish on time and budget."
This signal typically appears at the first sign of progress or cost slippage. As opposed to dealing with the root cause of the slippage, many times project managers will shrink scope to meet time and budget. Reducing scope has the effect of reducing the overall value proposition for the project. Address this tendency by allocating sufficient time early in the project to identify business success criteria independent of schedule and costs.
3. "The CEO is the sponsor for this project or program."
Name-dropping typically emerges when there is a conflict over resources needed by multiple projects. Project managers hope that by presenting the CEO or other executive as a sponsor, it will create commitment to the project. However, CEO's and other executives usually do not have the luxury of time to serve as a sponsor on a project. Leverage stakeholder management activities such as a level of funding approval list to confirm the primary sponsors for the project.
4. "We are four weeks behind schedule, but we'll make it up in the next phase."
Unless there is a large change of scope, one of the more the unfortunate laws of physics for projects is that any schedule slippage is likely to carry over to the next phase. The best approach is to be transparent about the schedule delay. By making the slippage transparent, you enable leadership team attention and corrective actions.
5. "I feel green."
A green status indicator in a project report typically means that no issues are present. However, a green status indicator does not always tell the complete story.
For example, despite deliverable dates that were slipping on one project, the project manager continued to declare a green status indicator. In an executive steering committee meeting, the leadership team challenged the project report. The project manager said, "I know the deliverable dates are slipping but I'm still feeling green." To promote project team and leadership confidence, employ objective project metrics such as planned vs. actual deliverable dates or earned value analysis to show the true status of the project.
While tools, approaches and processes help manage delivery risk, recognize these signals and take the right steps to act on them.
What have you found to be good examples of signals that point to risks on projects?