Risk Management Deliverables

Risk Management Plan: at the planning phase of the project, the project manager has to come up with a Risk Management Plan which describes what risk management tools are to be used for managing risks, who is responsible for managing risks, who will be involved in project risk meetings, and how often risk meetings will be held. This plan is very important since it gives guidelines and policies for managing the risks throughout the project life cycle.

Risk Identification and Evaluation Meeting(s): at the early stages of the project planning phase, and after the project team is assigned, the project manager gathers the project team for a risk identification and evaluation meeting(s) during which all initial risks are identified no matter how trivial they are. In this meeting, we use the risk categories sheet to help identify the most relevant risks to our project. These meetings are very useful since the most critical risks are identified at early stages of the project and accordingly, the proper risk plans are developed either by mitigating the risk, avoiding the risk, transferring the risk or creating a contingency plan for the risk. Once the risks are identified, we start evaluating the risks by giving scores to each risk probability and impact on the project. Using the probability/Impact matrix, the resulting scores are used to prioritize the risks and the risks with low scores are put on a watch list, the high score risks are entered to the risk register.

Risk Register: The outputs from the previous meetings are either put on a watch list (for low score risks) or are entered to the risk register. The risk register is created at the planning phase and is continuously updated throughout the project life cycle. A risk register is a very powerful tool since it lists all important risk along with their probability and impact, their mitigation strategy and a contingency plan, risk trigger and finally each risk status (open, closed). During the project execution phase, risk review meetings are held to review all risks and update their status, monitor their trigger, and review the validity of each risk mitigation strategy and contingency plans.

Risk Review Meetings: Creating a risk register alone is only half way through; monitoring the risks and updating the risk register during the project life cycle is the most important part since new risks might arise, old risks might not be valid anymore and risk mitigation strategies are revised. During the project execution phase and until the project closure, risk review meeting have to be conducted on a periodic manner, usually monthly and sometimes bi-weekly depending on the project duration and complexity of the project.

At our organization, the project manager who is PMP certified from PMI leads all the efforts for managing the risks. In addition to that, my organization sends application managers for project management training, because they need to have the minimal set of knowledge to aid them properly manage their projects and contribute effectively in the risk identification meetings, setting the RMP along with reviewing the risks.

Reference:

Bran, F, Hîncu, D, & Radulescu, C. (2009), 'PROJECT RISK MANAGEMENT', Metalurgia International, 14, 5, pp. 102-105, Computers & Applied Sciences Complete, EBSCOhost, [Online], Available from: http://content.ebscohost.com.ezproxy.liv.ac.uk/pdf10/pdf/2009/2IZ2/01May09/37217958.pdf?T=P&P=AN&K=37217958&S=R&D=iih&EbscoContent=dGJyMNHr7ESep7U4v%2BbwOLCmr0meprBSsam4TLKWxWXS&ContentCustomer=dGJyMOzprkmvqLJPuePfgeyx44Dt6fIA

(Accessed 16 April 2011)

Fairley, R., (2005), ‘Software Risk Management’, Software Engineering Glossary, [Online], Available from:

http://ieeexplore.ieee.org.ezproxy.liv.ac.uk/stamp/stamp.jsp?tp=&arnumber=1438337

(Accessed 16 April 2011)

PMI, (2008), ‘The new PMBOK Guide’, edition 4

Common Risks

In the process of launching our bank, we went through lots of successful and unsuccessful project implementations; there are couple of reasons why some of these projects were unsuccessful, failed or partially successful. Absence of experienced resources, unclear requirements and unreasonable time schedules were the main reasons for unsuccessful software and business projects within my organization.

Gathering requirements and understanding them is the most common overlooked risk, unclear requirements is one of the most critical software risks which emerges from many factors such as: not enough knowledge about the needed solution, who gives the requirements is usually not the end user which makes it on a very high level, Business analyst didn't understand the requirements clearly, no requirements review from the quality assurance and customer, not enough analysis for the requirements and poor communication between the business analyst and the developers. To mitigate the impact of this risk, I would reduce the likelihood of unclear requirements to occur (Bannerman, 2008). I do this by presenting a quality assurance person, along with the business analyst, during the requirements gathering sessions to review the documented requirements and to ensure that they are written according to the customer needs, the customer has to review the requirements and approve it, at certain milestones during the development, the customer has to be involved in the review of the first releases of the software to fix any wrong features at early stages. There is no way to avoid unclear requirements, as there will always be a room for misinterpretation of the requirements, of lack of understanding for some.

