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.

http://www.reuters.com/article/2015/07/17/us-usa-seattle-tunnel-idUSKCN0PR2GW20150717#PMM4oPLPYAlM4yiB.97

http://www.dailymail.co.uk/news/article-2987391/Construction-workers-prepare-lift-world-s-biggest-tunnel-boring-machine-streets-Seattle-repaired.html

 

Cypress Viaduct:

Cypress Viaduct

Image of Bertha:

 

 

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?

http://www.brighthubpm.com/risk-management/72055-best-practices-in-it-risk-management/

From Complexity to Ingenuity

I have learned from the project management course that risk management is the essence of project management, by understanding, analyzing, mitigating, and monitoring project risk the company would reduce the number of surprises and that will leads to project success and increase stakeholder satisfaction. According to PMI’s report Pulse of the Profession in 2013 “Every $1 billion spent on a project, will have $135 million at risk, the trend becomes more troubling for projects with added complexity, which, on average, have budgets nearly twice as large.”

Project manager must identify complexity in a project from the beginning to help control the risk through the life of the project, to make sure his or her team is focused and the project is better governed and managed. Also, he or she would decide if the project is worth the risk and what should be done to manage the risk through the life of the project. According to PMI’s report in February 2014 “From Complexity to Dexterity” the report added seven tips to taming complexity in a project as follows;risk_measurement_400_clr_5483

1. Project and program management culture comes from above.
Having engaged project sponsors is one of the main drivers for project success.

2. Set a clear vision for project outcomes.
Setting specific goals for what the project needs to define how decisions are made, and prevent scope creep from pulling the project of track.

3. Break highly complex projects into manageable pieces.
Determining the elements of complexity early when problems are cheaper to solve.

4. Establish centralized functions for oversight.
Setting guidelines and providing tools between project teams and leadership to ensure they remain aligned.

5. Create a formal governance process and follow it.
Diligently oversight projects by people empowered to make decisions to mitigate issues before they become a major problem.

6. Invest in people.
Developing the expertise of project leaders ensures the organization has a broad pool of leaders ready to manage highly complex projects.

7. Communicate effectively with all stakeholders.
Seeking out different perspectives and ensuring project objectives are widely understood.

The report indicated that the pharmaceutical business is a prime example for complexity when dealing with uncertainty about the future of creating new drug to market. “We are trying to predict what’s going to happen 10 years from now with respect to multi million euro rug development projects.Research wants to develop a new drug, commercial wants something to sell, and customers and stakeholders want a product proven safe and effective.” says Ken Jones, President and CEO of Astellas Pharma Europe Ltd. As organizations have little choice to deal with indexcomplexity, but such project management strictness helps Mr. Jones’ team better control the risks and determine which projects should be fast-tracked, slowed down or killed.

Which one of the tips do you find most important to taming complexity in a project and can you think of any additional tips to add to this list?

URL: http://www.pmi.org/~/media/PDF/Business-Solutions/Complexity_Dexterity_whitepaper_v2.ashx

 

A Risk Management Lesson from “Silicon Valley”

The video clip linked below is from HBO’s “Silicon Valley”. This television program follows a group of software engineers as they launch an innovative app and their associated start-up company (both named Pied Piper). This clip focuses on Pied Piper’s primary competition, a tech conglomerate named “Hooli”. The clip shows a speech by Hooli’s CEO, followed by several discussions between members of a project team.

HBO’s Silicon Valley on Risk Management

This scenario highlights several instances of risk management failure which are tragically relevant to the workplace. Some of the failures I observed are lack of communication within the project team, lack of escalation within the project team and larger organization, and absence of risk planning and mitigation planning early in the project. In today’s hyper-competitive, fast-paced marketplace proper risk management is critical to project success. Has anyone observed this type of situation at their workplace?

Recently I encountered a scenario where the customer made a significant design change late in the project. The product was nearly qualified, but was deemed unacceptable due to reliability and performance requirements. The team was faced with a tough decision: kill the project or redesign.

As the contract manufacturer in this arrangement, I raised concerns regarding the potential risks this design change could have on the project. Any delay or high defect rate would result in lost revenue and profit to my organization as well as the customer. I was reassured there would be no issues and no change to the product ramp/launch dates and product cost.

