Project Summary

Background to the project

CAI is a global IT services firm that is currently managing
engagements with more than 100 Fortune 1000 companies and
government agencies around the world. Specific CAI offerings
include balanced outsourcing solutions, legacy support,
application development, knowledge capture, desktop services,
and managed staffing services.
As a result of increased competitive pressure, technology
savvy clients, and tightening margins, CAIs Solution Centers
needed to improve service and reduce costs. Increased project
governance was key to success. Focused areas of project
governance that were addressed included: Establishing,
Evaluating, Enabling, Defining, Controlling, Monitoring,
Measuring, Acting and Developing.
CAI had manual-based Project Governance procedures in
their Solution Centers. Metric data collection was via face-toface communications and e-mail. Often, new teams form in
these centers. A long-standing resource management challenge
is training new team members to perform in a consistent and
repeatable manner. This issue occurs not just at CAI but across
the IT industry. Often new team members need to re-learn the
same processes by making the same
mistakes made previously not because they need to learn
from their mistakes, but because processes to capture previous
mistakes and translate them into employee training are often
costly, time-intensive, and overlooked.
So, CAI chose to implement Advanced Management
Insight (AMI). Initial implementation was eight large projects.
The system was used out of the box for nine months. Based
upon feedback received and utilizing AMI authoring tools, the
system was customized with specific questions, rule, and
dashboards in December 2008. The customization included:
Monthly Project Management Procedures.
Monthly Developer Procedures.
Weekly Execution Assessment for the Developer.
Weekly Execution Assessment for the Project Manager.
Rolled out to all projects in the Harrisburg Solution Center
in January 2009.
75+ people responding to questionnaires.

 400+ questionnaires taken per month (weekly and

monthly based questionnaires).

List of project stakeholders

Top level business leaders such as the Board, Executive,

non-Execs, and especially heads of Finance, Operations
and IT.
Those that have a responsibility for investor and public
relations.
Internal and external auditors and regulators.
Middle level business and IT management.
Key business partners and suppliers.
Shareholders.
Customers.

Main goals of the project

Availability, security and continuity of IT services.

Costs and measurable returns on investments.
Quality and reliability of service no embarrassments.
IT not appearing to respond to the real needs of the
business.
Identification and management of IT related risks to the
business.
Capability and skills of human resources.
Compliance to legal, regulatory and contractual
requirements.
Responsiveness and nimbleness to changing conditions.

Risk Management Plan

After reading and finding out, we realize that risk
management is the heart and soul of project management and
failing to practice it in the right manner can have fatal
consequences on IT projects whether it is a CRM roll-out,
business intelligence or even a nation-wide integration project.
Proper risk planning can save the entire investment and
increase the likelihood of project success. However, planning
alone is not enough if monitoring of risks is not performed
thoroughly. Here are the pitfalls of IT project risk management
and the actions to avoid them:
Disregarding Enterprise Risk Management
Enterprise Risk Management (ERM) specifies the
processes, frameworks, and methodologies an organization
uses to identify and manage all risk types such as operational,
strategic, financial, compliance, etc. One needs to consider the
enterprise-wide risks and study the threats the organization is
likely to encounter during the project lifetime. While building
the risk management plan it is imperative to consult the Chief
Risk Officer. It can have a mammoth impact on the risk
management plan which needs to be congruent with ERM
probability and impact scales, risk appetite, risk quantification,
and risk management software.
Using Incomplete Risk Breakdown Structure
Risk Breakdown Structure (RBS) is the catalyst to identify
large number of risks. This should be used to identify risks and
stimulate the creativity of stakeholders participating in the risk
identification workshops. RBS can be developed by listing root

causes of potential risks. RBS highly depends on the project

domain and technology used. As an IT project manager, one
can start with an existing template and customize it based on
lessons learnt in past projects.
Ignoring Subjectivity
Subjectivity can make risk management lose its essence.
Risk averse stakeholders often identify large number of risks; in
contrast, risk takers may be oblivious to critical risks.
Identification is the first step of risk management that accounts
for 60% of the entire risk management cycle. Once the risks are
identified, the subsequent activities can be planned and
executed smoothly. The top problem of risk management is
subjectivity wherein different people perceive risks in different
ways. For instance, a financial risk may not grab the IT
managers attention and a technical risk is very unlikely to be
deemed as a risk by a finance manager. IT manager has to
minimize subjectivity and maximize quality of risk information.
One can avoid subjectivity by using Delphi Technique, as it
keeps the views of different subject matter experts (SME)
anonymous.
Assigning All The Risks to the IT Project Manager
Risk ownership has to be communicated to the risk
owners. Meticulous follow-up on unresolved risks is equally
important. The project manager should never own all risks.
Potential risk owners may be reluctant during risk identification
stage to accept responsibility of the risks they identify. Creating
a risk management RACI (Responsible, Accountable, Consult,
and Inform) Matrix will ensure that roles and responsibilities are
clearly identified and communicated.
Neglecting Risk Management Benefit Cost Analysis
Not all risks have to be managed. Some risks just need to
be accepted. The response strategies of negative risks (yes,
there are positive risks, known as opportunities) are Avoid,
Transfer, Mitigate, and Accept. However, often times the
acceptance strategy is never considered. A risk might be
accepted if cost of mitigation outweighs the potential impact.

Misusing Contingency
Reserve Contingency reserve can only be determined after
completion of multiple revisions of the project management
plan. It should only be used when a planned risk, whether
known or unknown materializes. It is not efficient to use
contingency quota of one risk at the expense of another risk
unless the latter has been resolved.
Doing it Once
Risk management is an iterative process and should be
practiced at all stages of the project. Many IT project managers
conduct risk identification at the beginning of the project and
shelve risks until they turn into issues. Leadership teams should
promote risk management culture amongst team members and
encourage them to actively report new risks and always have
risk management as top item on their agenda.

The monitoring and control

processes
The monitoring and control processes are tightly coupled
with Risk Register. The Risk Register will be updated, at
minimum, weekly and will be used to guide all risk review
sessions. Risk monitoring and reporting will involve the
following:
1. High and medium level risks will be monitored weekly during
regular team meetings. This is an
opportunity for team members to provide updates and to
ensure that they understand project risks.
2. All risks will be monitored on an ad-hoc basis between the
Project Manager and the Risk Owner. Risk
owners are expected to give regular updates to risk as follows:
weekly if the risk is high; monthly if the
risk is medium or low.
3. High and Medium level risks will be reviewed monthly with
the Steering committee. The Steering
Committee must also authorize the closure of high and medium
risks.

Conclusion

IT project managers need to safeguard their projects

against critical risks that might jeopardize the success of the

project. Identification of the right risks plays a pivotal role to

ensure efficient and effective risk management. Always keep in
mind the common pitfalls and remember that the biggest risk
in IT project management is failing to identify the right risks.