Another common risk we face is that the customer/end user wants the application to have every possible feature: The customer (or the end user) usually needs a software to relief their pain or to replace an existing obsolete software, and that software has to have all possible features even the most trivial ones just in case it might be needed in the future, this therefore increases the complexity of the software and affects the time needed to finalize the project. To mitigate this risk, I would document the requirements, then explain to the customer the impact of the nice to have features on the code and project time lines which impacts the delivery of the project, and if they agree on the impact then a change request has to be developed and approved, by this we transfer the risk to the customer, if they don’t approve it, we escalate to the management. In order to avoid this risk, features are divided into major, good to have, and nice to have, the nice to have features are put on a wish list and if within the specified time frame there's time to develop them then they will be considered.

Another common risk is time estimates are not precise, the main cause for this risk is that the resources that do the planning are not the same resources that actually do the coding. To mitigate this risk, we add a buffer in the time estimates given by the team leader. And to avoid this risk, the project manager has to define the project team as a first step, get the estimates from the same resources that are going to develop the software and add a buffer to these estimates.

References:

Armour, P. (2005), 'Project Portfolios: Organizational Management of Risk', Communications of the ACM, 48, 3, pp. 17-20, Computers & Applied Sciences Complete, EBSCOhost, [Online], Available from: http://web.ebscohost.com.ezproxy.liv.ac.uk/ehost/detail?sid=2becee82-5b18-45a1-b7c1-8bbeca42928f%40sessionmgr10&vid=1&hid=19&bdata=JnNpdGU9ZWhvc3QtbGl2ZSZzY29wZT1zaXRl#db=iih&AN=16390580

(Accessed 16 April 2011)

Bannerman, P. (2008), ‘Risk and risk management in software projects: A reassessment’, Journal of Systems and Software, Volume 81, Issue 12, Best papers from the 2007 Australian Software Engineering Conference (ASWEC 2007), Melbourne, Australia, April 10-13, 2007, Australian Software Engineering Conference 2007, pp. 2118-2133, ISSN 0164-1212, DOI: 10.1016/j.jss.2008.03.059, [Online], Available from: http://www.sciencedirect.com/science/article/B6V0N-4SBSDDK-2/2/3664c09f725897dd90a36b4752b2e5ce

(Accessed 16 April 2011)

Costa, H., Barros, M. & Travassos, G., (2006) ‘Evaluating software project portfolio risks’, Journal of Systems and Software, Volume 80, Issue 1, January 2007, pp. 16-31, ISSN 0164-1212, DOI: 10.1016/j.jss.2006.03.038, [Online], Available from: http://www.sciencedirect.com/science/article/B6V0N-4K128V5-3/2/c33d2b09593d857e06c434889323d676

(Accessed 16 April 2011)

Software Development Outsourcing

Outsourcing is becoming the trend in most information technology areas, in my own organization, when we established it 3 years back, our decision was to outsource all junior positions within IT department, and hire qualified and experienced staff to manage certain areas. The aim was to reduce cost and get the best out of experienced engineers in areas we don’t master. This model succeeded in some of these areas but others not. The risks that come with outsourcing is general should be well identified and avoided if possible.

Cost reduction is one of the main considerations behind IT outsourcing, software development is one of the areas where outsourcing to other countries like India and Russia becomes cost effective, increase productivity, increase quality and efficiency. But its not always the case, software development outsourcing specially to other country brings risks that need to be identified, and well studied before doing so. Industry reviews claim that half of the software development outsourcing projects fail, and 28 percent of those projects, fail due to contract management issues (Gefen, Wyss & Lichtenstein, 2008). The three phases of outsourcing life cycle that are pre-contract, contract and post contract, should be assessed to identify the risks properly, as each of these phases has its own risks that might lead to the failure of the software development outsourcing model. Companies tend to tradeoff something in return to lower cost of operation and high revenues, but the minimize this trade off, the risks for each business decision should be well assessed and all risks should be identified.

One of the major risks in software development outsourcing is “Protecting Intellectual property”; software development outsourcing requires transferring files, source code, business process or trade secrets to vendors, and sometimes licenses for software that belong to a third party, both vendor and customer should monitor and administer the IP. Recent reports of stolen or purchased sensitive data from Indian outsourcing vendors triggered the concerns of across boarder’s data security (Rottman, 2006).  An employee from the vendor side can send the source code to his private email in order to work on it from home, or to sell it to other companies who might be interested in it. Such actions can be controlled by its hard to eliminate it. However, some Indian vendors started to increase the security procedures by securing areas using access cards, and forming clean desk policies to control the documents that their employee have access to (Rottman, 2006). This only cannot guarantee data security, for that UIC which case was studies by Rottman applied a successful strategy to mitigate this risk, they tended to outtasking to help secure their Intellectual property, the idea is to break their code into smaller portions, and spread it among different vendors to work on it, assuring that to impossible to reconstruct. UIC usually gives the work to three vendors and monitors the job carefully (Rottman, 2006).  In addition to that, IP should be protected by the contract between the customer and the vendor, including legal and financial penalties to more secure and protect the information and IP, in the pre-contract phase of the outsourcing lifecycle, the vendor should be selected carefully to be trustworthy, and working with the vendor in previous projects help building the trust and insures that the vendor understands the customers policies and concerns.