As we built increasing numbers of the product the failures began to pile up. Both customer and manufacturer turned to firefighting mode and additional resources were dedicated to expedite resolution. In my customer’s organization I could see finger-pointing among several teams as each department tried to cover themselves and avoid being the next bearer of bad news to upper management.

Eventually the product was fixed and had a successful (yet slightly delayed) launch after several weeks of many stressful meetings. Could this situation have been prevented? I believe so, but only if the correct tools, controls, and planning were put in place at the beginning of the project at both the customer and manufacturer. The following article details such risk management best-practices:

Risk management and project management go hand in hand

Some noteworthy items include ingraining a risk management culture/mindset in the project team, frequently analyzing the project status and forecasting new risks, developing and agreeing to risk response plans in advance, and assigning an owner to each risk who can drive corrective actions and track progress. Although you cannot predict every possible risk in a project, I’ve seen how important it is to conduct this planning at the beginning of the project to avoid firefighting late in the project.

Does your company have a formalized process for risk management? Are these successful, or would you suggest alternate approaches? Do you have any horror stories similar to mine? Please share your experiences!

 

Risk, Risk, Risk, Can you avoid it? Can you plan it?

I came across an article that talks about managing risk on our projects.  Brad Egeland, who is the author of the article implies that the risk can be mitigated by dedicating a chunk of the project money to the risk.  He also points out that, there are times where we create a risk management plan but don’t follow through with it due to time or budget constraints.  I totally agree with Egeland that well documented risk management process is always going to be a great strategy to follow.  What happens when you don’t have enough money to asses or plan for risk?  Do projects without any budget assigned to risk fail?

In class we have learned that, to manage risk we must proactively attempt to recognize and manage internal events and external threats that could potentially affect the project.  One of the most asked questions on the project is “What could go wrong?”.  Many times we are uncertain of the consequences of our actions until they are completed.  There are times where we can sit down and really ponder about the situation that could potentially put the project at risk.  Usually ideas that put a project at risk are put on the side and quickly forgotten.  Risk management teaches us to be more proactive than reactive.  I think everyone can agree that being proactive could potentially eliminate most of the risks from the project unless we experience unforeseen risks.  At that moment we better have some kind of a contingency plan that will reduce the negative impact of a risk event.  Contingency plan will usually require some kind of a budget.  Depending on the project, the risk assessments could identify additional budget requirements or reserves as some might call them.

Many times I jump into a project without thoroughly assessing the situation for risk.  Risk is not something that we think about everyday.  Most of us usually react to the situation and are not proactively estimating the potential risk.  Once the problem arises, I personally document what went wrong.  I start from the beginning and trace all my steps to find out how,why and where did this go south.  Once I have determined the root cause of the problem I am more inclined not to make the same mistake twice.  The reason many of us jump into the project without looking at the risks is because risk planning takes long time and sometimes is unavoidable.  Some might argue that risk planning should depend on the size of the project.  I would strongly recommend that even a small project should have some kind of a risk assessment.  At the end of the day don’t we all want to be perfect?

If you would like to read more about managing risk on our projects please feel free to read Brads article.  The article could be found at http://blog.aecsoftware.com/2015/04/are-we-really-managing-risk-on-our-projects/

10 Golden Rules of Project Risk Management

If you are planning to ever lead a project this article is an absolute MUST read! It provides the 10 golden rules for the application of risk management in every project. Based on the author’s personal experiences of over 15 years, the article discusses how to deliver on time, on budget, meeting sponsors’ quality demands.

Rule 1: Make risk management part of your project

Risk management tools should not only be part of daily operations, but also included during meetings or staff training.

My 2 cents…It would be almost ignorant to not include risk management in a project. You would simply be setting the project up for failure.

Rule 2: Identify risks early in your project

The author points out two main sources to identify risk: people (offering personal experiences and expertise) and paper (project plan, business cases).

My 2 cents…Identifying the risks either through human capital or documents is the first step. Dealing with them timely and properly is the real challenge during a project with multiple phases.

Rule 3: Communicate about risks

Communication should be a component in every task carried out during the project. By having a dialogue as these arise, the team will have a chance to discuss and handle.

