IT Service Management

Download PDF
7 downloads 44223 Views 460KB Size Report
Comment
cies and implementing the optimal ones to achieve best results for both client .... desk for responding in case of any service disruptions and ser- vice requests ...
IT Service Management A Typological Classification of Policies for Governance Veerendra Kumar Rai

Ashish Kumar Jha

Abhinay Puvvala

System Research Laboratory, Tata Research Development and Design Center, Pune, India e-mail: [email protected], [email protected], [email protected]

Abstract—Governance of production support engagements entails handling complex and volatile scenarios that occur in production support environment. It deals with managing numerous policies and implementing the optimal ones to achieve best results for both client and the vendor. Understanding these policies is critical to provide better governance of these increasingly large and complex projects. This paper presents a three layered typological classification of the strategies and policies commonly employed in a typical project. S uch a classification, as has been demonstrated in the paper, will be useful in planning and executing projects by making policy interventions to keep the projects on track easier. Keywords— Governance, IT Governance, IT Production Support, Agent Based Modeling, IT service management

I. INT RODUCT ION Policies, their classification and the impact thereof, have been a problem humans have grappled with since time immemo rial [1,2]. Although social science researchers were the pioneers in their attempts of classifying policies, other fields are catching up fast. Experience of sociologists in the field of policy classification informs us that the benefits provided by classification of policy instruments helps in understanding the implications of policy implementations better and improves the management of those policies [2,3]. The extension of this debate has become quite wide recently. Many other fields dealing with policies and strategies have begun to classify the policies to enable better understanding and usability of those policies. These fields range from the traditional policy analysis [4] to computer networking [5,6] and server management [7] in domain of information sciences. The strategic field of governance of IT projects has not seen enough research on the policies and their classification aspect. IT systems were traditionally designed to support operation and management within an organization [8] but its role has expanded immensely since then into a much wider context of engaging multiple businesses and leading them to their successes. In such situations IT project governance can benefit immensely by careful implementation of suited complex policies for the effective management of production support services. This makes the study of policies and their classification an area of considerable importance, which has not yet been done. This lacuna in literature is what our current paper aims to fill. In the current work we take a typology based approach to classify the policies or strategies of a typical production support engagement. The core tenant of the classification approach remains the same where members of each class are significantly similar to one another and significantly different from members of another class. The benefit that such classification provides us is the ability to predict the usability of a single policy based on the properties of the complete class. It is these benefits which

have made typological studies interesting in all fields of research. The growing complexity in IT service projects and competition amongst different service providers has made the IT services a domain striving for perfection. The perfectionist approach, however, is repeatedly tempered by the dynamic environmental factors like law of land, nature of contract, costs, quality of service, change in technology, etc. Strategic interventions in the middle of such projects have become more of a norm than exception. Projects not performing to expected metrics for even a short duration of time are no more acceptable. The policy interventions required in such projects makes the need for a framework for classification of polices and strategies even more acute. This paper takes an initial step in this direction by proposing a policy classification for IT services management policies. This enables an organized approach to deal with dynamic environment of IT services. An organized approach to handling policy interventions is an attempt to enable project managers to take the decision on relevant policy to be implemented for best and most cost effective solution. We test the impact of the class ification framework proposed by using an Agent Based approach. A model of IT services has been simulated and the framework has been used to suggest and see the impact of relevant policy intervention in the engagement. II. LIT ERAT URE REVIEW Policy has been defined by researchers in various fields of study in a multitude of ways. At a general level, policy is to influence the behavior of a system [9]. Policy classification allows us to find commonalities and get a better grasp of what could be achieved by their use. Academicians have carried out the exercise of policy classification in various areas. There has been a reasonably wide base of literature on policy classification in the fields of public policy and sociology. Policy classification is a common practice amongst public policy researchers. Different typologies, taxonomies of policies that fall in the domain of public policy have been discussed in [10]. This study also introduces the concept of morality based classification of public policies. Similarly, Lowi [11] has proposed a two dimensional schema to categorize public policies with dimensions indicating the likelihood of government applying its coercive powers (immediate or remote) and the target of its coercion (the individual or the environment of conduct). Spurred by the promise of Lowi’s [11] work, public policy domain has seen a host of such typologies created [12,13,14]. Although most of the extant literature on classifying and using policies to achieve objectives was traditionally in field of human governance [2], its usability in other modern fields like project management and IT service management (ITSM) has been felt over past couple of decades. One of the fields where