Another major risk in software development outsourcing reside in cost and time over-runs for the project, this can happen because of the instability in outsourced countries, either political or other like environmental, as well cultural gap between the customer and the vendor, such as different language, different work mentality, and big difference in time zones. Usually the customer expects the vendor to pick up the call immediately, but this might not be the case with big difference in time zones. Gonzalez, Gasco and Llopis highlight this as a major risk, as asynchronous communication like email can help in reducing this risk, but it doesn’t work well for all projects. This can delay the project and can directly or indirectly increase its cost. As well bad selection for the vendor who lacks for expertise or have different work mentality, can extremely affect project timelines and cost money.

Even though time zone difference can be seen as an advantage and a driving force, not only a risk, because they can work in shifts, and utilize this time difference to their advantage. However, if not utilized properly, it can still be seen as a risk. To mitigate this risk, mixing of near and far shore vendors can help reduce this risk, by this work that requires minimal interaction from the customer can be outsourced to far shore vendor, while projects that require extensive amount of interaction can be outsourced to near shore vendor. Taking for example the US companies can mix between Eastern Europe and far Asia in outsourcing for such purposes. This diversity in customer vendor selection can help limiting the risk of time and cost overruns and its threads.

Software development outsourcing risks exist and approaches to mitigate or avoid the risks has to be identified to allow maximum benefit out of it.

References:

Ahmed, R., (2006), ‘Software maintenance outsourcing: Issues and strategies’, Computers and Electrical Engineering 32 (2006) pp.449–453, [Online], Available from:
http://www.sciencedirect.com.ezproxy.liv.ac.uk/science?_ob=ArticleURL&_udi=B6V25-4JX3SG8-1&_user=822084&_coverDate=11%2F30%2F2006&_rdoc=1&_fmt=high&_orig=gateway&_origin=gateway&_sort=d&_docanchor=&view=c&_acct=C000044499&_version=1&_urlVersion=0&_userid=822084&md5=431650312cb5d14d819f6e45bcf84342&searchtype=a
(Accessed 19 April 2011)

Chou, A. & Chou, D., (2010), ‘Innovation outsourcing: Risks and quality issues’, Computer Standards & Interfaces 33 (2011), pp.350–356,  doi:10.1016/j.csi.2010.10.001, [Online], Available from:
http://www.sciencedirect.com.ezproxy.liv.ac.uk/science?_ob=ArticleURL&_udi=B6TYV-51DD93D-1&_user=822084&_coverDate=03%2F31%2F2011&_rdoc=1&_fmt=high&_orig=gateway&_origin=gateway&_sort=d&_docanchor=&view=c&_acct=C000044499&_version=1&_urlVersion=0&_userid=822084&md5=4b2237216897dca3c31ff791487c116d&searchtype=a
(Accessed 19 April 2011)
Dhar, S. , Balakrishnan, B., (2006), ‘Risks, Benefits, and Challenges in Global IT Outsourcing: Perspectives and Practices’ Journal of Global Information Management, vol. 14, issue 3, [Online], Available from:
http://khazanchi.ist.unomaha.edu/Teaching/ISQA4590-8596/Readings/Supplemental%20Readings/week%2012/Risks-Benfits%20and%20Challenges%20in%20Global%20Outsourcing.pdf
(Accessed 19 April 2011)


Gefen, D, Wyss, S, & Lichtenstein, Y., (2008), 'BUSINESS FAMILIARITY AS RISK MITIGATION IN SOFTWARE DEVELOPMENT OUTSOURCING CONTRACTS', MIS Quarterly, 32, 3, pp. 531-542, Computers & Applied Sciences Complete, [Online], Available from: http://web.ebscohost.com.ezproxy.liv.ac.uk/ehost/detail?sid=595b2d81-e922-4d9e-8aa9-0be5d68ecc12%40sessionmgr12&vid=1&hid=11&bdata=JnNpdGU9ZWhvc3QtbGl2ZSZzY29wZT1zaXRl#db=iih&AN=33422914
(Accessed 20 April 2011)