My 2 cents…Communication! Communication! Communication! It is absolutely critical to communicate risks with all stakeholders as they arise to help prevent disasters later on during the project. If you are not sure of the whole impact of a risk, bring it up during a meeting. There is nothing worse than foreseeing an issue, not addressing it to later be faced with irreversible consequences.

Rule 4: Consider both threats and opportunities

Many project teams group opportunities under the risk category when in fact these might be ways to help improve the project. Overloaded with work and pressured to meet deadlines, projects with decent pay-offs are bypassed.

My 2 cents…Once on a project, the marketing director asked me to write my own SWOT analysis (Strengths, Weaknesses, Opportunities and Threats for those without a marketing background). I thought she was crazy and undermining my skills since I was fresh out of college. The project ended up being one of the best ones I was a part of because my knowledge and experience were used in the correct phases or milestone tasks.

Rule 5: Clarify Ownership Issues

Someone needs to be held responsible for certain tasks and be prepared to deal with them and take ownership. Simply writing down a list of the potential issues isn’t enough especially when money is at stake and someone will have to empty their wallet?

My 2 cents…Clarifying ownership is critical for the success of a project. If team members are not held responsible for individual tasks or risks, the project will be doomed for failure as fingers will be pointed left and right.

To read the remaining five rules, please refer to the article https://www.projectsmart.co.uk/10-golden-rules-of-project-risk-management.php

Which one of the rules do you find most important for the success of the project and can you think of any in addition to his list?

Thank you for reading my blog!

Reference:

https://www.projectsmart.co.uk/10-golden-rules-of-project-risk-management.php

 

 

Project Management: The Good, The Bad and The Ugly

Do you sometimes see your project manager as just the “jerk in charge?”

The course material has resonated with me in that I am able to identify the need for project management in certain areas of my workplace where this is lacking; such as developing systems for interdepartmental communication and talent acquisition and retention. But, can this be done in the project/program setting with definitive time lines, goals, budget, planning and execution? I think so!

To examine this further, let’s review two examples of projects that I’ve taken part of during my career in the Association Management Field which starkly contrast with each other. One, the successful implementation of a global acquisition strategy for a stand alone association. The other, an abysmally failed attempted to reorganize the digital file structure of an Association Management Firm representing 40 clients and employing almost 250 people.

The latter project, in my opinion, was the attempt of an executive assistant to prove her worth to the company. Beginning with the notion that a one size fits all file structure would be suitable for different account teams representing vastly different clients from many different industries was mistake number one. The project managers did not take the time to properly assess what the organization’s true needs and wants were and simply operated under assumptions. They may have been doing this to avoid scope creep, which often happens in the Association Management Firm setting because there are so many different agendas that come to the table. However, in this instance where the project largely affected day to day operations, failure to involve the entire organization in the planning process lead to a great amount of internal imbalance.

The next mistake was formulating an unreasonable timeline, which included several hours of pointless meetings and then full days, or even weeks, where entire account teams were taken away from their work and forced to moved files around within the network to comply with the new uniform structure. I was personally affected by this as my account team had a system in place for invoicing which relied heavily on file paths – all of which would have to be changed due to the relocation and none of which was considered or anticipated by the project manager. This was an absolute waste of human capital and client’s suffered because of it.

The successful project was one that was carefully cultivated over a two year period by a project manager with a strategic and forward thinking mindset. The Global Development Department at my current company put together an ROI tool which will allow them to assess how to approach various different markets. Each department had a seat at the table and everyone’s role in the process was considered. While implementation is just now beginning, there is great excitement! A good project manager should be able to generate positive feelings about the project – as opposed to the previous example which generated a lot of groaning and eye rolling. I hope to be able to partake in and lead more successful projects like this one in the future.

 

Misericordia in Motion – Team 5

Misericordia Logo

 

Project Description:

The goal of our project was to partner with Misericordia Heart of Mercy and provide donations and service to help bring awareness and further contribute to their cause. Our team participated in two service events for Misericordia as well as raised donations and awareness through social media and online outlets. We hosted an event with a family-friendly movie for residents and the general public which also included other activities such as yoga, dancing, face-painting and a silent auction to generate monetary donations to Misericordia and also interact with and engage the community. Four of our team members also volunteered at the Greenhouse Inn for Sunday brunch at Misericordia’s campus restaurant. Our group maximized online donations through the implementation of social media outlets such as Facebook, Twitter, Instagram, and LinkedIn. This social media exposure and personal networks brought significant online donations through our FirstGiving.com page as well as provided valuable awareness to the work done at Misericordia.

