• Introduction
• Risk and Risk identification as a first step toward risk management
• Ranking of commonly identified risk factors
• Risk identification – the sooner the better
• Lack of top management commitment – No. 1 risk factor
• The general model of commitment
• Desire (affective commitment)
• Perceived Cost (continuance commitment)
• Felt obligation (normative commitment)
• Possible signs and questions/statement to help identify lack of commitment
• Implications for future research
• Implications for practice
• Conclusion
• References

Introduction

It is a commonly accepted fact that failure among Information Systems (IS) projects is rampant and it is no surprise that avoidance of failure is a dominant theme in IS literature (Schmidt, Lyytinen, Keil, and Cule, P., 2001). One explanation for the high failure rate is that managers are not taking prudent measures to assess and manage the risks involved in these projects (Keil, Cule, Lyytinen and Schmidt, R., 1998). Proponents of risk management for IS projects have long been pointing to the importance of identifying and analyzing threats to project success in order to reduce the chances of failure (Boehm and Ross, 1989; Boehm, 1991).

However, the question of when is the right time to start this risk identification process in the Systems Development Life Cycle (SDLC) has escaped attention. Although, there has been a call for identifying potentially troublesome software components and early detection and correction of problems, based on quantitative metrics that can be systematically evaluated with little or no subjective measures from domain experts (Goseva-Popstojanova, Hassan, Guedem, Abdelmoez, Nassar, Ammar, and Mili, 2003), these analyses were mostly concerned with reliability-based risk, which takes into account the probability that the software product will fail in the operational environment and the adversity of that failure (Goseva-Popstojanova et. al., 2003). In other words, studies like those of Goseva-Popstojanova et. al., 2003 have done excellent work in terms of identifying the “technical” risk factors, but the IS risk assessment literature has pointed out that most IS project managers view “non-technical” risk factors as the most important and potentially deadly for the successful completion of their projects (Schmidt, et. al., 2001).

This paper addresses the opportune time for starting with the risk identification and mitigation process by listing some of the most common risk factors (Schmidt, et. al, 2001 and Keil, et. al. 1998) and by proposing that the best time to start with this process is very early in the SDLC. Later, the paper takes an initial step toward understanding one of the most important and commonly expressed risk factors “lack of management commitment,” in the light of Myer and Herscovitch’s, 2001, general model of commitment. A brief outline of the model is explained and an attempt is made to lay a foundation that will help in identifying lack of management commitment to IS projects using the model - early on in the SDLC. A possible scale or a check list is also proposed. The paper concludes with direction of future research and implications for practice.

Back to top

Risk and Risk identification as a first step toward risk management

Barki, Rivard, and Talbot, 1993 define software development risk as the product of Project Uncertainty and Magnitude of potential loss due to failure. Schmidt, et. al., 2001 define risk as a condition that can present a serious threat to successful completion of a software development project – based on March and Shapira’s, 1987, definition of management risk. Naturally, identification of project risk factors, outlining the most important ones, and finding out what countermeasures would be most suitable to mitigate these factors would be the course of action necessary as part of any risk management effort (Keil, et. al. 1998 and Schmidt, et. al, 2001). Schmidt, et. al., 2001 developed an updated list of risk factors based on an excellent Delphi based international study addressing the first step of identification of risk factors.

Back to top

Ranking of commonly identified risk factors

Schmidt, et. al’s, 2001 study revealed a ranked factor list based on a Delphi procedure. The investigation was carried out in three different countries with different socio-economic and cultural backgrounds, where panels of experienced IS project managers participated in identifying, and later, ranking the most common risk factors in the order of criticality. Although, the study revealed some 53 factors in all, about 29 of them were ranked by the different panels, and about 11 of them had composite ranks – ranked by all three panels. Table 1 lists the 11 factors and the composite (average) ranks assigned to them by the different panels.

Table 1. Composite Ranks of Risk Items (Schmidt et. al., 2001)

Back to top

Risk identification – the sooner the better