use of governance policies is critical to success is managing complex projects. Project management can be described as “application of relevant policies designed and targeted towards achieving maximum benefit at minimum cost from the project” [15]. Choice of the most optimal policies under various contexts is crucial for ensuring the optimal management of any project. Similar study on project management has classified Project Management Offices (PMOs) on the basis of approach they take towards handling projects which helps analyze the PMO based on the capability it may have [16]. Recent advances in research in managing IT projects have viewed performance measurements as the most effective tool to measure the success of project management policies [17]. The measurement metrics to quantify the performance of projects may vary from context of a project to another, but the success of those policy implementations can be established against the performance of teams in the project [17,18]. Management of any project is not an independent task of comparing its inputs to outputs. Rather a s ystemic view is required to understand how the policies interact with each other and what the implications of policies are in the context of the project. In terms of dynamic environments of IT projects the need for a systemic view is even more acute [19]. As specified above, managing an IT project, more specifically IT Service Management engagement comes with its own set of complexities. Barafort et al have elaborated on managing IT project and suggested a Tudor IT Process Assessment (TIPA) framework for innovative management of processes governed by Information Technology Infrastructure Library (ITIL) but the day to day management of IT projects goes a little deeper and requires different set of frameworks [20]. The dynamic world of IT with fast changing technologies and ubiquitous requirements puts tremendous strain on managing such projects [21]. In the context of our current work we would use the definition by ITIL, the premier body for defining the best practices framework for IT services management to refer to service management as “a set of specialized organizational capabilities for providing value to customers in the form of services” [22]. The IT service management is also referred to as Production support in many contexts. A Production support engagement typically includes ensuring the reliability and quality of the IT services being offered. The typical production support engagement is to ensure maximu m availability for the serviced software during the tenure of the engagement [22]. The primary and overriding objectives of IT production support services are to maintain service availability, enhance the application efficiency and possibly, reduce the cost of providing the support services. The task of converting these objectives into realities is dependent on the policy decisions made during the course of engagement. Classification of policy to better manage IT related projects has been done to some extent. Policy classification has also been done in the domain of network administration and management. Wies, in his two seminal papers [5,23], has proposed a framework to classify network administration policies on the basis of a 10 criteria along with a hierarchy to order the resultant categories from classification. However, such research works are far and few. Although the literature of project management in terms of policies and its implementations is somewhat developed, there have been questions on its applicability to non-traditional project management in industries like IT [24]. Mahring takes a policy view of governance of IT projects [25]. This study extends a

similar approach to IT service management projects. This approach will facilitate better understanding of the need for the class of policies required for intervention in dynamic IT service management environments to ensure intended objectives are met. Herring and Kaplan extended the control logic to adaptive control so that systems can adapt and survive in a changing environment and remain viable [26]. In this study, we propose a framework for classifying policies for IT service management with specific focus on production support engagements. Theoretically, the framework could be used to classify policies in any system. However, we limit our discussion in this paper to IT governance in production support engagements. III.

IT PRODUCT ION SUPPORT SYST EM

As per ITIL [22], IT production support system constitutes of various sub systems that are constantly interacting and interdependent. A typical IT Production support engagement may have up to 5 key service operation processes [22].  Event Management: The process of proactively monitoring and controlling events, alerts and warnings at IT infrastructure level.  Incident Management: Incident management concerns with restoring availability in service quickly. Incidents are the issues that cause or can cause disruption in service or degrade the service quality.  Problem Management: This process concerns itself with determining the root cause of the incidents. Root cause analysis is followed by either implementing a change to prevent future reoccurrences or updating Known Error Database (KeDb) with a workaround to allow quicker diagnosis and resolution if similar incidents occur again.  Request Fulfilment: The process of handling small and pre-approved changes is termed as request fulfilment.  Access Management: A basic processes of IT production support which is concerned with granting of rights to use a service. Any production support engagement can comprise of one or more of these processes. Input to all the above mentioned processes is described by an abstract unit of work called ‘ticket’. Ticket could be any one of incident, event, service request, problem, access request and change request. Naturally, outputs are expected to be resolved incidents, fulfilled requests, granted accesses, workarounds and resolved errors. To handle tickets, the IT production support system is structured into multiple functions with capabilities and resources necessary for their respective performance and outcomes . The structure includes Service desk for responding in case of any service disruptions and service requests, multiple layers of support for resolving of incidents and application management for implementing changes throughout application’s lifecycle [22]. Also IT production support system is surrounded by volatile/ever changing environment often influenced by the business requirements of the supported application. Although IT service management is mostly characterized by repetitive execution of standard set of procedures/activities, the ever changing business environment makes it necessary to balance between conflicting set of priorities. IV. CLASSIFICAT ION Smith, [10] while discussing the classification of public policies based on Morality factor, has discussed two basic approaches to classification– typology based and taxonomy based.