DSC_0636DSC_0726

 

 

 

 

 

 

Charity Information:

Misericordia is a Chicago-based not-for-profit corporation serving persons with developmental disabilities.  Misericordia serves more than 600 people through a wide variety of programs.  The Mission Statement of Misericordia is to “support individuals with developmental disabilities in maximizing their level of independence and self-determination within an environment that fosters spirituality, dignity, respect and enhancement of quality of life. We promote development of natural family and community support, community awareness, education and advocacy.”  Misericordia offers a continuum of care based on the needs of the individual.  They also offer peace of mind to the families of residents since they know their loved one is cared for in a way that will enhance their life.  Donations allow Misericordia to offer more than just room and board for residents and offer them exceptional programs, such as intervention by physical therapists, occupational therapists and speech therapists.

 

Success Metrics:

Goal #1: Generate $3,000.00 in revenueDSC_0718

Our group was able to produce $2,795.00 in revenue and we reached 93% of our intended goal.  This was amazing as approximately 70% of our revenue was generated entirely online through our personal/corporate networks and social media outreach. Through many in-kind donations and resources we were able to minimize expenses to $30 and the entire remaining balance will be donated to Misericordia.

Goal #2: Provide 48 hours of service

Our group was able to produce 58 hours of service to Misericordia through two service events. The first service event had a family-friendly movie for residents and the general public which also included other activities such as yoga, dancing, face-painting and a silent auction. At this event we had approximately 60 attendants including 45 Misericordia residents. Four of our team members also volunteered at the Greenhouse Inn for Sunday brunch at Misericordia’s campus restaurant.

DSC_0744DSC_0783

Goal #3: Have a social media reach through 4,000 impressions

Our group was able to produce over 175,000 impressions! Our original objective was to produce 750 likes and 3,000 reach on Facebook, 25 retweets on Twitter, 25 hearts on Instagram, and 10 snaps on Snapchat or approximately 4,000 impressions. By combining all of our social media exposure through the listed social media outlets, including LinkedIn, our group was able to far exceed our original goal by producing over 175,000 impressions. Each impression provides awareness and recognition for the valuable work Misericordia does.

    DSC_0622

Advice for Future Teams:

  1. Defining individual responsibilities and workflows is key. By having individual ownership, everyone was held accountable and felt that their contributions were part of a collective goal.
  2. Decide on a goal or mission and stick to it. It is imperative to have a clear and attainable scope for your project. Scope creep can be easily overlooked and before you know it you have a completely different project.
  3. Have an online presence. With the various conflicts people have whether it be family, other classes, work, etc it is very difficult to get everyone in one physical location. Our group utilized Google Docs and Google Hangouts to make sure that more people are able to participate no matter where. In addition, our group took advantage of online donations as part of our online presence.

Lessons Learned:

  1. Having a team mission is critical. By understanding what it is your team wants to accomplish makes other decisions much easier. For example, when venue conflicts arose our team knew that the involvement and engagement of Misericordia residents was more important and this ultimately prevented us from changing venues.
  2. Continue to monitor risk and make any updates for new risks that may occur. With so many variables in the field project it is important to have contingency plans. Having an effective risk management plan allows for your team to be proactive in dealing with future issues and have a proper response to overcome the issue.
  3. Utilize an effective communication strategy. There are many applications groups can use to make communication easier such as the app Slack. Setting some rules of communication and having a proper way of communicating allows for the group to work together more effectively. In addition, this will help eliminate some redundancies in communication such as email overload.

Risky Business

 

This week in class we had to turn in our risk assignment for our fundraiser project.  As a financial analyst I work closely with risk on a daily basis.  Something we touched on in class when we created the risk was just the basics. What sort of risk, probability, value of the risk and contingency plan.  In reality, there is so much that goes into risk.  That it why I chose to research risk and see what else there is to know about risk.  I found a great article that talked about the fluidity of risk. The project management realm deals with an ever changing environment, which means risk is changing on an almost daily basis as well.  In my business, the programs I work on are very complex, which makes risk management and analysis complex as well and needs to be continuously re-visited and re-analyzed.

