Risk Management – Sharing the Learning - Scenario 5

One line requirement

Potential Challenges:

1. Incorrect assessment of the impact – If one liner requirements are taken at face value, there is a risk on missing out very critical impacts.

2. The above situation can very easily translate into estimates way off the mark risking the entire initiative.

3. If estimates are arrived at based on high level requirements and communicated to the client, the client, at times, starts expecting the final cost in similar ranges. This can become an issue from financial sponsorship of the project.

4. In such situations where functional requirements can not available, it is very easy to loose focus of non functional requirements; mainly usability and performance needs

Mitigation Strategies:

1. Multiple Options – A short term, near term and a long term solution can be thought of and discussed with the client.

2. Knowledge Management – Knowing the domain of the customer / application is very important to assess the right impact.
E.g. In transportation domain a one line requirement saying that improve the visibility of shipment on web tracking system has a potential to translate into very high amount of impact. The change would be required to all operational systems to generate such information, processing it and persist it. The data services applications will need to retrieve it and finally the delivery channels will need to display it. This could well be a program of 6+ months

3. Client Education – It is necessary to make sure that the client understands the true complexity and extent of impact. This will help to make the client appreciate the budget and timelines.

4. Even if non functional requirements are not stated, the same can be derived based on past experience in same or similar domain / implementations. This can be shared with the client to ensure correctness of the information.

Risk Management – Sharing the Learning - Scenario 4

Crunched schedule project

Potential Challenges:

1. If a project is crunched beyond a certain limit (say > 40% as per the COCOMO Model), there is a high risk for failing the timelines and or poor quality.

2. Resource utilization becomes a challenge when many tracks run in parallel. Result can be high effort over-run.

3. Team morale typically takes a hit in such project

4. Low tolerance for defects. Higher or in cases even normal DIR (defect injection
rate) can impact project timelines.

5. Crunched projects typically have a context at the client end e.g. come commitments to business, regulatory needs, etc. Hence it is important that such projects are done first time right and succeed in achieving its objective.

Mitigation Strategies:

1. Joint Application Development – Jointly working with the client is a good de-risking strategy. Issues are identified and resolved early. Also, this helps in creating a team spirit.

2. Modify team structure and reporting – The development team can be empowered to take certain decisions. Also the reporting structure can be changed to facilitate attention of the top most stakeholders and fast decision making

3. Leveraging GDM – Work can be carried out at various geographical locations. Roles and responsibilities of each and every team needs to be were well defined.

4. Improved communication – Top to bottom every one needs to be made aware of the objectives and implications. SPOC can be defined for all the teams. Stand-up meetings, daily handover meetings, weekly status meetings, Net Meetings and white-boarding – all possible means of communication can be leveraged to ensure that every information and change is communicated appropriately.

5. Process Tailoring – Can be done to suite the situation and potential risks of quality mitigated by better quality resource commitment.

Note - People are the single most factors that can make or break a project. If all the teams are driven by the single objecting of making it happen, the engagement can succeed. There is no prescription / mitigation step to motivate people but some things that can help are:

1. Common communication from the top most executive to all e.g. The IT CEO addressing all development teams in cafeteria.

2. Articulating the objective of the project, its need and criticality very clearly to all the teams

3. Team Leaders need to lead from front by example.

4. Usually the toughness of the challenge itself can tick ☺

Risk Management – Sharing the Learning - Scenario 3

Programs with 3rd party vendor involvement

Potential Challenges:

• Dependency on other projects or parties whose outcome or working cannot be influenced by you.
• In case there are stringent SLA with penalty for SLA breach, multi party involvement can pose a potential financial risk

Mitigation Strategies:

• Joint risk planning and mitigation with the client and other stakeholders
• Well defined communication plan for client and also other stakeholders
• Enter into an agreement with the interfacing vendors (e.g. OLA – Operation Level Agreement). The agreement can define overall test requirements and gain commitment from interfacing systems to provide support during testing and implementation.
• Review of the SLA and other agreements from companies legal cell to ensure that we are not at financial risks due to some one else’s breach of contract / SLA.

Risk Management – Sharing the Learning - Scenario 2

Complex Technology

Potential Challenges:

• No precedence – The technology landscape is changing on a daily basis with a new technology making to the market on a daily basis. It is likely that there would be no or less extensive know-how on a particular technology.
• Propitiatory products (typically from small time vendors) do not have much information in documentation and or public domain like mailing lists, discussion forum, “Googling”, etc. available. This increases the learning curve and dependency on 3rd party.
• Sometimes customers buy 3rd party products based on their marketing blurs without much due diligence on the technical information and need context. Fitness of use can get compromised in such cases.
• No estimation methodology, historic data or guidelines are available for such type of work.
• Immature products typically have defects that could get unearth during the development phase