Typological approaches generally rely on grouping policies based on multiple characteristics, which are derived conceptually. These characteristics are not necessarily backed up with empirical evidence [27]. Such typologies generate useful and easily comprehendible heuristics to provide a basis for comparison and analysis. However, they are commonly criticized for their inability to produce sharp distinctions needed for further exploratory studies. On the contrary, taxonomical approaches are grounded on empirically observable and easily measurable dimensions [28]. Mostly found in biological sciences, this approach to classification, due to its empirical nature, could be done by cluster analysis . A. Policy Hierarchy In this paper, we propose a typology based classification of policies for IT service management. The classification proposed here has roots in systems thinking. Systems thinking attempts to understand systems in terms of interactions between the elements that compose the entirety of the system. Herring and Kaplan [29] have identified a class of software application as complex systems. By using Viable System Model proposed by Stafford Beer [30], they have revisited the control paradigm of software architecture. Their study proposes an adaptive control system approach, derived from viable system model, for software engineering. Our study adopts this adaptive control system view [31,32] to understand the IT production support system (Fig. 1).

Figure 1: Structure-Policy-Patterns-Events

To ensure service availability and service quality in a volatile service environment that characterizes IT service management, managers control the system’s behavior with policies. Volatility could be a result of the occurrence of exogenous events or adverse effects of past policy decisions. An example of volatility due to exogenous events in the IT production support system is sudden and unexpected influx of application users. Such an event may lead to higher volume of incidents. This volatility in the system manifests itself into systemic behavioral patterns. The system, running under a set of policies, could auto correct these behavioral patterns and bring itself back to the desired state or cause events that need policy interventions (Fig. 1). These patterns of behavior, when analyzed, could also act as alerts for impending events. Managers can anticipate based on these pat-

terns and react with policy interventions proactively. This explains the feedback between patterns of behavior and policies. In case patterns fail to convey or managers fail to intercept them early enough, events occur. Events affect the service availability and quality. To handle these events, managers are equipped with multiple policy interventions to achieve desired state(s). These policy interventions may or may not be supported by the system’s structure. Policy interventions in production support environment could range from something as simple as maintaining a fixed number of buffer resources change (often, known as the bench strength in IT outsourcing terminology) to something as complex as adding a new process (like problem management) to the existing structure of engagement. The onus is on the manager to implement a policy that stabilizes the system, minimizes the cost and does not adversely impact the system in a longer run. In the increasing order of complexity, we have defined three classes of policy interventions for the domain of IT service management. To reiterate, the classification conceptually bases itself on systems thinking. The basic premise of system dynamics, an integral approach of systems thinking, is that emergent behavior of a system is a manifestation of its structure. The proposed classification originates from the need to alter the system’s structure to influence the behavior. System’s structure includes feedbacks, delays, stocks (accumulations), flows and nonlinearities [33]. All these structural elements put together cause ‘Dynamic Complexity’- the counterintuitive behavior of complex systems behind policy resistance. Policy resistance is the tendency for interventions to be defeated by the response of the system to the intervention itself. The below defined policy classes allow us to assess the system’s response to various interventions a priori. Changing the levels of existing structural elements: Certain policy interventions can be made by merely altering the levels of elements that are already a part system’s structure. Forrester [34] describes the number of ‘levels’ as the number of accumulations in a system. An example of level is the accumulation of Incidents with the inflow being the occurrence rate of new service outages and outflow being the resolution rate. Policy interventions such as increasing the level of service desk automation, adding more resources to a team, increasing the number of buffer resources, changing the composition of Incident management team fall in this category. These set of policies are least complex. However, no correlation has been observed between policy complexity and cost to implement it. It is not necessary that implementation of a simpler policy is more cost effective than a complex one. Changing relationships/rules that govern existing structural elements: The policies that belong to this layer, from systems’ perspective, necessitate changing relationships between structural elements or altering rules that govern structural elements. In production support environment, governance rules comprise of assignment rules, preemption rules and escalation rules. Assignment rules define how to assign tickets to resources on the basis of priority, competency and technology tower. Preemption rules outline the conditions under which a resource can preempt the resolution process of the ticket he/she is currently assigned to and pick up another ticket. Escalation rules define under what conditions a ticket should be escalated to higher levels of support. The context, objectives and events have a bearing on the choice of governance rules. From systemic point of view, policies that fall in this category need not only be modifications of IF-THEN-ELSE rules that govern the system, but could also be