Risk assessment can be performed at various phases throughout the development process (Goseva-Popstojanova, 2003). IS literature on risk management has pointed out that risk identification is a crucial step toward risk management (Keil, et. al, 2001) but there seems to be a lack of a clear call to begin this risk identification process right in the beginning. Systems analysts plan for a project and perform detailed analyses as part of initial phases of the SDLC, like Planning and Analysis. Careful attention is paid to the “problem” at hand for the IS project but little or no effort is made to simultaneously, if not first, look for lurking risk factors in the initial environment of the IS project. A quick look at the 11 factors listed above, suggests that most, if not all, of them can be identified right in the beginning and this initial identification could lead to possible remedy or a change in the course of action to alleviate the potential negative impact due to these factors. It is widely accepted that it is easier and less costly to fix problems early in the SDLC (Goseva-Popstojanova, 2003).

If project managers and analysts at least have this mind set and awareness when they approach a particular IS project, and have the necessary tools and background knowledge to identify such risk factors, they will be more aware in the initial phases and in a much more advantageous situation later in the process. In other words, work on risk identification where managers and analysts should look for the presence of such risk factors, should begin before work on the actual project begins, or at the very least should be carried out simultaneously.

Such awareness and initial tackling of the risk factors would not only benefit managers later in the SDLC, but could also help in determining feasibility of the project itself. For example, if signs of “lack of management commitment” are present – which is often cited as the number one risk factor (Schmidt, et. al’s., 2001), then managers could really assess whether such a project is even worth considering, what else, then, are the true reasons for initiating such a project, or what if any measures could be taken to ensure that this would not adversely affect the project.

Back to top

Lack of top management commitment – No. 1 risk factor

Lack of top management commitment as a very important risk factor is a prominent theme in IS literature (Galliers, 1987; Lederer and Sethi, 1988; Grover, et. al., 1988; Ewusi-Mensah and Przasnyski, 1991; Newman and Sabherwal, 1996). Schmidt, et. al’s, 2001 study confirmed this when experienced IS project managers from three different countries cited “lack of top management commitment” as the number one risk factor and even termed it “fatal.”

As part of the effort to exhort IS Managers to look for risk factors early on in the SDLC and try to mitigate risks, this paper makes an initial attempt toward providing guidelines that may help IS project managers identify the presence of this risk factor. Meyer and Herscovitch’s, 2001, general model of commitment is used to provide a lens, with which managers can scrutinize the initial environment of the IS project. Although project specific determinants of commitment have been identified based on Staw and Ross’s 1987 taxonomy of project determinants viz. psychological determinants, social determinants, and structural determinants by Newman and Sabherwal, 1996 to shed light on escalation of commitment, such determinants as a group, may not be suitable for the purposes of the initial identification but may play a crucial role once the project has started.

Meyer and Herscovitch, 2001 argue “that commitment should have a 'core essence' regardless of the context in which it is studied.” Their model (discussed in the next section) provides such a “core essence.” This could play an important role in our use of the model in studying commitment to IS projects especially because of the very broad range of the types of projects undertaken and their idiosyncrasies and also because we are trying to identify lack of commitment in the very initial stages of the project, where the project is still perhaps a "cocoon" and may be very different in form than during the later stages of development. In other words, a general model like this could serve well when we consider commitment to IS projects early in the SDLC.

Back to top

The general model of commitment

Meyer and Herscovitch’s, 2001, general model of commitment; which was partly based on Meyer and Allen’s, 1991, three-component model (of affective commitment, continuance commitment, and normative commitment), presents the core essence of commitment as the “sense of being bound to a course of action of relevance to a particular target.” The model also reflects the different mind-sets that can characterize any commitment; viz. desire (affective), perceived cost (continuance), and felt obligation (normative) (Meyer and Herscovitch, 2001). They state that according to their model commitment can reflect varying degrees of all three of these mind-sets. They also outline the consequences of commitment as behavioral consequences and differentiate between “Focal target-relevant behavior (that is the focus of the commitment)” and “Discretionary target-relevant behavior (that can accompany the focal behavior).”

The following sections will attempt to look at top management commitment to IS projects under the three mind-sets of desire, perceived cost, and felt obligation.

Back to top

Desire (affective commitment)

Meyer and Herscovitch, 2001, state that individuals with strong affective commitment want to pursue a course of action and list some of the mechanisms involved in creating this desire as involvement, shared values, and identification. They go on to propose that any situational or personal variable that contributes to the likelihood that an individual will (a) become involved – intrinsically motivated, absorbed – in a course of action, (b) recognize the value-relevance of association with pursuit of a course of action and (c) derive his/her identity from working toward an objective, will contribute to the development of affective commitment (Meyer and Herscovitch, 2001).