Mitigation Strategies:

• Guide the client, as possible in selecting appropriate products that are fit for use. Adopting a structured approach to product selection is a good practice.
• Doing a proof of concept (POC) is recommended depending on the complexity and criticality of the requirements. Target the most risky scenario for this POC so that issues are identified early one.
• Obtain a formal support mechanism from product vendor during the Design & Build phase. This support should be available at both offshore and onsite.
• Work with the client to define a process for fixing issues in the 3rd party products identified during project execution.
• The contract can be a time and material kind in case the financial risks are considered high.
• Communicate the risk involved with using a complex technology and new product to the client before beginning the assignment.
• The learning from the engagement needs to be collated and made available in the internal knowledge portals for future engagements.

Risk Management – Sharing the Learning - Scenario 1

Let us see some hypothetical situations and the corresponding challenges which can be potential risks for the project. Also are accompanied mitigation strategies for these challenges.

First Time Customer / First Time Off-shoring

Potential Challenges:

• Low Confidence Level - Being the first engagement, it is very natural for the client to be apprehensive.
• Insecurity - Off-shoring is a paradigm shift for customers that are off-shoring first time customers. It is difficult to digest the fact that people, miles away can understand their requirements and deliver in time.
• Frequent changes – Typically customers engaging off-shore firms for the first time are not used to adhering processes. Frequent changes to the requirements are a common observation with such clients. Also many such clients have implicit requirements and expect the incorporation of the same in the project.
• Typically such clients find estimation as one of the issue areas of discontent.
All such issues manifest itself typically in risks like requirements issues, micromanagement from client and relationship endangerment.

Mitigation Strategies:

• Educate the client on offshore processes and practices. Arranging a client visit to the offshore development centre is a good way to boost the client confidence.
• Have elaborate communication plan with multiple and multi-level communication channel e.g. the project sponsor can have two or three points of contact. This redundancy in communication channel helps to foster the necessary confidence.
• The customer facing team needs to be oriented / trained in appropriate soft skills and have the client cultural sensitivity.
• During requirements elicitation phase adopt a process driven approach to ensure holistic information capture. Apart from functional requirements try to elicit the non functional requirements also e.g. performance, user interface, maintainability, etc.
• Try and adopt a top down and standard estimation approach such as Function Points. These are easy for the client to verify and accept.
• Transparency – Keep the client informed all the time. In case any critical issue is anticipated, share the same albeit with an appropriate mitigation strategy.

Risk Management in Action - Part 2

Symptoms of a Project in Need of Risk Management

If we are not proactive enough to identify Risks early on in the project, potential risks will start materializing. As an alert project manager you could use the following checklist to know if the uncertainties have started getting manifested into realities.

1. Poor executive buy-in
• No or minimal participation from top client side executives
• No SOW or any agreement document to proceed with work
• No communication channels with the client top brass

2. Poor Requirements
• High number of TBD in the requirements specifications
• High number of issues in issue tracker with status as open
• Ever changing requirements with late or no baseline of the requirements
• Client raising CRs even in advance phases of the project

3. Poor Estimation and Scheduling
• Team staying back late from the very beginning of the project
• Some components in project not estimated / accounted for in the estimates
• Members waiting to be assigned work, waiting due to dependency on modules
• Project having many assumptions that are not validated by the client / stake holders / experts
• Project crunch not quantified

4. Poor Project Management –
• Project resources working on unplanned activities,
• More than average time is required to report quantitative metrics

5. Poor Quality –
• High defect injection rate
• High amount of rework
• High number of iterations before closing of issues

6. Poor Communication –
• Team does not know what to do,
• Gap in Top Management and Client perception of the project health against the ground zero situation.
• Lack of comfort of project manager front in breaking the bad news

7. Lower Team morale –
• People working in isolation,
• The “team spirit” missing and people issues within team,
• Team Members no longer have faith in the management

Risk Management in Action - Part 1

Identifying Potential High Risk Projects

As stated before project management is characterised by uncertainty and risk. Though there are no prescribed criteria to identify a prospective high risk project, we do outline some thumb rules that one can keep an eye on.

Thumb Rules for identifying Projects that may become High Risk Projects

• Projects / Proposal with one liner requirements: These are usually projects from a known client. The client expects you to understand statements like “Replace the existing system using DB2-Delphi with a .NET system” or “Use the latest technology to rework the current report generation”.