the ones that modify the dependence between structural elements. An example of IF-THEN-ELSE rules can be taken from the preemption rules. A ‘no preemption’ condition would mean that a resource would continue to stay attached to a ticket until it has been resolved. ‘Preemption based on ticket priority’ condition means that a ticket allotted to resource can be put back in the waiting queue for resolving a ticket with higher priority. Whereas, ‘Preemption based on time to SLA expiry’ condition would expect the resource to preempt his current ticket in case there is a ticket closer to SLA expiry is lying in the queue. A policy intervention here could be changing the preemption rule based on the scenario countered. An illustration of the above discussed example is presented in section 5.2. Adding/deleting structural elements to the system: Every now and then, managers are faced with events, which are impossible to handle with existing structural support. An event such as client realigning the engagement objectives to include cost reduction in incident management by a certain percentage over the next few months could fall in this category. Such requests to vendor are very common in IT production support engagements. Under such circumstances, managers may resort to including problem management process, in case it does not already exist. Adding problem management is a major policy decision and the impact of it could be profound. Implementing a policy decision of this magnitude too is very complex. Merging two levels of support, adding a new production support process, deploying new software agent for production support services are just few examples of policy decisions that belong to this layer of policies. B. Policy Radar Now that we have defined the three layers of policies, we attempt to develop a deeper understanding of these layers by analyzing their characteristics. As shown in figure 2, policy layers are scored on different dimensions. To understand the layers further, we have conducted multiple rounds of semi structured interviews with project managers, handling production support engagements, to compile a list of criteria/dimensions that characterize the policy layers . In the first round, carried out using open-ended questions, our objective was to validate our understanding of IT Service Management along with ratification of set of dimensions culled out of the literature. Our understanding of the domain is based out of experiential knowledge and case studies conducted on multiple ITSM engagements. The responses from each round of interviews enhanced our understanding of the domain and enriched the discussion for later rounds. We identified these 5 dimensions as a result of our extensive interactions with service delivery centers in our organization. These are based on our observations and we do not claim that this list of dimensions is exhaustive. The final list of dimensions and their respective scores is presented in Figure 2. In the previous section, the policy classification and hierarchy are primarily done on the basis of one such characteristic, the implementation complexity. Cost is a fairly straightforward dimension to analyze policies. When faced with an event, managers aim to stabilize the system at the same time minimize the associated cost implications. The dimension of implementation complexity is a composite measure of the managerial complexity involved in implementing a policy intervention, which includes the number of other processes that are impacted, time and effort needed to implement the change etc. The impact of some

policies is short term owing to their reversible and easily changeable nature, whereas some policy decisions not only take longer to implement but last longer. Number of resources impacted by a policy decision is another characteristic of policies that has been considered in this framework. Although some policies are cost effective, are relevant and do not have any long term adverse effects, yet they could not be considered as the client vendor relationship may not be mature enough. Layer 1 and Layer 2 policies are generally taken at lower rungs of managerial hierarchy, whereas, client’s consent is needed to implement Layer 3 policies owing to the magnitude of change associated with them. Policy interventions such as adding problem management process need the client to trust vendor’s capabilities. Trust grows as the relationship between client and vendor matures. Relationship maturity in IT outsourcing is a well-researched topic [35,36,37,38]. The underlying service provisioning model is an indicator of the level of relationship maturity between client and vendor. From the basic staff augmentation (body shop) mode and move to managed team (project management) to managed services (total outsourcing) models as client gains trust on the vendor [39,40].