Gonzalez, R., Gasco, J. & Llopis, J., (2006), ‘Information systems offshore outsourcing: A descriptive analysis’ Industrial Management & Data Systems
Vol. 106 No. 9, 2006, pp. 1233-1248 doi: 10.1108/02635570610712555, [Online], Available from:
http://www.emeraldinsight.com.ezproxy.liv.ac.uk/journals.htm?articleid=1576181&show=abstract
(Accessed 19 April 2011)

Kikuchi, T. (2006), ‘Time Zones, Outsourcing and Patterns of International Trade’, Economics Bulletin, Vol. 6,No. 15 pp. 1-10, [Online], Available from:
http://www.accessecon.com/pubs/EB/2006/Volume6/EB-06F10018A.pdf
(Accessed 19 April 2011)


Kikuchi, T. & Long, N. (2009), ‘A Simple Model of Service Offshoring with Time Zone Differences’, [Online], Available from:
http://proj3.sinica.edu.tw/~econ/2010GTD/11/11-3.pdf
(Accessed 19 April 2011)


Rottman, J., (2006), ‘Successfully outsourcing embedded software development’ Computer , vol.39, no.1, pp. 55- 61, Jan. 2006
doi: 10.1109/MC.2006.33, [Online]. Available from:  http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1580383&isnumber=33375
(Accessed 19 April 2011)


Roy, S. and Sivakumar, K. (2011), Managing Intellectual Property in Global Outsourcing for Innovation Generation. Journal of Product Innovation Management, 28: 48–62. doi: 10.1111/j.1540-5885.2010.00780.x, [Online], Available from:
http://onlinelibrary.wiley.com.ezproxy.liv.ac.uk/doi/10.1111/j.1540-5885.2010.00780.x/abstract;jsessionid=6EB0639FD12E9C0E5709F34B2D471961.d02t02
(Accessed 19 April 2011)

Waymack, P., (2000), 'Outsourcing Opportunities', Health Management Technology, 21, 7, p. 44, Computers & Applied Sciences Complete, [Online], Available from: http://web.ebscohost.com.ezproxy.liv.ac.uk/ehost/detail?sid=f8d30193-18f9-49ef-9413-c3503b4830b5%40sessionmgr15&vid=1&hid=11&bdata=JnNpdGU9ZWhvc3QtbGl2ZSZzY29wZT1zaXRl#db=iih&AN=3256997
(Accessed 20 April 2011)

Measuring ROI

Prior to the financial crisis my organization never paid attention to projects cost versus benefit, our IT steering comity used to approve project based on business requirements, if a new application was requested by any business unit, we as IT department used to execute, assign the resources from our side and start working on it, even if we have other projects in hand. All of this changed, any project now needs to be financially justified before being approved.

My organization considers many factors before approving or rejecting a project, we first identify the return type, and in other words will this project reduce cost or increase revenue. The difference between both is that if the project reduces cost, we measure the amount of work needed to fulfill the new project, in addition the mount of work eliminated by this project and its cost. If the project is revenue driven, we basically calculate the expected revenue from implementing the project less the cost for that project and prioritize the project based on ROI figures. In addition to that, as a bank we have regulatory issues we have to fulfill, so any regulation from the central bank that requires a project we do it regardless of the cost.

Based on the business request, we verify if this request requires a change or a complete project to fulfill it, after this approval, we calculate the feasibility of the project; we weigh the benefits against cost. The cost we calculate is based on new equipment’s or software licenses, man-days for internal staff or consultants, rental for network lines, and within our department we prioritize it based on the availability of our team and cost on our department. We then present the outcome with the business unit that requested the change, and they have to justify the spending and ROI.

From my IT department side, all the projects whether IT internal or business projects, should fit into three categories, business enablement program, risk reduction program and service enhancement program, the first should be justified financially by the requesting department, the others benefits are calculated either by risk reduced (we consider this as a benefit and revenue), or offering better services to internal or external customers. For the service enhancement program projects, we calculate TCO for each system we have, which includes maintenance, training, software, hardware and administration cost, and any service improvement project has to reduce the TCO. For example, we introduced a project to virtualize all our windows based servers, the improvement was in easing manageability and monitoring of the systems, as well cost reduction was in software licenses and hardware equipment used, in addition to administration cost reduction as we reduced number of outsourced engineers we had.

References:

Gincel, R 2004, 'Measuring Success Through Metrics', InfoWorld, 26, 45, p. 51, Computers & Applied Sciences Complete, [Online], Available from:

http://web.ebscohost.com.ezproxy.liv.ac.uk/ehost/detail?sid=359c5975-db4c-4fad-b3ec-43e9a3bf552d%40sessionmgr15&vid=1&hid=13&bdata=JnNpdGU9ZWhvc3QtbGl2ZSZzY29wZT1zaXRl#db=iih&AN=15055911

(Accessed 10 April 2011)

Joch, A. (2006). Reassessing it project metrics. Hospitals & Health Networks, 5(2), 18, [Online], Available from: http://search.proquest.com.ezproxy.liv.ac.uk/docview/215308746/fulltextPDF?accountid=12117

(Accessed 10 April 2011)

Zizakovic, L. (2004), ‘ROI for your Software Project Basing your Return on Investment Analysis on Sound Financial Principles’, [Online], Available from: http://www.insidus.com/CalculatingROI.pdf

(Accessed 10 April 2011)

Outsourcing

Introduction

Since we established the bank, the management wanted to outsource all non-managerial positions within the IT department, this means all system administration area’s (Unix, Microsoft, storage, backup and restore), SAP Basis, service desk and operations, needs to be outsourced. As we the decision were taken that no in-house development at all. The driver behind this decision was to reduce cost on IT department and because most of the systems were new to the region, and there is limited number of locally hired resources for a system like SAP for example, which is the core banking application.

Our Experience

We faced a couple of issues, first of all the level of expertise that we used to get in the administration area are not as expected, the way we do it, is that we get resumes for the candidates from the vendors, and after interviews with them we either approve or reject the candidate. It happened twice that we choose someone who we believed can be trained by our team, because this is the best we could get, and after we train him, and he gets experience in our environment, the company replace him with a junior one. Although the contract states that they don’t have the right to replace the candidate without our approval, but it happened. Second issue was whenever the candidate had a problem with him employer, it gets reflected on his work and we as a customer suffer from that, this happened after the candidate somehow read the contract between the company and us as a client, and he started comparing what he is getting from his company, in return to what we pay his employer for his services.

In other area like IT operations and service desk, it was really effective, because the outsourced candidates had predefined tasks, we prepared for them the operation manuals and monitoring tools to help them get the proper feedback from our customers and how to fix it, and if they couldn’t, to whom they should report it.

The Contract

The Contract between the company and us states that they have to provide us with a replacement incase the candidate becomes not available due to sickness or he in on leave. It happened a couple of times that the company couldn’t provide us with a replacement, due to lack of resources on their side or provide us with un experienced candidate, we reported that to the company but nothing changed as they didn’t have the proper caliber. And raising this issue to court didn’t help a lot, because they company paid the penalty as per the contract, but we couldn’t find another company to provide us with the resources needed.

Conclusion

We failed to achieve the benefits of outsourcing in some of the area as we explained, and especially the cost saving, true that we saved in staff salaries and bonuses when we implemented the outsourcing model, but we lost the stability within our team, if we have hired a single administrator in each area we could have built and trained our in-house team, instead of loosing the candidate after we train and invest in him. There are hidden costs in outsourcing that should be considered which is not only tangible, risk of exposing our departments confidential information to outsourced staff which happened to be with not qualified vendor, whenever we had a candidate replacement we had to change all super users password and application user credentials.

References:

Ha, M 2005, 'IT Outsourcing Benefits, Difficulties Seen', National Underwriter / Property & Casualty Risk & Benefits Management, 109, 22, p. 23, Business Source Premier, EBSCOhost, [Online], Available from: http://web.ebscohost.com.ezproxy.liv.ac.uk/ehost/detail?sid=67123b8f-3e4a-4b1a-a9fd-5bfa485a431e%40sessionmgr12&vid=1&hid=14&bdata=JnNpdGU9ZWhvc3QtbGl2ZSZzY29wZT1zaXRl#db=buh&AN=17991877

(Accessed 9 April 2011)

Juras, P. (2008), ‘The hidden costs of outsourcing’. Journal of Corporate Accounting & Finance, 19: 7–15. doi: 10.1002/jcaf.20428, [Online], Available from:http://onlinelibrary.wiley.com.ezproxy.liv.ac.uk/doi/10.1002/jcaf.20428/abstract;jsessionid=DC68CEC8039D7419EAAA2E9B9F1FC9C3.d02t01

(Accessed 9 April 2011)

Mol, Michael J.. Outsourcing. Cambridge University Press, 2007. Cambridge Books Online. Cambridge University Press, http://dx.doi.org.ezproxy.liv.ac.uk/10.1017/CBO9780511621543 , [Online], Available from: http://ebooks.cambridge.org.ezproxy.liv.ac.uk/ebook.jsf?bid=CBO9780511621543

(Accessed 9 April 2011)