• First time customer: This might be a customer who is off-shoring for the first time. Other case might be that the customer has been bitten hard by a former offshore IT vendor. Hence, one may encounter problems like low confidence levels, micro management by customer, escalation at trivial issues, etc.

• First time technology or complex technology: This needs rigorous technology management and client cooperation to deal with unknowns in emerging and difficult technologies.

• First time project manager: Have you heard the proverb “There are no good project managers - only lucky ones”? Project Management is one of the keys to project success. Thus, good project management is a must for good risk management.

• Bad history of project execution for an account: If there have been cases of failure for projects in an account, one should ensure good risk management practices in other projects in the same account.

• Crunched projects (> 40% COCOMO crunch): Project with crunched timelines is critical since there is little time to set right things that go wrong.

• More than 50% of people have technology mismatch.

• Multi location projects: Managing virtual teams is a reality today. But it needs maturity with the project manager and the team.

Risk Management and Communication

Communication is the most essential function that can affect any outcome. Comunication does not merely mean getting the message across to the stakeholder, but it also implies winning over your stakeholder so has to have support for your project at all times. Given below are a few communication tools which will work the right way in getting your risks through.

1. Project Initiation Report:

Commonly referred to as PIR, this report summarises the project on various fronts like effort, estimation, risk-impact analysis, risk management, effort available and projections on project completion. It is created before the project start and serves as a powerful communication tool to project sponsor and other key stakeholders within the delivery organization.

• SDLC Stage: Project initiation
• Key Stakeholders: Project Manager, Project Sponsor, Project Quality Advisor, Project Unit Head.
• Primary Intent: To give an exhaustive end to end picture of the project situation including the risks and the risk management plan to internal stakeholders.

2. Project Plan: Project plan

The risk management section of the Project Management Plan serves to communicate risk, its impact, mitigation and overview to the end viewers. The initial risks flow down from the project initiation report (PIR). Till the end of the project, it communicates the risk management plan to its stakeholders.

• SDLC Stage: Project start to project closure
• Key Stakeholders: Project Manager, Project Quality Advisor, Project Sponsor,
• Primary Intent: Continuously monitor risks and its impact to internal stakeholders

3. Estimation

Usually, it is not a common practice to share details of estimation with the customer. But in some cases, usually common in large accounts where the relationship with the client has matured over time, estimation details are transparently shared. At the point in time, it is also advised to have an annexure of risks to the given approach.

• SDLC Stage: Proposal stage
• Key Stakeholders: Project Manager, Project Sponsor, Customer
• Primary Intent: Convey the initial risks of the chosen approach to client, especially the ones impacting cost.

4. Status Reports

This is a communication tool mainly between the Project Manager and Customer to apprise the customer of the progress on the project. It also highlights the issues and risks on the project to the customer.

• SDLC Stage: Project start to project closure
• Key Stakeholders: Project Manager, Customer
• Primary Intent: Keeps the customer appraised of the project progress at the same time ensure that risks and issues are effectively tracked.

5. Client Portal:
In large accounts, where the cost overhead is justified, it is advisable to have a portal where by the projects across the account can be tracked through the portal. Usually, in these cases, it is also customary to have joint risk mitigation strategies with the customer’s buy in.

• SDLC Stage: Project start to project closure
• Key Stakeholders: Project Manager, Customer
• Primary Intent: Project updates can be posted on the portal from time to time both by the customer and software vendor. Also, it report generation based upon data can be facilitated. This portal thus increases the transparency with the customer and also seeks support on customer related issues.

6. Dashboard
A dashboard is similar to a Client Portal, the difference being that it is used internal to an organization. Other major difference can be that relevant dashboard snippets and event triggers are posted to the stakeholder on a periodic basic. Thus this uses the push mechanism for data unlike the pull strategy involved in case of a portal.

• SDLC Stage: Project start to project closure
• Key Stakeholders: All internal project stakeholders
• Primary Intent: Current project updates to all project stakeholder. Since it has the advantage of data getting pushed to the stakeholder’s inbox, it offers an edge over other tools.

Risk Management Process

Risk Management process can be considered as answering the following key questions:


1. What all can possibly go wrong (Risk Identification)?
The first step towards an effective Risk Management is identifying all the possible risks. A point to note here is, quantum of the risks by no way indicate the success or failure of the project. Hence this process needs to be unbiased and non-judgmental. One of the key challenges faced in this phase is need of a structured and repeatable approach of Risk Identification that will ensure that all the aspects of the Project are probed.