When creating our risk at my company, we don’t know how many out of box failures we may have on a program.  We don’t know how many parts might fail.  That is why over time, it is pivotal to continue to re-visit our risk.  Something I use in my job is called a “gating month”.  It is a month when we think our risk will be retired or OBE (overcome by events).   That being said, looking at risk on a daily basis is so important to monitoring project health.  As a project progresses and evolves, potentially so does the risk.

A personal example from my job as a financial analyst on government programs has to do with gating months.  For example, on my current program, we build and deliver hardware to the customer.  Because of that, a risk we carry has to do with our second sourced suppliers.  If a supplier who makes a part for our hardware build goes out of business or stops making the part, we need to be prepared for the costs that will go into replacing that part.  That includes finding another supplier, validating them and then potentially modifying the part to our specs.  This isn’t just a risk we carry throughout the entire program.  Over time, as we deliver hardware, this risk becomes smaller and smaller.  Why carry risk for 500 deliveries when we only have 50 left?  That is why, as a financial analyst, I work with the PMO to analyze our delivery schedule in relation to our risk items.  I help plan when this risk item should be reduced and when it will be OBE. When that happens the PMO needs to make an important decision.  Do we want to retire the risk to our bottom line or do we want to re-visit the program health and plan risk items for other problems that, over time, have now presented itself?

I have learned through personal experience, class and this article that risk is something that needs to be looked at continuously.  It needs to be managed daily and analyzed daily for any changes to the project and its environment.  It needs to be reduced or increased.  It needs just as much attention as the project execution itself.  In the article I read I found a great chart that shows the fluidity and cyclical nature of risk management and risk analysis:

 

Now a few questions on risk management and risk analysis:

1. Do you use risk at your job?  What sort of risk management and analysis do you perform?

2. Have you experienced a unique risk circumstance? What happened and what did you learn from the experience?

3. Do you have anymore insight and input into risk management and analysis?

4. Any other questions and comments are welcome!

 

http://www.pmoplanet.com/cross-discipline-elements/risk-management/

Risk Management (Aviation Project “Aircraft Lease Return”)

 

heavy maint

People tend to think about risk management as the use of statistical data and probability; well not always! Risk management is a process that we use in every day of our lives  and sometimes without even knowing. For example, before we go to bed, we adjust our alarm to ring at 6:00 a.m. Now, the question, why we did not set it to ring at 7:00 a.m.? The obvious answer is that we will be late for school or work!  The word ‘”risk” may be defined as the likelihood a loss will occur. Risk management is the preventive measures that we take against such  losses.

In the aviation industry, an Aircraft Lease Return Project involves very high risks. The project is about the redelivery of an aircraft back to the lessor (owner) in accordance with the terms and conditions specified in the lease contract. In order to succeed, the risk management plan must be well defined in term of its objective and importance. The preparation of a risk management process is usually started at least six months before the kick start of a project. The reasons are:  these projects may involve substantial an aircraft maintenance check; sending the aircraft engines and some other aircraft components to the overhaul facility; additional aircraft spares may require to be purchased. Such spares may have long lead time. To prepare a risk management plan for the project, first we need to start with reviewing the lease contract to identify the significant risks. For example, what are the consequences if we don’t meet the return conditions on the redelivery date? Or what are the penalties on late redelivery of aircraft? Next is to do the risk assessment by making different scenarios. For example, what if the engines get delayed in the overhaul facility? This could impact the entire timeline of the project severely. After identifying and assessing all risks, the risk responses have to come into the picture. Do we mitigate, transfer, avoid, or retain? Aircraft lease return can have lots of surprises, such as failure of components before the redelivery date, project scope change, change of the project team members or even the project manager, etc. Therefore, a contingency plan should be ready to execute at anytime.

Risk control plays an important part in the project plan. Risk control is a method by which project team members evaluate potential losses and take action to reduce or eliminate such threats. Risk control is a significant action taken by project team members that is intended to identify proactively, manage, and reduce or eliminate risk. All projects should have a well-prepared risk management plan. An aircraft lease return project can be very costly and stressful if the risks are not identified and assessed at the early stage.

Engine Overhaul

If you are assigned to be the project manager of an aircraft leased return project, what could be your action if the aircraft engines are not arriving on time from the overhaul facility as planned?