Affective commitment is also thought of as perhaps being stronger than the other two mind-sets as “being bound out of desire,” “…might be a stronger ‘force’ than being bound out of obligation or need. (Meyer and Herscovitch, 2001)”

Determining presence of affective commitment or the lack there of could be the difference between a successful project and a complete disaster. Given the importance ascribed to commitment, it is important to determine the means by which project managers can ensure that they have the needed level of commitment from management (Sauer, 1993).

Taking Meyer and Herscovitch’s, 2001 three bases (listed above) for possible development of affective commitment as an outline, IS project managers could assess lack of affective commitment. First, IS project managers can look for any situational variables that point to a lack of intrinsic involvement or presence of apathy. Do the managers have a “don’t care much” attitude or are they exhibiting a strong sense of involvement and desire to pursue and undertake/finish this project successfully. Second, does the management “recognize the value-relevance” of associating with the project and have a set of “shared values” that exhibit belongingness? Third, do individual mangers show a sense of pride and derive his/her identity as being part of the project? If members of the management show signs of disassociation with the project and treat it is somebody else’s pet project then this could be a potential sign that they may be not as committed if the “champion” of the project leaves.

IS managers should not only be aware of these signs but may also actively investigate for their presence, when they are initially looking into a project. Questions like “How important is this project to the management?” “Does this project have both political and financial support?” “Are there more than one ‘champions’ of the project or this is more of a one person initiative (Ross and Staw, 1993)?” “How passionate are members of the management about this project?” - can provide much needed insight for the managers to generally assess presence or lack of commitment. A summary of possible questions based on different mind-sets is provided in Table 2.

Back to top

Perceived Cost (continuance commitment)

Meyer and Herscovitch, 2001 portray continuance commitment as “the perception that it would be costly to discontinue a course of action.” Continuance commitment is often shown to be present when a person makes investments, monetary or otherwise and there is a danger of loosing such investments if the activity is discontinued. Meyer and Allen also included lack of alternatives as a basis for the development of continuance commitment (Meyer and Herscovitch, 2001).

IS project managers can assess the lack of this base by either simply asking management or indirectly assessing the willingness of management to commit adequate resources to the project. Even information about any investments that have already been made toward a project could provide estimates of their continuance commitment. Another simple yet often overlooked factor could be the availability of financial and other resources that could be diverted to this project. In other words, IS project managers should bear in mind both the willingness and the capacity of management to provide adequate investments to a project.

One area that is also worth looking under this dimension could be how the project is being funded and what the Capital Budgeting process was. Was approval for this project granted (funding wise) because of ‘overselling’ or have the stakeholders done an honest assessment. IS projects that have been over sold may not carry the same level of continuance commitment later in the SDLC when ‘reality’ sets in. IS project managers could greatly benefit by having an awareness of how this project was ‘sold’ to the management.

Also, the presence of alternatives to this project and management's attitude toward these alternatives could provide clues as to how far they are willing to support this project. Lack of alternatives could mean stronger continuance commitment.

Another important consideration worth mentioning at this point is the possibility that managers may sometimes become too committed to certain IS projects (Keil and Mixon, 1994; Neumann, 1994; Orli, 1989; Rothfeder, 1998). In their excellent paper dealing in part with escalation of commitment, Newman and Sabherwal, 1996 point to escalation of commitment both as a danger to IS development in general and as sometimes being the difference between abandoning a project and completing it. In the context of continuance commitment, IS project managers can use this concept for dual purposes. On one hand, they can assess if top management is over committed to perhaps and existing system – and if signs of this phenomenon are present then management may not necessarily show the desired level of commitment to the new project, and on the other hand, they can look for warning signs within management that suggest possible escalation of commitment to the new project - perhaps suggesting reasons beyond those that should be present for successfully completing the project.

Back to top

Felt obligation (normative commitment)

“Normative commitment is characterized by the mind-set that one has an obligation to pursue a course of action of relevance to a target (Meyer and Herscovitch, 2001).”

Meyer and Allen, 1991 proposed that normative commitment develops when an individual (a) has internalized a set of norms concerning appropriate conduct, and/or (b) is the recipient of benefits and experiences a need to reciprocate (Meyer and Herscovitch, 2001). In other words, normative commitment is said to develop when individuals, through socialization, or being part of an organizational structure have come to accept a set of norms and feel committed to follow such norms or what is in general expected of them. They also feel a need to reciprocate when they are recipients of benefits as part of the normative commitment.