Some of the common tools employed for Risk Identification are:
• Checklists and guidelines
• Risk Repository / re-use of historic data
• Brainstorming and Experience (within and outside the team)
• Taxonomy Based Questionnaire (TBQ) by SEI

The deliverable of this phase is an exhaustive list of Risks.

Which risks do I take care of (Risk Analysis)?

The 80-20 rule applies here too. It is important to have a prioritized list of risk list to work on. One of the approaches used in our organization is Risk Exposure which is computed as – Risk Exposure = Risk Probability * Risk Impact.

Here Risk Probability is the likely hood of the risk materializing (expressed in %) mainly derived from historic data and Risk Impact is a number between 0 and 10. Quantitative and Qualitative guidelines are available to arrive at the risk impact. All Risks that have high probability (>=70%) and or high impact (>=7) are considered for Risk Planning.

The deliverable of this phase is a prioritized Risk List.

Note – there are various ways available to assess the probability and impact and quantify the same.

3. What do I do with these prioritized risks (Risk Planning)?

Some of the common strategies for Risk Planning are:
• Risk Transfer - causing another party to accept the risk, typically by contract, insurance or by hedging.
• Risk Avoidance - includes not performing an activity that could carry risk.
• Risk Reduction (i.e. Risk Mitigation) - involves methods that reduce the severity of the loss should the risk occur.
• Risk Acceptance (i.e. Risk Retention) - involves accepting the loss when it occurs. Risk retention is a viable strategy for small risks where the cost of insuring against the risk would be greater over time than the total losses sustained.
It may not be possible to use all the strategies all the time. Once the strategies have been determined, they should be documented in a risk management plan (RMP) or as part of the project plan. Decisions taken need to have a rational (and or data points) to support.

The deliverable of this phase is a Risk Management Plan.

4. Am I doing what I planned to do (Risk Tracking)? Things are going as planned (or not), what do I do (Risk Control)?

Once the plan is made and implemented, it is a must to continuously monitor the status of various risks and action items implemented as a part of RMP. Metrics need to be defied to enable objective tracking. Tracking can be event driven e.g. completion of a milestone or frequency based e.g. every week-end. In case any deviations are observed in the risk status or implemented plan, we need to take appropriate actions. Similar to the PDCA cycle, we need to trigger the Risk Management cycle again.

Risk Management Introduction

Each one of us will have a horror story to share of projects failing or on the verge of failing or the “mess” that we were in. One of the primary reasons for project failure is our inability to handle uncertainties at the right time and in the right way i.e. effective risk management.


Definition

Risk can be defined as an event or a situation that has a likelihood of occurrence and can cause loss (or benefit). Risk Management is the process of measuring, or assessing, risk and developing strategies to manage it. Strategies include transferring the risk to another party, avoiding the risk, reducing the negative effect of the risk, and accepting some or all of the consequences of a particular risk.


Issues in Risk Management

Many an organizations and projects do have a risk management program and plan. However, the adoption of the same has issues. Some common issues that can be observed are:

1. Ad-Hoc approach – Though the organization might be having a Risk Management framework in place, it is common to see Project Managers doing Risk Management as an ad-hoc activity; visited only at the project creation/initiation stage and from the perspective of completion of the project plan. The Risk Management Plan (RMP) is seldom revisited during the project life cycle stages or project milestones. It is done based on the experience and risk orientation of the Project Manager.

2. Isolation of the process – It is not an uncommon sight to see the Project Managers filling the RMP excel sheet, Risk Portal, etc. alone. It is seldom a team activity and seeking participation from SQA, Technical Leads, SME, and senior management is virtually unheard off.

3. Reactive approach – Risk Management is seldom proactive. Typically a project is classified as high risk only when it is in middle of the build phase or half way through the schedule. Late flagging results in reactive responses and the eminent fire-fighting exercise.

4. Communication issues – Risks are known within the team - If an event is happening for the first time and is unknown to the team, no amount of Risk Management would help ☺. The issue is free and fair communication of the same. There is reluctance on part of various members to communicate risks. The team members are not keen to share risks with team lead; project managers are reluctant to share it with client and client with business or end users. This reluctance is on account of the perception that Risks are an “evil”. We need to understand that Risks are neither good nor bad. Risks are inherent in any project and effective management of the same is a critical success factor for the success of the project.

5. Education and awareness – One observation is that Project Managers (current and would be) are not appropriately oriented towards Risk Management. Project Managers tend to lack awareness of the Risk Frameworks, Processes, Repositories available within and outside the unit and organization. Sharing learning of failed projects is very rare.