Saturday, July 14, 2007

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

Friday, July 13, 2007

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.

Thursday, July 12, 2007

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.

Wednesday, July 11, 2007

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.

Tuesday, July 10, 2007

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.

Sunday, July 8, 2007

Get PMP Certified in 35 days from Scratch

I had suggested this to one of my friend. It works!!
He passed with 69% marks.

Total effort in Plan: 35 days

Make sure you can spare at least 3+ hours a day for next 24 days
And 8+ hours for last 11 days before you attempt the exam.

Register with PMI:

Go to http://www.pmi.org/

Select "Global Membership & Communities-->Membership-->Individual --> Online", Membership fee is $119. As part of membership, you will receive PMBOK Guide from PMI
Also get a copy of Rita Mulcahy’s PMP exam prep book.

Apply for the certification exam
Select "Professional Development and Careers-->Certification Program-->Online Application"

You need to do this now as you may get a slot only after 30-40 days depending on the availability. Exam fee is $405 for members. Your preferred exam date should be 35+ days from now.

Register for a PMP Exam Prep 4 day course on 25th day from now.

Start Preparation:

There are 12 chapters in PMBOK
Read one chapter two times in a day for next 12 days
First read ITTO (Inputs - Tools & Techniques - Outputs), next read and understand each item in detail.
ITTOs are very important, Logically understand and Memorize all ITTOs, you will get many questions on that.

Now start reading Rita Mulcahy’s PMP exam prep book in parallel with PMBOK
This book has all the needed basic concepts in detail with scenarios, exercises and practice questions. Since you are now familiar with the PMBOK, you will start understanding the concepts in depth. This may take another 12 days.

This is not sufficient to attempt the exam. Remember that you need to follow PMBOK as bible. No mugging or guess work will help. All you need is through understanding of concepts and good buffered Short Term memory.

To boost your short term memory, I would suggest you to take a PMP Fast Track Exam preparation course. This will help you grasp all the chapters in 4 days and also you will get the much needed 35 PDUs certificate which is an entry criteria for the exam.

Now you will have increased confidence level to attempt the exam.
Take off from your work and other commitments for next one week and start preparing for the exam. By this time you would have realized your gaps and week areas. Start paying more attention to difficult areas. Revise, Revise and Revise. Attempt practice questions on difficult areas like Project Integration Mgmt, Time Management, and Cost Management etc.

Keep cool mind on exam day, relax, don’t stress yourself as you will need 100% of you mind to work at its optimum speed continuously for 4 hours.

All the best!