This mind-set of a normative form of commitment can be an important consideration when it comes to assessing the overall commitment. Although this may not be the most desirable type of mind-set IS project managers would be looking for, it could still provide a solid foundation on the part of management to see the project through. If members of the management feel a sense of obligation to the organization as a whole and if that sense of obligation translates into commitment for the project in question, then there is a good chance that project will have the needed level of commitment from management. Management’s perceptions of the importance of the project to the organization as a whole will also promote normative commitment.

Another factor to consider could be that if members of the management have already accrued some benefits because of the upcoming project in question, they may exhibit more commitment as a sense of obligation to perform.

Also, if stakeholders have supported a project explicitly and publicly (Newman and Sabherwal, 1996) they may exhibit stronger sense of obligation to the project. This by itself, may not be the best reason management would support an initiative but would still provide some level of commitment that may be beneficial to the project. Again, if IS project managers are aware of these phenomena they can be on the “look out” for potential lack of this form of commitment and although the presence of this factor may not be ‘fatal’ to the project, the early detection could surely enhance the chances of project success.

Back to top

Possible signs and questions/statements to help identify lack of commitment

Table 2 outlines some of the possible signs that IS project managers or analysts could look for, and some statements that could show/confirm these signs. Items in the third column have been in part adapted from an introductory scale (to measure the three types of commitment) provided by Meyer and Herscovitch, 2001. Accordingly, they can easily be modified to be framed as direct questions or can retain their structure to be used as a scale based questionnaire.

Although, the list below is by no means comprehensive and/or novel, looking at it in the initial phases of the SDLC should provide a unique perspective that may not be available later.

Table 2:

Commitment Mind-set Signs for lack of this type of commitment Questions/Statements that could help identify/confirm these signs Affective Commitment Management shows lower level of involvement/desire Apparent apathy toward the project Members try to disassociate themselves from the project There is only a single person (or a small group) who seems enthusiastic about the project and the rest seem to be ‘going along’ Successful completion of this IS project is as important to me as it is to the organization. I really want this project to succeed Is the ‘champion(s)’ of the project here to stay? What are the long term prospects that they will continue?   Continuance Commitment Management members show a disregard to the costs associated with not pursuing this project Members of management show unusual concern for the resources required Members keep mentioning alternatives Management members show unrealistically high expectations because of the type of funds that have been approved/planned for this project It could be costly for the organization if this project is not undertaken. I personally have a lot to loose if this project fails. Has there been an investment already made toward this project? Why this particular project and not something else? How ‘dear’ is their existing system to them? Is this a strategic project? Are they aware of the cost/benefit ratio of this project?   Normative Commitment Management members showing inadequate levels of personal responsibility Management members don’t necessarily seem to really promote or support this project explicitly. I owe it to this organization to do my best to achieve successful completion of this project I feel a real sense of obligation to this project.

Back to top

Implications for future research

This paper attempted to make a clear and unequivocal call to start the risk identification process very early in the SDLC and even went as far as saying that it could be carried out before any other steps are taken. Future research could definitely move toward empirically testing this concept. The paper also studied "Lack of management commitment" as one of the most cited risk factors and attempted to look at it through the lens of the 'general model of commitment' developed by Meyer and Herscovitch, 2001. This again was an initial attempt to tackle just one albeit the most important of the risk factors commonly identified. Future studies could work toward assessing the application of such a model to Commitment to IS projects. Such a model which is general, in a sense, could prove very useful, and studies to prove this fit empirically could be carried out with ease. Meyer and Herscovitch, 2001 have provided an initial scale as a starting point.

Further research is also needed to examine other risk factors from the point of view of early detection particularly during the very early stages of the SDLC as this paper suggests

Back to top

Implications for practice

Although the list of possible questions in Table 2 and the sections on the three mind-sets of affective commitment, continuance commitment, and normative commitment should provide a guideline for practicing IS project managers and analysts, the most important thing for them is to develop this mind-set and carry it with them when they are looking into possible projects – very early on in the SDLC.

As mentioned earlier, IS projects normally tend to have their own idiosyncrasies and it is difficult to come up with a comprehensive list, a panacea of some sort that will help solve all problems. However, if managers are aware of the fact that there could be potential problems with commitment, for example, and are actively looking for them early on, they could use this awareness and what ever conclusions they draw from it to better tackle the project and take appropriate measures to alleviate these risks.