Fig. 2: Policy radar map

The score of each policy layer, dimension wise, was also conceived in consultation with practitioners. Needless to say, the layer scores are approximate measures of central tendency, from the perception of practitioners rather than any individual policy figures. Layer 1 policies, more often than not, are easy to implement, and very few resources are impacted while doing so. Cost implications of layer 1 policies are not too high but not minimal either. These policies are often taken at lower rungs management hierarchy, which means that the client vendor relationship maturity need not be high for such decisions. Unlike easily reversible layer 2 policies, layer 1 policies’ impact tends to last longer. Layer 2 policies are often managerial decisions that, generally, reorient the way work is done. Hence, the cost associated in implementing layer 2 policies in production support governance is often low. As a consequence, the resources impacted due to layer 2 policies are often very high. Possibly due to the above mentioned attributes, layer 2 policies have shorter life. Project managers look at layer 2 policies as their first line of defense to any events the production support system throws. Governance policies, for example, are often altered first to tackle any volatility in the system. Layer 2 policies are controlled by lower levels of management hierarchy. Usually, team leads and project managers have the power to alter them when needed. Consequently, the relation between client and vendor need not be very mature to implement such policy decisions.

Owing to the magnitude of change as sociated layer 3 policies, it is natural for them to be costly, complex and have an impact on a number of resources. Also most of these decisions not only take longer period to implement but also last for a longer duration. The relationship maturity needs to be high for the client to trust vendor on handling such policies. V.

multi-layered framework is that “not all class of policies is feasible or recommended all the times”. Certain events require certain policy interventions to ensure that the engagement performance is not impacted. We illustrate the usefulness of this strategy to mitigate the impact of changes in the dynamic environment of IT production support services by developing a model system simulator [41].

ILLUST RAT ION

In the previous section we described a multi-layered framework for policy classification for the governance of IT production support services. The basic tenet of the application for the

Fig. 3 T he system architecture

Figure 3 shows the structure of the system developed for this purpose. The system has 5 major components. The first is the scenario database which stores the various scenarios and parameters that define those scenarios for an engagement. The second is the strategy database which stores the possible policy interventions that might be made. This database has the policies classified as explained above in strategy bundles. Both these databases are continually updated and continue to evolve. The other modules are the values module, which stores the current KPIs of the service engagement and the “To-Be” KPIs. In this system actual engagement settings and contexts are stored which constitute the databases and simulation runs are used to determine the implications of future actions from the strategy database. The policy intervention decision is made through the use of experiment module which uses the Agent Based Model (ABM) to check for various policy interventions possible in the given scenario to get the KPIs to the expected value. ABM allows for simulation of human systems to see the emergent phenomenon in an environment with defined rules and thus provides a mechanism to understand the complex system in a controlled fashion [42]. Table 1 describes the model in terms of the agents (column 1) which have certain attributes (column 2) and how these agents interact in the environment (column 3). The interactions explain which agents interact with which agent under the influence of contextual parameters to generate certain patterns and corresponding results.

T ABLE 1. AGENTS, ATTRIBUTES AND I NTERACTIONS Agent

Attributes

Inte ractions

Resources

Skill level, Shift Level, Competency Type, Cost etc.

Resource  Resource Resource  Incidents

Incidents

Priority, Effort required, Arrival T ime, SLA etc.

Resource  Incidents

As described above, the policies used in an engagement determines the environment within which the agents’ interactions take place. Each policy creates certain impact on the system which leads to unique outcome of the engagement. For generation of incidents, based on our analysis of various engagements data, we found that incidents are generated according to a Poisson distribution of a given mean which varies from one engagement to other. The incidents are distributed between the various priority levels and also between different technical towers. For resolution process, Incidents can be allotted to the resources based on various policies employed by the engagement manager. The resolution process is also governed by the pre-emption and escalation policies in place. The typical use of such systems is to check for requirements of any policy intervention due to the engagement moving off the expected course. KPIs (Metrics) are computed at periodic intervals and the project managers have access to them through the dashboard specifically tailored for the purpose. The system through its database of scenarios and events flags any possible

