Biggest Program Risk
Can you elaborate a time when you had to take a considerable risk in a program to make it successful?
This question is behavioral! Focus on an experience you feel comfortable and knowledgeable about.
How did you mitigate the risk?
Did the risk work out or not?
What would you do better in future?
Before we dive deep into a sample answer for this question, let’s take a quick moment to understand certain key points below:
- What is the interviewer’s motive for asking this question? The interviewer is looking to see if you have demonstrated the art of taking calculated risks. You don’t want to come across as a person who is risk-averse or someone who takes risk recklessly.
- Every company and program will involve taking risks to various degrees, which is why this is a frequently asked TPM interview question. And it’s YOUR story based on your experience, so please do prepare and practice it well before your interview.
- For behavioral questions, it is recommended that the answer be in SAR format (Situation for the first couple of minutes, followed by Action for about four minutes, and finally the Result for a couple of minutes).
Example answer:
Situation: One of the biggest risks I have taken was in a recent program, where we developed a new feature based on beta feedback and released the feature externally without QA sign off. We had about ten days from the time we decided to include this new feature to external launch. Usually, the biggest chunk of time in each release cycle was the sign-off from an external QA team. We fast tracked the dev effort and completed the development of the feature in five days. Unfortunately, however, the QA team did not have the bandwidth to run a test pass on the new feature given other priorities within five days before external launch.
Action: Our options came down to launching the feature without external QA sign-off or delaying the P0 feature request from customer feedback. As the TPM of the team, I decided to launch the feature without QA sign off and planned for mitigating the risk:
- I worked with the developers and formulated a combined engineering test strategy and ensured they run all the unit, integration tests and build verification tests, and fix all the issues from these automated tests.
- I organized a bug-bash for all the people on the team for all the days leading up to launch and had the fixes deployed by the on-call developer the same day.
- I worked with the dev team to build a solution for acquiring customer feedback and logs to help debug any problems faced by the users once the feature went live and a roll-back plan for disabling the feature if we found blockers after the release.
Response: The feature was released on the external launch date, much to the delight of the users (and bloggers). We surpassed expectations in terms on how many users were on-boarding to the app due to this P0 feature we released by over 25%. The risk of going ahead with the launch without external QA sign off but with having some guardrails in place really paid off in this case.
Why is the above answer considered good?
- It gives the interviewer a brief, but clear, background to help understand the context before talking about the risk.
- Risk and mitigation go hand-in-hand. The answer seamlessly includes the mitigation plan as part of the narrative.
- The mitigation plan clearly describes what the interviewee has done to mitigate the risk.
- It includes concrete data to measure the outcome of taking the risk.
Helpful tips
- Plan, Prepare and Practice: This is one of the best ways to deal with behavioral questions in an interview.
- Reciting the answers in your head doesn't work - practice talking out aloud in front of a mirror or get your buddies to listen to your answers.
- Don't get caught up too much in the details - be clear and concise in your answers. A good way to evaluate if you are giving too many details is by doing plenty of mock interviews and getting feedback from the interviewer. And remember, if the interviewer is interested in knowing more about what you are talking, they will probe deeper.
- Finally, behavioral questions don't have a right or a wrong answer. They are your stories, your experiences - it's your job to convince the interview that you have done your best in the circumstance you experienced!
I will divide my answer in 2 parts:
Process for Risk Management can be broken down into 3 parts: Risk Identification: Risk identification is a team effort and is an ongoing process that happens throughout the Project. Technical Risks are usually identified during design/build/testing stage. I maintain a Risk register document to capture all the risks identified during project meetings/discussions for further assessment. Risk Evaluation: At this stage, Project team will assign probability and impact to each risk. Probability is the likelihood of the occurrence of an event while Impact is the result of the event if it happens. Probability/Impact assessment can be done qualitative or quantitative. Usually, quantitative analysis is preferred. Risk Score is determined by multiplication of Probability and Impact. A high priority risk is the one with a high risk score. Risk Response definition: As a team, we will determine the appropriate response technique for all the risks identified in step 2. Following could be the potential response categories: Mitigate: To reduce the impact of risk if it occurs Avoid: To prevent the risk from occurrence Accept: There is no workaround and risk must be accepted Transfer: Transfer the risk to a third party
Real Life Situation: I was working on a Project to launch a web based application for one of our client business team. During the testing phase, we identified that the response time of the application was exceeding the threshold limit for users/machines outside US (Germany/China). This was a big risk as high latency could result in bad user experience and decline in their daily productivity. It was identified as a High priority risk and we needed to devise a mitigation plan in the event it occurs post deployment. I scheduled a call with the Engineering manager and Core technical resources to review the architecture and established that lag was happening at the time of record retrieval which required access to shared database server based in US. Database was hosted centrally and there was no localization of data. We decided to build read replicas of the database server in all the impacted regions. We had to modify our design and ask for additional funding to build additional servers. There was about 3 weeks delay in the launch of this application due to additional time required for building and retesting. But we were able to bring the latency back to acceptable limits and avoid adverse impact to Business in production. It was finally a successful launch. Our efforts were appreciated by Business leaders.