Who’s Bertha and how hindsight is 50/50

After taking our Project Management class, I have been fascinated about how organizations manage risks, and how project managers put together a risk management plan.  There is one project that is on-going in the city of Seattle. The project is replacing a double decker highway or better known as the Alaskan Way Viaduct. The viaduct, as it’s commonly known, is a road system that sits on top of each other and runs a long Elliott Bay about the roadway, Alaskan Way. The risk of having this roadway is similar to the Loma Prieta earthquake of 1989 in Northern California, where multiple roadway infrastructures were destroyed. The San Francisco Bay Area had a similar viaduct, called the Cypress Viaduct, and it ran along the Bay Shore in Oakland.  This viaduct tragically tumbled down during the earthquake killing 42 people.  I was 5 years old at the time, and I vividly remember when the earthquake occurred, as multiple buildings and infrastructure were destroyed (the Bay Bridge even lost part of his bridge). The earthquake was famous because it occurred during the World Series, when the Giants and A’s played each other, known as the Battle of the Bay. Seattle is in a similar position, as geologists have been theorizing that the area is long overdue for a massive earthquake.

Washington state and the city of Seattle have addressed this risk, and knew that the viaduct needed to be retrofitted or replaced with a tunnel.  Residents were asked to vote on a measure on either saving the viaduct or boring a tunnel to replace the infrastructure.  I voted on the measure, as I remember the tragedy in the Bay Area, and I asked for the city to build a tunnel.  The measure passed in favor of the tunnel, and the project started in late 2012. However, the project has been delayed due to the boring process, where the machine called Bertha suddenly stopped mid-way through the project. It has been 2 years since this delay, and I can’t help but think that they did not accurately account for Bertha stopping. Let’s quickly recap the risk management steps, and what steps might have been missed with the Alaskan Way Viaduct project.

Risk Management steps:

  1. Risk identification – the process of listing out the possible scenarios of a risk occurring, including brainstorming, problem identification, and risk profiling. A common mistake is focusing on the objective (completing the tunnel), and not the events that could produce the consequences (Bertha stopping). In addition to identifying the risk, the organization needs to understand their Risk Breakdown Structure, split into four parts; technical, organizational, external, and project management. Bertha fits squarely into the technical breakdown, specifically under performances and reliability.
  2. Risk Assessment – this is broken down into 2 categories; probability and impact. Organizations generally utilize a semi-quantitative scale, and the likelihood on a numerical scale, 1-5, where 5 is very likely of occurring. For the Alaskan Way Viaduct, I assume that Bertha had a likelihood of breaking down, but the probability of breaking down was unforeseen, and the project management team might have given Bertha a score 1-3, while a 4-5 might have prevented the long delay.
  3. Risk Response Development – this has four components, and includes: mitigating risk, avoiding risk, transferring risk, and retaining risk. Mitigating risk would include how to avoid Bertha breaking down or how to reduce the impact of failure. However, Bertha broke down due to being overheated, and experienced mechanical failures. Mitigating risk also includes reducing the impact. In this case, the project management team did not anticipate a mechanical failure, and thus not being able to mitigate their risk. Lastly, retaining risk includes that the project management team makes a conscious decision to accept the risk. This seems unlikely as Bertha’s failure has cost the project more than 1.1 billion dollars.
  4. Risk Response Control – this includes risk control and establishing a change management system. Risk control includes execution of the risk response strategy, monitoring triggering events, initiating contingency plans, and watching for new risks. For change management, this includes monitoring, tracking and reporting risk, foresting an open organization environment, repeating risk identification exercise, and assigning responsibility for managing risk. For the Viaduct project, the contingency plan was to fix Bertha, which took 1 year to fix.

As we can see, the Alaskan Way Viaduct has experienced a major setback, and might have been prevented with a better risk management plan. Do you think this project was too big of an endeavor to complete? What else should have the construction firm have done to prevent Bertha on breaking down? I believe that Bertha should have been tested before starting the project, which could have mitigated the risk of failure.  Hindsight is always 50/50.




Cypress Viaduct:

Cypress Viaduct

Image of Bertha:




Risk Management Plan for Software Development Life Cycle

When I was a recruiter for an IT staffing firm, I would always wonder why IT firms would reach out to our office with a hiring manager in need of a contract software developer for one of their projects. These hiring managers were either Project Managers, Program Managers, or Release Managers, that had a group of software engineers that rolled out new software for their company. Our staffing agency sought out for these types of projects, and would find contract workers for these hiring managers on their SDLC projects. There is always a need for contract workers, especially for technology companies that run multiple projects. When reviewing project management topics, risk management seems to be a likely area where project manager’s account for staffing needs.

