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, CAI’s 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-to-face 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 samemistakes 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 manager’s 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 anopportunity 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. Riskowners are expected to give regular updates to risk as follows: weekly if the risk is high; monthly if therisk is medium or low.3. High and Medium level risks will be reviewed monthly with the Steering committee. The SteeringCommittee 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.