«VOLUM E 1 1, N UM B E R 1 I S SN 2 1 6 8 - 0 6 1 2 F L ASH DR I V E I S SN 1 9 4 1 - 9 5 8 9 ON L I N E T h e In s t it ut e f o r Bu s i n e s s an ...»
According to Feldman (2010), the practice of enterprise project management is finally getting broad respect, not just lip service. Seven out of 10 companies use formal project management methodologies, our new InformationWeek Analytics survey finds. Pay for project managers was on the rise last year, even as pay for most IT pros was flat. Sixty-one percent of the managers we surveyed see the Project Management Institute's project management professional - PMP - certification as important to their companies. Most companies have some project management methodology in place, and that's part of the problem - if you're not actively questioning your approach, looking for weak spots, and comparing it with other options, it'll creep along in whatever direction it's already headed.
According to Bataller (2011), while just 3% of respondents to our survey say a CRO is the primary owner of the IT risk management program within their companies, we think that within a few years, the role will be commonplace, especially in large enterprises. However, to bring everyone together, the CRO must be able to form an agile organization that can dodge and weave and evolve with the regulatory climate, attacker landscape, budgetary cycles, and industry dynamics. The CRO must have a vision compelling enough to silence the inevitable naysayers and gain cooperation from people with many different priorities.
The PMBOK Guide (2000) provides the most extensive body of knowledge and standards regarding project risk management. As defined within the guide, risk management represents the systematic process of identifying, analyzing and responding to potential project risk. The risk management process provides opportunity to maximize the probability and impact of positive project outcomes while minimizing the probability and consequences adverse outcomes. As further explained within the guide, project risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on a project objective.
Additionally, as suggested within the guide, it is important to recognize that a risk has a cause and, if it occurs, an impact.
According to information provided in the PMBOK Guide (2000), the major processes associated with risk
management include the following:
1. Risk Management Planning: the process by which a plan is developed as to how to approach and implement risk management activities for a project.
2. Risk Identification: the process by which risks that may potential impact the project are identified and characterized.
3. Qualitative Risk Analysis: the process by which a qualitative analysis of risks and conditions is conducted with the results being used to prioritize the effects of risks on project objectives.
4. Quantitative Risk Analysis: the process by which the probability and impact of risks are measured with results being used to estimate implications for project outcomes.
5. Risk Response Planning: the process by which procedures and techniques to enhance opportunities and to reduce threats to the project’s objectives are identified and/or developed.
6. Risk Monitoring and Control: the process by which residual risks are monitored while identifying new risks, executing risk reduction plans and evaluating their effectiveness through the project life cycle.
GCBF ♦ Vol. 11 ♦ No. 1 ♦ 2016 ♦ ISSN 1941-9589 ONLINE & ISSN 2168-0612 USB Flash Drive 469 Global Conference on Business and Finance Proceedings ♦ Volume 11 ♦ Number 1 As indicated within the report provided by RMRDPC (2002), the RMM is based on the assumption that the maturity of risk management processes within projects/organizations can be categorized into groups that range from those who have no formal process to those in which risk management is fully integrated into all aspects of the project. As clearly emphasized within the report, the expectations of RMRDPC in designing the model were such that it was not expected that all projects/organizations would fit neatly into these categories. However, as explained within the report, the RMMM levels were defined sufficiently different to accommodate the diversity found in most projects/organizations. The four levels of the RMMM are found
within the following table:
The Four Levels that identify the level of an organization’s Risk Management Maturity.
There are four things you can do about a risk (Turbit, 2013). The strategies are:
Avoid the risk. Do something to remove it. Use another supplier for example.
• Transfer the risk. Make someone else responsible. Perhaps a Vendor can be made responsible for • a particularly risky part of the project.
Mitigate the risk. Take actions to lessen the impact or chance of the risk occurring. If the risk relates • to availability of resources, draw up an agreement and get sign-off for the resource to be available.
Accept the risk. The risk might be so small the effort to do anything is not worth while.
• Finally, as further suggested by Hulett (2001), risk maturity is truly reflected in projects/organizations that are willing to share working risk management approaches and practices. Through the visible exchange of ideas, project risk management as a discipline is provided the opportunity to grow in the development, improvement and application of more effective risk management skills, tools, concepts and practices.
In the words of a fellow Chicagoan, never let a good crisis go to waste. A unique convergence of circumstances makes this the perfect time to bring IT and business units together under the flag of a riskoriented approach to security. Economic stress and cutthroat competition on a global scale mean every dollar you spend on security had better matter. Plus, the money is there. Thirty-five percent of the 563 respondents to our InformationWeek Analytics IT Risk Management Survey say their companies' IT risk management programs will get more funding in 2011 than they did last year (Bataller (2011).
GCBF ♦ Vol. 11 ♦ No. 1 ♦ 2016 ♦ ISSN 1941-9589 ONLINE & ISSN 2168-0612 USB Flash Drive 470 Global Conference on Business and Finance Proceedings ♦ Volume 11 ♦ Number 1 As was reflected in the preceding review, there is at present an extensive knowledge base on IS development. However, there is no evidence or documentation of efforts to study and investigate project risk management as it applies to IS development projects. This may be a consequence of the fact that both IS development and project risk management are relatively new and still emerging fields of study and practice. In spite of the sparseness of theoretical frameworks and discussions integrating the two disciplines as well as the lack of research investigating project risk management in IS development projects, the results of the literature review clearly provide documentation of the need for research in this area.
IS development projects can be expected to remain critical to complex modern organizations and, as the knowledge base and skills associated with IS development will certainly continue to expand at a rapid pace, it is critical to engage in efforts to study the nature of project risk management and the degree to which it occurs in IS development projects. The current information available on risk maturity in organizations appears to offer a strong basis for planning and developing research in this area. The risk maturity knowledge base could very well serve as a critical tool in aiding IS development project managers to establish effective and ongoing project risk management practices.
Achimuga, P, Babajide, A., Oluwaranti, A., Oluwagbemi, O., Gambo, I. (2010). Towards an Efficient Information Systems Development Process and Management: A Review of Challenges and Proposed Strategies. Journal of Software Engineering and Applications. Irvine: Oct 2010. Vol. 3, Iss. 10; pg. 983, 7 pgs Artto, K. A. (1997). Fifteen years of project risk management applications - Where are we going? K.
Kahkronen & K. Artto (Eds.), Managing risks in projects (pp. 3-14). London, United Kingdom: E & FN Spon.
Artto, K.A., & Hawk, D.L. (1999). Industry Models of Risk Management and their Future. Philadelphia, PA: PMI.
Artto, K. A., & Hawk, D. L. (October, 1999). Industry models of risk management and their future.
Philadelphia, PA: PMI. Bataller, E. (2011) Risk Avengers. InformationWeek. Manhasset: Jan 31, 2011., Issue. 1289; pg. 32, 6 pgs.
Birnbaum, J. Pervasive information systems. (1997). Communications of the ACM, 40, 40-43.
Cano, A., & Cruz, M. P. (1998). On the management of risks in construction projects. Project Management, 4(1), 54-61.
Carnegie Mellon Software Engineering Institute (2002). Survivable Systems Analysis Method. Retrieved July 02, 2002 from http://www.cert.org/archive/html/analysis-method.html Center for Technology in Government (1998). A Survey of System Development Methods (1998). Albany, NY: University at Albany, CTG Publication.
Clemente, C. (1998). State of the net:The new frontier. New York, NY: McGraw-Hill.
Davenport, T. H., & Prusak, L. (1998). Working knowledge: how organizations manage what they know.
Boston, MA: Harvard Business School Press.
Drori, O. (1997). From theory to practice or how not to fail in developing information systems. SIGSOFT Newsletter, ACM SEN (Software Engineering Notes), 22, 85-89.
GCBF ♦ Vol. 11 ♦ No. 1 ♦ 2016 ♦ ISSN 1941-9589 ONLINE & ISSN 2168-0612 USB Flash Drive 471 Global Conference on Business and Finance Proceedings ♦ Volume 11 ♦ Number 1 Drucker, P. (1999). Beyond the information revolution. Atlantic Monthly, 284(4), 47-57.
Feldman, J. (2010). The New Project Management. InformationWeek. Manhasset: Oct 18, 2010, Issue.
1283; p. 14.
Hillson, D.A. (1997). Towards a risk maturity model. Journal of Project and Business Risk Management, 1(1), 35-45.
Hoffman, J., & King, J. (1997). Project management ills costs businesses plenty. Computer World.
Retrieved July 10, 2002, from http://www.computerworld.com/managementtopics/management/project/story/0,10801,00.html Hulett, D.T. (2001). Key Characteristics of a Mature Risk Management Process (Fourth European Project Management Conference, June 6-7, 2001). London, UK: PMI Europe.
IEEE Standards Association. (2001). IEEE 1540-2001. IEEE standard for software life cycle processes Risk management. The Institute of Electrical and Electronics Engineers, Inc.
Innotas (2015). Enterprise Class Project Portfolio Management Software. Retrieved August 27, 2015, from http://solutions.innotas.com/project-portfolio-management-softwareppc?utm_campaign=Project_Management_General_Search&utm_source=bing&utm_medium=cpc&utm_ term=+project%20+management%20+software&utm_content=Project%20Management%20Software&k_ clickid=6a3d3b11-c16c-2309-4b6a-000052d06839 Intaver (2015). Project Risk Management and Schedule Risk Analysis. Retrieved August 27, 2015, from http://www.intaver.com Jutte, B. (2015). 10 Golden Rules of Project Risk Management. Retrieved August 28, 2015, from https://www.projectsmart.co.uk/10-golden-rules-of-project-risk-management.php Kanabar, V. (1997). Project risk management. Action, MA: Copley Custom Publishing Group.
Kharbanda, O. P., & Pinto, J. K. (1996). What made Gertie gallop? Lessons from project failures. New York, NY: Van Nostrand Reinhold.
Kharbanda, O. P., & Stallworth, E. A. (1983). How to learn from project disasters: True life stories with a moral for management. Hampshire, United Kingdom: Gower Publishing Company.
Laudon and Laudon (2014).Management Information Systems: Managing the Digital Firm. Pearson:
Upper Saddle River, New Jersey.
Liu, J., Chen, J., Klein, G., Jiang, J. (2009). The Negative Impact of Conflict on the Information System
Development Process, Product, and Project. The Journal of Computer Information Systems. Stillwater:
Summer 2009. Vol. 49, Iss. 4; pg. 98, 7 pgs.
McManus, S. M., & Grushka, M. J. (1999.). Risk driven project planning with critical risk paths (Proceedings fo the 30th Annual PMI 1999 Seminars and Symposium). Philadelphia, PA: PMI.
NUA, Ltd. (2002, February). How many online. Retrieved July 13, 02, from Scope Communications Group Web Site: http://nua.ie/surveys/how_many_online/world.html GCBF ♦ Vol. 11 ♦ No. 1 ♦ 2016 ♦ ISSN 1941-9589 ONLINE & ISSN 2168-0612 USB Flash Drive 472 Global Conference on Business and Finance Proceedings ♦ Volume 11 ♦ Number 1 Pinto, J. K. (1997). Twelve ways to get the least from yourself and your project. PM Network, 11(5), 29Processes, techniques and insights. London, United Project Management Institute (PMI) (2000). A guide to the Project Management Body of Knowledge. Newton Square, PA: Project Management Institute.
Rasegard, S. (1997). Science and society - the need of promoting interdisciplinary research. International Journal System Research and Information Science, 7, 189-211.
Risk Management Research and Development Program Collaboration (2002). Risk management maturity level development. (Provisional Draft). PMI. Retrieved July 10, 2002, from http://www.risksig.com/projects/report.htm Snyder, R. (2011). Risk Management Within Information Systems Development. Association for Global Business Annual Proceedings: Newport Beach, CA. November 17-19, 2011. ISBN: 1050-6292 Standish Group (1995). The Standish Group Report. Retrieved July 1, 2002 from http://www.scs.carleton.ca/~beau/PM/Standish-Report.html SAP (2015). Preserve and grow your business value – with our risk management software. Retrieved August 28, 2015 from http://www.sap.com/pc/analytics/governance-risk-compliance/software/riskmanagement/index.html The Standish Group. 2009. Standish chaos report. www.projectsmart.co.uk/docs/ chaos- report.pdf [Accessed on November 11, 2010].
Turbit, N. (2013) Basics of Managing Risks. Retrieved October 31, 2013 from http://www.projectperfect.com.au/info_risk_mgmt.php Ulfelder, S. (2001, June). Project management: The dirty half-dozen. Darwin. Retrieved July 10, 2002, from http://www.darwinmag.com/read/060101/dirty.html Walsham, G. (1993). Interpreting Information Systems in Organizations. Chichester, UK: John Wiley.
Wet, B. and Visser, J.K. (2013). An evaluation of software project management in South Africa.