My curiosity lead to me to an article on how project managers account for risks in their SDLC projects. The article addresses risk management as a general approach for all project’s, and below are steps for project managers to follow:
1. Risk identification
2. Negative impacts
3. Prioritizing risks
4. Risk management or risk treatment
5. Auditing the risk management plan

The article states that firms can either have a full-time Risk Officer, or the responsibility be delegated to the project manager. It seems in my experience, the latter is true, where the project manager takes the lead on the risk management plan. Hence, why the contingency plan of needing additional human capital to fulfill the project included a staffing agency. However, the article addresses the importance of having a risk management plan based on the phases of the SDLC. Let’s briefly discuss what these phrases look like, and how a risk management plan is incorporated into each step.

There are five stages in a software development life cycle, and the stages include; inception, design, implementation, maintenance, and audit or disposal. For each of these steps, the article suggests what should be done to develop the risk management plan. In the inception phase, the engineers talk through some the risks associated with the software. The second step is the design phase, where the engineers take the risk into account, and how their software will support or manage the risks associated. Generally, these include a set of checklists that the engineers address when designing their software. The next stage is implementation, and in this stage, there are tests conducted to test where the software can pass the associated risks. The third stage, the article stresses the importance of ensuring the risks are passed, before going live. The fourth stage includes maintenance of the software, and problems generally occur in this stage. These problems are where the engineers debug the issues, and maintain the system to run as designed. The risk management plan takes into account that there will be problems with the system, and understands that if the system needs to be changed or altered, the risk plan accounts for alterations of the system. The final stage is auditing the system or disposing it, where the risk management plan refines the system.

When reviewing how the risk management plan fits into a software lifecycle, I understand why Project Managers can utilize contingency workers for their projects. When reviewing stages 3 and 4, these areas are likely where the project manager accounts in their risk management plan to have contractors mitigate the risk.These stages account for issues arising, and based on my experience as a recruiter, the hiring manager knew who to reach out to fulfill their staffing needs.

Has anyone worked with a staffing firm to mitigate risks in their projects?


Product manager vs. project manager: who is what, and why is each important

During our first 2 weeks of class, I have been assessing how my company handles project management, and where to find our PMO group. Regrettably, our company does not have a dedicated group that handles all our company’s projects. This led myself to re-assess how our company operates under its current organization, which based on our customer needs, Hotwire serves to be a fun, spontaneous travel site that attracts advantageous travel geeks. Our goal is to develop a great travel experience, and this hinges on product development. Product development has similarities with project management, developing a scope, executing on the deliverables, quality control, and completion. So I searched what was the main difference between these organizational groups, and found an article that describes how a product manager sees the difference (listed at the end of this post).

The article discuss the differences between product and project management. Product management is “focused on the end-to-end life cycle of an identified value-proposition”, and I see this group supporting an on-going goal. Ultimately, product managers serve the purpose of delivering products to its customers. The article breaks down project management simply as having a “narrower scope, delivering an outcome defined by someone else”, and which gives the impression that project managers have a purpose based on around strategic decision makers.  The article gave me the impression that product managers are miss understood, and should have a clearer view of their role in the organization.

So, I as reflect on the author’s view of product management and project management, I see the similarities with my own firm, but in the reverse. Project managers have an unclear role in our organization because of how our company organizes it’s priorities around product development. As a Hotel Account Manager, I work closely with our product teams, who oversee different functionalities on our site. These functionalities include product placement, special tagging, promotion features, and specialized amenities (like free parking or complimentary breakfast). In addition to these different product types, our product teams are organized into different categories like mobile, supplier tools, content, pricing and email marketing.

When it comes to our company’s project managers, they are involved in new product releases, technology conversions, and having ownership over key initiatives. Some of these initiatives are related to our companies score card that track different strategy goals, and our project managers are either key senior managers or proven contributors assigned to a special project. To give further insight, our team assigned one of Regional Managers a project to oversee a conversion of a sister travel site. Our Regional Manager led the project for 3 months, and after completing the project, continued to manage his region. Ultimately, I believe our company is set up for success, but I wonder how we could be a better organization with a dedicated PMO team.

Does anyone see a similar project management set up with their organization?