deviation in course of project due to presence of any unfavorable patterns. Also, in the event that the user through dashboard monitoring is aware of an unfavorable pattern but is not able to take effective policy decisions because of unknown root cause, the system does root cause analysis to factor out changes in environment or previous policy decisions responsible for the pattern. The system thereafter provides user with decision support to mitigate the pattern. Policies are implemented at three layers as mentioned above. To test the efficacy of the multilayered governance strategy, we take a typical production support service engagement. The engagement parameters , shown in Table 2, are used to set up its context and environment. Table 2 has 3 partitions. The first partition shows how tickets are distributed in different priority categories and different competencies. The next partition lays down the structure of the engagement which has 2 tiered support with 2 different competencies required with a mean time of 19 minutes required to resolve each incident. The last block shows the SLA compliance times within which the incidents must be resolved.

Percentage time spent on training (during competency development)

Let’s suppose, in the course of the engagement, the production support system counters a situation wherein mean effort to resolve tickets goes up from 19 minutes to 26 minutes due to deployment of a new module and the consequent arrival of more complex tickets. The rise in mean effort to resolve incidents impact SLA target of 95% say, for instance, and resource utilization. To handle this situation we invoke policy from layer 1. Layer 1 policies are least complex and they have least side-effects too. We increase the number of resources deployed for incident resolution. To implement this, the model runs the simulation multiple times by changing the number of resources. Simulation runs with this policy intervention show that with new configuration SLA targets can be met. Table 4 and 5 show the implications of this intervention. T ABLE 4. RESOURCE SETUP Pre-intervention

T ABLE 2. – CONTEXTUAL P ARAMETERS

Comp*1

Distribution of tickets Critical 15.00% High Medium 35.00% Low Competency 1 40.00% Competency 2 Structural Parameters Mean Effort Time 19 minutes Levels of Support 2 No. of Competencies SLA compliance Time (minutes) Critical 20 High Medium 40 Low

30.00% 20.00% 60.00%

Level1 Level2

2 1

1 2

T ABLE 3. LEVERS TO HANDLE THE EVENT Strategy - Process Automation Percentage of team resources used for Increment in process automation automation Strategy - Resource Management Available Resources (Competency, Shift, Support Level Wise) Mean interval between resource Percentage of resources on bench level reviews Maximum number of resources on Senior to junior employees ratio bench Minimum number of resources on On-site to off-site ratio bench Strategy - Competency Development Improvement in team competency Subject matter experts in team

Comp* 2

2 3 *Comp refers to Competency

T ABLE 5. SLA, RESOURCE UTILIZATION Parameter

A. Layer 1: Changing levels of existing structural elements For each engagement a sub-set of strategies relevant to that particular engagement are outlined and the management zeroes in on the most critical strategy as desired. Following is a sample sub-set of strategies for a sample engagement explained above Process automation  Resource management  Competency management  Knowledge management Each strategy can be managed or tweaked using a set of policies. These policies belong to one of the three layers described in section 4 above. Any change in metrics o contextual parameter is handled by deploying one of these policies. Table 3 shows some of the relevant policies for each of the sub-set of strategies.

Comp*1

2 2

Pre Event

2 30 50

Post-intervention

Comp* 2

SLA compliance Utilization

98.83% 65.30%

Post Event, Pre Intervention 94.45% 83.21%

Post Intervention 99.32% 72.47%

T ABLE 6. SLA, RESOURCE UTILIZATION Parameter Critical High Medium Low Utilization

SLA compliance

Pre Intervention 96.40% 97.20% 97.31% 97.43% 64.81%

Post Intervention 99.10% 98.27% 97.14% 95.72% 72.36%

B. Layer 2: Changing relationship/rules that govern existing structural elements In a case where the client desires to change the contractual agreement to include variable SLA non-compliance penalties on the basis of ticket priority, a policy intervention is required to ensure that the vendor does not have to bear heavy penalties. Such a situation requires handling by change of policy to cater to redesigned constraints. To implement the same, the following preemption rules are changed. Below are pre and post intervention preemption rules respectively.  No interruption. Once a ticket is assigned to a resource, he/she remains unavailable for further ticket allocation until the assigned ticket is solved.  Priority based interruption. Engaged resources are interrupted in the case of occurrence of a higher priority ticket. They release the existing ticket back into the queue after updating the work done on it and attempt to resolve the ticket with higher priority.

Table 6 shows the impact on SLA compliance and utilization pre and post preemption rule change. By changing the preemption rules, not only have the SLA compliances of higher priority tickets improved, but also resulted in higher resource utilization.