Back to top

Conclusion

This paper attempted to make a clear call for starting with the risk identification process - toward risk management - very early in the SDLC. It stated that most, if not all, of the common risk factors identified in the literature can be tackled right in the beginning. It took one of those problems, “lack of management commitment” and showed that it could be very aptly viewed through the lens of "the general model of commitment" by Meyer and Herscovitch, 2001. The three commitment mind-sets of affective commitment, continuance commitment, and normative commitment can provide excellent basis upon which we can scrutinize presence or absence of management commitment to IS projects. It is hoped that an awareness of these phenomena will help both further research in IS and practice among IS professionals.

Back to top

References

Barki, H., Rivard, S., and Talbot, J. “Toward an assessment of software development risk,” Journal of Management Information Systems (10:2) Fall 1993, pp. 203-225.

Boehm, B., and Ross, R. “Theory W software project management: principles and examples,” IEEE Transactions on Software Engineering (15:7), July 1989, pp. 902-916

Boehm, B. “Software risk management: principles and practice,” IEEE Software (8:1), January 1991, pp. 32-41

Ewusi-Mensah, K. and Przasnyski, Z.H. “On Information Systems Project Abandonment: An Exploratory Study of Organizational Practices,” MIS Quarterly (15:1), March 1991, pp. 67-88.

Galliers, R.D. “Information Systems Planning in the United Kingdom and Australia: A Comparison of Current Practice,” in Oxford Surveys in Information Technology, Volume 4, P.I. Zorkoczy (ed.), 1987, pp. 223-255.

Goseva-Popstojanova, K., Hassan, A., Guedem, A., Abdelmoez, W., Nassar, D., Ammar, H., Mili, A. “Architectural-Level Risk Analysis Using UML,” IEEE Transactions on Software Engineering (29:10), October 2003, pp. 946-959.

Grover, V., Lederer, A.L., and Sabherwal, R. “Recognizing the Politics of MIS,” Information & Management (14:3), March 1988, pp. 145-156.

Keil, M. and Mixon, R. “Understanding Runaway IT Projects: Preliminary Results from a Program of Research Based on Escalation Theory,” in Proceedings of the Twenty Seventh Annual Hawaii International Conference on System Sciences, IEE Computer Scociety Press, J.F. Nunamaker, Jr. and r.H. Sprague, Jr.(eds), Kihei, HI, 1994, pp. 469-478

Keil, M., Cule, P., Lyytinen, K., and Schmidt, R. “A framework for identifying software projects risks,” Communications of the ACM (41:11), November 1998, pp. 76-83.

Lederer, A.L. and Sethi, V. “The Implementation of Information Systems Planning Methodologies,” MIS Quarterly (12:3), September 1988, pp. 445-462.

March, J., and Shapira, Z. “Managerial perspectives on risk and risk taking,” Management Science (33:11), November 1987, pp. 1404-1418.

Meyer, J.P., and Allen, N.J. “A three-component conceptualization of organizational commitment,” Human Resource Management Review (1), pp. 61-89.

Meyer, J.P. and Herscovitch, L. “Commitment in the workplace – toward a general model,” Human Resource Management Review (11), 2001, pp. 299-326.

Neumann, S. Strategic Information Systems: Competition Through Information Technologies, Macmillan College Publishing Company, Inc., New York, 1994.

Newman, M. and Sabherwal, R. “Determinants of Commitment to Information Systems Development: A Longitudinal Investigation,” MIS Quarterly (20:1), March 1996, pp. 23-54.

Orli, R.J. “Battling Project Escalation,” Computerworld (23:14), April 3, 1989, pp. 64-66.

Ross, J. and Staw, B.M. “Organizational Escalation and Exit: Lessons from the Shoreham Nuclear Plant,” Academy of Management Journal (36:4), 1993, pp. 701-732.

Rothfeder, J. “It’s Late, costly, Incompetent – But Try Firing a Computer System,” Business Week, November 7, 1988, pp. 164-165.

Sauer, C. “Understanding support – lessons from a case study,” Australian Journal of Information Systems (1:1), September 1993, pp. 63-74.

Schmidt, R., Lyytinen, K., Keil, M., and Cule, P. “Identifying software project risks: An international Delphi study,” Journal of Management Information Systems (17:4), Spring 2001, pp. 5-36.

Back to top