[3]

[4]

C. Layer 3: Adding/deleting structural elements to the system The third layer of governance involves dynamically handling events that involve addition or deletion of existing structural elements. In a case where the vendor, pre intervention, was only responsible for incident management function but later was given the opportunity to handle the problem management too. An event of this kind demands addition of new structural components that may include resources, software agents etc. The set of policy that can handle such an event belong to layer 3 where they add an additional structural element of problem management team with 4 resources to cater to the change. The system suggests the policy but also the implication of such a policy intervention as shown in table 7.

[5]

[6]

[7]

[8]

[9]

T ABLE 7. SLA, RESOURCE UTILIZATION Parameter

Pre Intervention

SLA compliance Problems Solved Incident Management Utilization Problem Management

VI.

98.46% --------75.24%

Post Intervention 99.910% 108 69.97%

---------

64.23%

CONCLUSION

Although classification as a tool to better understand and implement policies in complex environments started as a research area in sociology and public policy disciplines, it has now become a topic of interest in all modern sciences. Also, a universally agreed upon classification of policies may not be easy to achieve, but various attempts at classifying in various dimensions is still a problem to be worked on. It provides greater control and understanding of the complete environment. Our current work, presented in this paper, is one such attempt at classification of policies in the complex world of governance of IT production support services. This work opens the domain of policy classification in hitherto unexplored field and helps understand the implication of good classification on managing complex IT projects and policy interventions. We have presented a typological classification of the policies for IT project management based on their relative positions on a five dimen sional framework. This is one of the many possible approaches for classification. The work presented in our paper is an exploratory approach where we have attempted to present the classification and its usability in better governance through an Agent Based Model. The work can be taken further to improve upon the classification and have it validated through empirical analysis. This will lead to a more robust study by presenting a taxonomy based classification of the IT governance policies.

[10] [11] [12] [13] [14] [15]

[16]

[17]

[18] [19] [20]

[21]

[22] [23]

[24]

[25] [26]

REFERENCES [1] [2]

Vedung, E. (1998). Policy instruments: typologies and theories. Carrots, sticks, and sermons: Policy instruments and their evaluation, 21-58. Hugh Heclo, H. (1972). Review article: Policy analysis. British journal of political science, 2(01), 83-108.

[27] [28]

Greenberg, G. D., Miller, J. A., Mohr, L. B., & Vladeck, B. C. (1977). Developing public policy theory: Perspectives from empirical research. The American Political Science Review, 1532-1543. Ma, Q. (2013, November). Study of Optimizing Pension Mechanism Improvement Measures Based on Fuzzy Evaluation Model. In 2nd International Conference on Management Science and Industrial Engineering (MSIE 2013). Atlantis Press. Wies, R. (1995). Using a Classification of Management Policies for Policy Specification and Policy T ransformation. Proceedings of the IFIP/IEEE International Symposium on Integrated Network Management. Santa Barbara. Wies, R. (1995). Using a classification of management policies for policy specification and policy transformation. In Integrated Network Management IV ( pp. 44-56). Springer US. Mansor, A. A., Wan Kadir, W. M. N., Elias, H., & Elsawi, A. (2014). Policy Overlap Analysis to Avoid Policy Conflict in Policy-based Management Systems. International Journal of Innovative Computing, 4(1). Dubois, E. (2014, January). Information Systems for the Governance of Compliant Service Systems. In Advanced Information Systems Engineering (pp. 1-11). Springer International Publishing. Lindblom, C. E., & Woodhouse, E. J. (1968). The policy-making process. Englewood Cliffs, NJ: Prentice-Hall. Smith, K. B. (2002). Typologies, taxonomies, and the benefits of policy classification. Policy St udies Journal, 30(3), 379-395. Lowi, T . J. (1972). Four systems of policy, politics and choice. Public Administration Review, 33(4). Edelman, M. J. (1985). The symbolic uses of politics. Illinois: University of Illinois Press. McCool, D. C. (1995). Public policy theories, models, and concepts: An anthology. NJ: Prentice Hall. Steinberger, P. J. (1980). T ypologies of public policy: Meaning construction and the policy process. Social Science Quarterly, 185-197. Archer, N. P., & Ghasemzadeh, F. (1999). An integrated framework for project portfolio selection. International Journal of Project Management, 17(4), 207-216. Desouza, K. C., & Evaristo, J. R. (2006). Project management offices: a case of knowledge-based archetypes. International Journal of Information Management, 26(5), 414-423 De Oliveira Lacerda, R. T ., Ensslin, L., & Ensslin, S. R. (2011). A performance measurement view of IT project management. International Journal of Productivity and Performance Management, 60(2), 132-151. De Wit, A. (1988). Measurement of project success. International journal of project management, 6(3), 164-170. Kerzner, H. R. (2013). Project management: a systems approach to planning, scheduling, and controlling. John Wiley & Sons. Barafort, B., Rousseau, A., & Dubois, E. (2014). How to Design an Innovative Framework for Process Improvement? T he T IPA for ITIL Case. In Systems, Software and Services Process Improvement (pp. 4859). Springer Berlin Heidelberg. Sauer, C., & Reich, B. H. (2009). Rethinking IT project management: Evidence of a new mindset and its implications. International Journal of Project Management, 27(2), 182-193. Cannon, D., Wheeldon, D. and Sharon, T .( 2007). ITIL.[4]. Service operation. TSO (T he Stationery Office). Wies, R. (1994). Policy Definition and Classification: Aspects, Criteria, and Examples. Proceeding of the IFIP/IEEE International Workshop on Distributed Systems: Operations & Management. Toulouse, France. Carden, L., & Egan, T . (2008). Does our literature support sectors newer to project management? The search for quality publications relevant to nontraditional industries. Project Management Journal, 39(3), 6-27. Mähring, M. (2002). IT project governance. EFI at SSE. Herring C. and Kaplan S. (2000). Viable Systems: T he control paradigm for software architecture revisited. IEEE Computer Society, pp. 97 Weber, M. (1949). The Methodology of the Social Sciences. Glencoe, IL: T he Free Press. Bailey, K. D. (1994). T ypologies and taxonomies: An Introduction to Classification Techniques. Thousand Oaks, CA: Sage.

[29] Herring, C., & Kaplan, S. (2000). Viable systems: the control paradigm for software architecture revisited. In Software Engineering Conference, 2000. Proceedings. 2000 Australian (pp. 97-105). IEEE [30] Beer, S. (1984). The viable system model: its provenance, development, methodology and pathology. Journal of the operational research society, 7-25. [31] Rai, V. K. (2013, October). Systems Oriented Approach to Production Support-A Viable Framework. In Systems, Man, and Cybernetics (SMC), 2013 IEEE International Conference on (pp. 4427-4432). IEEE. [32] Rai, V. K., & Mehta, S. (2014). U.S. Patent Application 14/282,618. [33] Sterman, J. D. (2001). System dynamics modeling. California management review, 43(4), 8-25. [34] Forrester, J. W. (1968). Industrial dynamics-after the first decade. Management Science, 14(7), 398-415. [35] Gottschalk, P., & Solli-Sæther, H. (2006). Maturity model for IT outsourcing relationships. Industrial Management & Data Systems, 106(2), 200-212. [36] Oza, N. V., Hall, T ., Rainer, A., & Grey, S. (2006). Trust in software outsourcing relationships: An empirical investigation of Indian software companies. Information and Software Technology, 48(5), 345-354.

[37] Sabherwal, R. (1999). T he role of trust in outsourced IS development projects. Communications of the ACM, 42(2), 80-86. [38] Webb, L., & Laborde, J. (2005). Crafting a successful outsourcing vendor/client relationship. Business Process Management Journal, 437443. [39] Dibbern, J., Goles, T ., Hirschheim, R., & Jayatilaka, B. (2004). Information systems outsourcing: a survey and analysis of the literature. ACM SIGMIS Database, 35(4), 6-102. [40] Rai, V. K., Mehta, S., & Puvvala, A. (2014). Strategy Design for Service Engagement Model T ransformation. In Proceedings of the 25th Australasian Conference on Information Systems (ACIS 2014). [41] Rai, V. K., Mehta, S., Chandak, P., Jha, A. K., & Puvvala, A. (2014). U.S. Patent Application 14/513,626. [42] Borshchev, A., & Filippov, A. (2004). From system dynamics and discrete event to practical agent based modeling: reasons, techniques, tools. In Proceedings of the 22nd international conference of the system dynamics society