June 2014 Download this article as a PDFAbstract

A firm’s dependency on the information technology (IT) function is increasingly central to its ability to innovate. The IT function must balance this need for change with sustaining consistent, highly reliable operation of all existing services. A firm’s ability to rapidly change IT is impeded by its legacy portfolio of applications and infrastructure because changes need to be very carefully managed and understood in order to avoid unintended consequences leading to system failure and process breakdown. The change imperative for IT is urgent and often determines how IT is valued by the rest of the firm.

Improving the IT function’s agility requires improvement in IT capabilities, which can be categorized into three broad classes: technology, process, and competency. This article identifies the critical success factors for creating sustainable change for each of these three capability classes. It draws on the practical experience of the authors and leverages appropriate standards that provide grounding for change within the IT function of the firm, along with the roles and tasks that will be involved in this change agency. The article is of primary benefit for IT executives seeking to sustain an ongoing, systematic transformation of the IT function to enable IT entrepreneurship and agility.

Introduction

As firms become increasingly dependent on the capabilities of their IT function, their appetite for change becomes dependent on their ability to accelerate maturity in the IT function. Yet, most IT functions have an inherent inability to mature, which impedes a firm's ability to innovate due to the following factors, as we described in an earlier article in this series (Renaud et al., 2013):

  1. The IT function must manage a large and growing collection of aging applications, which are typically tightly interconnected and poorly documented, and the firm may have little knowledge of their overall workings. This common state of affairs is termed “legacy debt”. These applications have been running for such a long time that, although many are considered integral to the firm’s survival, the insight to fix their significant and accrued problems has been lost.
  2. Changing these applications engenders a level of risk that is hard to mitigate without extraordinary measures. Therefore, even necessary incremental changes are made infrequently and without a holistic expectation of how the application will react. Applications typically will degrade over time due to poor documentation and the loss of organizational knowledge about their inner workings and the extent of their external collaborations. This degradation is heightened if the application has been supported in a minimal maintenance context for an extended period of time. As a result, the technical and competency capabilities to properly maintain them are usually lost such that changes often incur unpredictable and unintended consequences.  These applications are usually characterized as “brittle”. Worse, this legacy debt is compounded by years of “workarounds” done to accommodate the inadequacies of ancient applications and often organizational knowledge of these workarounds (e.g., fixed limits that are now too small to support the firm’s needs, idiosyncratic behaviour that perverts the processes that rely on these applications) is also lost due to inevitable churn in personnel, obsolete development tools, etc.
  3. The IT function’s budget has been constrained by supporting this legacy environment, despite mounting pressure to support new initiatives. There is little tolerance from the business to invest in fixing the aging environment (i.e., the applications and infrastructure) because the pressure to innovate outweighs the effort, cost, and time required to remediate. As a result, the amount of legacy debt compounds every year.

This previous article defined how these recurring shortcomings could be overcome by showing how to incrementally improve an organization’s execution maturity through a set of capability building blocks, whose introduction would be carefully managed by a set of measurable processes that respected the vital interrelationship between the three fundamental capability classes (shown in Figure 1). The previous article provided the background for manageable change by:

  1. Depicting how maturity improvement in capability classes can be coordinated and managed
  2. Exploring the relationship of these three capability classes, as shown in Figure 1
  3. Providing guidelines for leveraging capabilities to sustain change

Figure 1

Figure 1. Relationships between IT capability improvement entities

This article examines the critical success factors for managing the maturity improvement of each of these three capability classes in greater depth. We will also make the case that there must be a systematic and holistic approach to improving capabilities with an integrated strategy in mind. We will start with a review of each of the three capability classes and then proceed to explore the requisite success factors in improving each class to address the following pain points:

  1. The three capability classes that enable advancements in IT maturity are not well defined nor uniformly applied in an IT organization.
  2. The supporting relationships between these classes are not understood or are ignored.
  3. There is little incentive to share innovation beyond a specific project context, and technical capabilities are introduced without sufficient process and competency underpinnings.
  4. The result for IT executives can be summarized as lost opportunities, wasted time and resources, and perhaps worst of all, the perception that the IT function is unresponsive to the needs of the business. Achieving an IT function that is continuously aligned to the needs of the firm requires a significant shift in the mindset of most IT staff in order to restore responsiveness.

This article will establish that IT capability improvement is not only essential for the IT organization’s relevance to the firm, but is achievable through the deliberate incremental introduction of defined technical, skill, and process capabilities. We will show how the more advanced capabilities often comprise several building blocks from these three classes. We will also make it clear that the path to IT maturity is a committed and constant journey because market forces necessitate changes to how a firm will stay relevant to its customers. As a result, the unique process steps for incremental improvement for each capability class will be discussed in detail. Finally, we will introduce how sustainability will optimally thrive if there is an enabling enterprise architecture group that embraces its role as a facilitator of strategic, business aligned change.

Capability Improvement Is Holistic as Well as Incremental

Sustainable IT entrepreneurship requires a deliberate, collaborative effort to advance technology, process, and competency capabilities in concert with each other because most capabilities have dependencies. For example, introducing a new technology capability, such as a storage array, will require some skill set improvement combined with an augmentation of some processes to enable the intended impact and reach of the new technology. Although this dependency may appear obvious in the abstract sense, in reality, most IT functions will introduce a new technical tool with little training or support to scale it out to the firm because they are under massive pressure to introduce and evolve technology with little regard for the importance of operational efficiency. Consequently, the competencies and process required to ensure the tool would be properly run in production are rarely made.

An example would be the introduction of comprehensive end-to-end performance monitoring for applications in a business unit. This introduction requires the integration of several technical tools so that monitoring data can be used by stakeholders. It also requires processes and education to specify how and when the tools should be run or turned off, and how data should be collected and archived. Without this understanding, the real benefits of such a complex capability cannot be achieved and the investment in the new technology is largely wasted.

Technology Capabilities

New technology capabilities are introduced by lead projects that are either "shadow IT" projects (Dyche, 2012), which are projects led by a business function without a direct engagement of the IT function, or are “official IT” projects involving collaboration between the IT and a business function. For example, in chaotic firms, business unit leaders lease cloud equipment and deploy applications in what they perceive to be an expeditious manner but without engaging with the IT function. In most of these cases, the applications will ultimately incur unexpected performance, security, and reliability problems shortly after deployment. In mature IT functions, these projects typically follow a standardized new technology introduction process that assures that all operational and support units within the IT function are prepared for the new technology. In the authors’ experience, this level of maturity is rare for the reasons mentioned in the introduction.

Existing technology capabilities are typically improved by exploitative projects, which are typically led by an IT architecture group within the IT function. This group sets standards for technology capabilities to control complexity, lower cost of support, lower cost of operations, and facilitate and accelerate maintenance and repair activities. The process by which the evolution of technology capabilities is managed must be flexible and responsive to the needs of the business.

Without a respected architecture group, technology investment remains arbitrary, with no guiding portfolio discipline. This lack of discipline accelerates technological obsolescence, which increases legacy debt, which in turn increases the tendency of businesses to embrace shadow IT to work around a stagnant IT function. We will explore the IT architecture group’s relevance issues later in this article, when we address the need for sustainable technology change. In mature IT functions, these issues fall under the scope of the IT product management process identified by Renaud and Bot (2012a).

Process Capabilities

Process capabilities in IT can be managed via the Software Engineering Institute's (SEI) five-level capability maturity model (Paulk et al., 1993) along with some guidance from the standards in service design, operations, and strategy produced by the Information Technology Infrastructure Library (ITIL). The capability maturity model defines five levels of maturity (initial/ad hoc, managed, defined, predictable, and optimizing), and the highest level reflects the attainment of self-optimizing processes, which are inherently adaptable to the changing needs of the IT function.

In the authors’ experiences, these levels cannot be achieved without sufficient skills or supporting technology capabilities to make the IT processes run cost effectively. Augmenting processes without corresponding skills and tooling to underpin process improvements inevitably leads to a waste of resources.

Many processes within the IT function in a large firm will typically have more than one instance of the process. For example, an instance of the change management process will typically exist at each data centre location. In general, a process can have many instances at different levels of maturity. For example, change management in the London data centre might be more mature as a process than the instance the Hong Kong data centre. A critical success factor for maturity assessment is rating all instances of a process, not just the best one. If this comprehensive approach is not applied (and typically it is not), then the justification for funding to scale out the maturity will not be supported.

Competency Capabilities

Competency capabilities pertain to skills and competency management. Skills are possessed by people and competencies are possessed by teams. We will use the term “competency capabilities” instead of “people-related capabilities” throughout this article because it is more frequently used. Most IT organizations have well-defined competency requirements for roles, and the better ones explicitly manage skill levels for those competencies. Even the worst-run IT functions recognize the value of IT certifications and define vendor skill-certification requirements as part of the job descriptions for many roles. Improving competency capabilities has a direct impact on the agility and responsiveness of an IT function because it develops the processes to promote and sustain the growth of a learning organization (Senge, 2006). Increased competency also promotes an awareness among IT professionals that the firm is investing in its people and, consequently, that they need to take ownership for their own learning to increase the success of the organization.

The "people capability maturity model" developed by the Software Engineering Institute provides a framework for assessing and improving people/competency capabilities that can be generalized for application in an IT function (Curtis et al., 1995). This model underpins the capability model developed in The Open Group Architecture Framework (TOGAF) (The Open Group, 2011) and relates the use of competency capabilities to the process areas where they are applied. Individual knowledge and skills are integrated at a team level to form competencies.

However, a lack of investment in competency leads to poor technology implementation and usage, and decreasing morale. It also furthers the idea that the IT function is out of touch with business needs. This lack of investment acts as a vicious spiral: poor morale causes the best talent to leave and, as turnover increases, so does the knowledge loss, the legacy debt, and the perception that the IT function is a hindrance. In turn, this perception drives the urge to create shadow IT projects, thereby increasing legacy debt and further constraining agility and investment resources to fix these increasing problems.

Sustainable Technology Change

Given that the IT function’s raison d’être is to manage technology, it is "mission critical" to manage technology change effectively. Sustainable, continuous capability improvement is the key to maintaining the responsiveness of the IT function as the pace of change accelerates. However, due to the high volume of technology changes, the IT function will be unprepared for change without sustainable IT governance that is rooted in capability improvement to guide determined and purposeful change.

The critical success factors for sustainable technology capability change are:

  1. Successful integration of new technology capabilities with existing technology capabilities and the decommissioning of legacy capabilities that are no longer useful
  2. Introduction of new competency capabilities (e.g., expertise in the new technology) as well as new or changed process capabilities to manage the new technology
  3. Sufficient critical mass of new competencies to ensure that there are enough people who can both perform the work and teach the skills required to others who will use different instances of the new technology. This critical mass of skill base is necessary to implement operating processes that can scale-out to coincide with the introduction of the new technology capability.
  4.  Objective assessments of what technologies need to be retired and when they can be decommissioned. This aspect of technology change is essential to reducing compounded operational cost but is often skipped in practice because of the risk associated with unknown interdependencies within legacy environments. Mapping interdependencies in turn requires additional technology and competency capabilities.

The Practice of Enterprise Architecture Is Essential for Sustainable Change

Successful integration of new technology capabilities requires an enterprise-wide architectural perspective. Enterprise IT architecture was first formulated by Zachman (1987), who introduced a disciplined approach to the management of information systems to reduce cost and to enable the success of the firm. Zachman established that a holistic approach to systems architecture was necessary and that a framework for enterprise architecture should explicitly consider the aspects of data, function, network, people, time, and motivation in each of the dimensions of scope, business, system, technology, and detailed representations.

In a mature IT function, this holistic approach is commonly accepted as an enterprise architecture practice (EAP) that consistently guides the choice of new technical capabilities. EAP encourages the use of standards, guides the evaluation of a technology’s business relevance, and, if properly developed, encourages business-driven sustainable improvement by enforcing an enterprise architecture as a reference model for all applications and infrastructure.

Codifying the guidelines and principles for an enterprise reference architecture definition is essential for the successful inter-operation of varied technologies. However, as two of the authors discovered at Wachovia Investment Bank, defining a particular reference architecture is not a sufficient condition for sustainable technical change. When implementing enterprise reference architectures, such as a service-oriented architecture (SOA), many IT functions make the mistake of assigning less-talented personnel to the role of the advisory architecture teams because the best people are always in use by mission-critical projects. These firms do not deliberately invest in the skills needed for enterprise architecture definition, which creates a self-fulfilling prophesy of poor expectations or a dependency on outside system integrators who supply architectural guidance without the firm’s larger interests in mind. To compound matters, centralized architecture teams rarely interact with development or implementation teams other than through the role of an approval hurdle when new technologies are being introduced, or as “judge and jury” when conducting post mortems of project disasters. In effect, these firms have failed to properly integrate technology with competency capabilities and, as a result, technology capabilities fall short of their potential.

Role of Capabilities in Enterprise Architecture

At Wachovia, the authors found that enterprise architecture teams have significantly greater impact when they act as a proactive and helpful guide, engaging with implementation teams to help find a priori solutions to problems instead of being posterior critics of solutions proposed by those teams. We found that this approach increased the velocity of effective use of new technology by a factor of four.

As stated in the previous section, there are reasons most organizations do not take the enterprise architecture teams seriously and why behaviour is not proactive. Proactive help accelerates the diffusion of new technology throughout the firm as well as accelerating the adoption of new technology in any given part of the firm. Through the proactive use of capability change agents, change becomes part of the culture, where alignment is expected and adaptation is celebrated and rewarded for its contribution to the firm. These supporting acts of teaching, recognizing, and rewarding are essential to overcome the typical inertia associated with IT change arising from legitimate fears of risk and complexity.

Figure 2 shows a process flow whereby new technology is introduced in an incremental, codified method that both introduces change while managing its proliferation. The enterprise architecture function is perfectly suited to facilitate this process, because its practitioners:

  • have an enterprise view of skill gaps and potential pilot opportunities
  • can codify the evaluation process so that it is repeatable
  • can invest in the required impact and success analysis once rollout begins
  • have enterprise-level clout with vendors to orchestrate training

All of these attributes support the technical capability-improvement process in Figure 2, which elaborates the improvement process for IT technology capabilities from Figure 1.

Although this diagram shows the critical success factors for sustainable technology change, most organizations rarely follow it, even if they have defined something similar. The reasons have been alluded to earlier, but are briefly listed below:

  • a lack of respect for the enterprise architecture group
  • a belief that such a process is too time consuming and too costly
  • a "hyped up" belief that the technology itself provides all that is required for success
  • a new, untried technology has been deemed “critical” to a project’s success. The time pressure to deploy this project is extreme and there is no time to waste on a “cumbersome ivory tower process” to vet the technology.

Figure 2
Figure 2. The technology capability improvement process

The technology capability improvement process depicted in Figure 2 enables a sustainable model of change over time, yet it is surprising how infrequently this proven approach is applied in practice due to lack of a capability-driven perspective. The five-step flow includes the initial needs assessment, which helps ground the proposed capability in terms of relevance. The alternative-evaluation stage provides an opportunity to compare various solutions, which is especially important during an innovation wave because many of the initial product offerings that provide the capability may not live up to the market hype. The sourcing-decision stage evaluates the various product vendors’ viability, which must be assessed before a long-term investment can be made. Rolling out a new capability is a two-phase activity: the first phase is a pilot, and the second phase is a larger-scaled rollout. The pilot phase localizes the impact until it is better understood and should be done by a small dedicated team. Finally, the assessment of effectiveness and associated ratings of key performance indicators (KPIs) provide feedback to the overall process as well as a judgment on the technology itself.

Sustainable Process Change

Senior management must sponsor, drive, and own process improvement. Management must be held accountable for process performance and should be rewarded for demonstrable improvement, because these improvements are critical to sustainable success and therefore have parity with other executive initiatives. Only active executive sponsorship enables disciplined process-performance improvement and generates acceptance for process alignment and adaptability that can spread across the firm. Bossidy and Charan (2002) characterize this type of active sponsorship as a leader’s most important responsibility.

Figure 3 elaborates the IT process capability improvement process. In this context, both the capability of a process (i.e., the ability of the process to meet specifications) and its stability (i.e., the consistency/stability of process behaviour over time) are addressed as part of the IT process capability improvement process.

Figure 3

Figure 3. The IT process capability improvement process

This model builds up to the "improve process" phase in a systematic multi-step approach. The first step, identification of process scope and needs, is critical. This step is often bypassed or done poorly, which has detrimental downstream impact, limiting the benefits of the process-improvement efforts as well as introducing re-work (i.e., waste) along the way. In this first step, the process specifications are captured along with outcome indicators, which set the bar for what is considered success.

Next, the process flow is captured and then indicators and controls are identified and confirmed. At this stage, the additional indicators are typically predictive in nature given that the outcome indicators should have been already identified in the first step, unless there is a need for additional sub-indicators (outcomes). The controls relate to the triggers and interventions that would be required when the process is not performing. Ideally, predictive indicators should be statistically confirmed with the outcome indicators. Then, the Process Management Control System is implemented, which enables systematic monitoring and assessment of process performance along with the appropriate intervention. The Process Management Control System is essential to the “assess/monitor performance phase” because processes and process improvement both heavily rely on the coordination and cooperation among different roles and departments.

The “assess/monitor performance phase” leads to the "improve process" phase. Any process improvement methodology can be used. In Renaud, Narkier, and Bot (2013), we illustrated the define-measure-analyze-improve-control (DMAIC) process from Lean Six Sigma because this particular methodology is central to realizing sustainable breakthrough improvements as opposed to only incremental ones.

As IT processes begin to improve, the IT function will inevitably discover that its existing capabilities are bottlenecks for business processes. These bottlenecks occur because the scope of process improvement is limited to the IT function but IT processes enable larger business processes. Restricting process improvement within the IT function may not necessarily be the best way of resolving these bottlenecks. More effective changes to the business process may avert the need to alter IT capabilities or may require the introduction of new capabilities of a different type. For example, the nightly IT operational process of loading a data warehouse may uncover that errors in data are causing the IT process to not complete overnight as required by the business process. A more effective solution than simply speeding up data error correction would be to alter upstream business processes to prevent them from producing transactions that contain data errors in the first place. Technology change may be necessary elsewhere in the IT function or improved processes may be required within the business function.

A key factor in making process changes is related to how the business goals and drivers are impacted by the requisite processes. The appetite for change and investment will be fueled by the degree which current processes are considered an impediment.

Sustainable Competency Change

The goal of an IT competency capability improvement process is proactive learning and its essential aspects are illustrated in Figure 4. The process steps to improve or introduce new competencies enable incremental improvement over time and are distinguished from the other improvement processes by two definition and two assessment stages – one for the requisite competencies needed by the IT function and the other for the competencies needed by the personnel in various IT roles.

Figure 4

Figure 4. IT competency capability improvement process

Proactive learning

As shown in the "define competency" step of Figure 4, identifying, selecting, and then defining a competency are vital first steps in this process because the outcome of this improvement process is an investment in training and recruitment. Yet, in practice, the skill set of the IT organization is rarely proactively upgraded. Most learning occurs on the job, in a “just-in-time manner” that is driven by a response to previous changes. Although this approach may work for an exploratory process such as evaluating a new technology, it does not scale due to the full workload most IT practitioners have on day-to-day basis. Where active learning exists, the dissemination process established by the human resources function is too general and does not necessarily reflect how the IT function needs to support the firm’s goals. Learning of new capabilities is rarely codified and typically does not have the dedicated resources to move rapidly if needed.

The subsequent step of linking to a process area is the key to understanding the scope and impact that each role is supposed to have within the IT function combined with the requirements for the requisite skill set. By failing to link competencies to process areas, many firms under-invest in IT training. This reluctance to invest is due to the perception that technology changes rapidly. Therefore, investing in training for changing technology needs will not reap sufficient benefits before the training becomes obsolete. This misperception is the result of two kinds of learning that are essential for IT competency improvement:

  1. Less-volatile fundamentals of each process role (e.g., design principles, understanding each of the processes in IT, requirements gathering and analysis)
  2. Volatile needs relating to specific technologies, such as new programming languages (e.g., Scala) or major revisions of well-known products (e.g., a new Oracle database release)

Another major concern about IT learning is that older training curricula are not sufficiently reviewed for relevance, or are not revised or retired. A new IT training role must be created to review, update, and purge training content and curricula within the context of role-driven knowledge management and information lifecycle management.

To define requisite competencies, a role-based skills sheet should be produced for each group within the IT function based upon the firm’s strategy. The competencies of an individual should then be evaluated against the required skills so that a training plan can be produced and subsequently tracked.

The rest of the flow depicts an improvement phase where the skills are assessed and improved upon, while determining the degree of impact and adoption the skills are having throughout the firm.

Investment by the IT function into becoming a learning organization must balance the needs of both volatile and non-volatile training. Less volatile material should be taught on-demand through computer-aided learning that is supplied by specialty vendors. Formal classroom training should be used for learning areas that require wide socialization due to their “radical” nature (e.g., extreme programming) or novelty. Despite being less volatile, any formal training should be organized via collaboration with institutes for higher education to ensure that that course content remains fresh. The need for formal instruction and active group participation should be means-tested against intent. For instance, interpersonal skills improvement clearly requires an active class with formal instruction, whereas learning the basics of systems architecture could occur via computer-aided instruction supplemented by a "live lab" to answer questions.

More volatile learning areas, which are often very hands-on (e.g., a new language or new product release), are best licensed through the vendors so that they can bear the ongoing cost of updating the learning curriculum. Just-in-time classes can be effective provided that the attendees can be insulated from day-to-day responsibilities and that they meet the prerequisites to learn the class material.

The successful implementation of such a program requires a supporting culture which includes mentorship. The side benefit of such a program is that it relates a promotion path to company goals, which emphasizes a value-based growth-reward system.

Competency improvement is clearly a long-term investment in learning and can only be sustained in an IT function if it is supported by a cultural mindset that can see beyond the usual horizon of yearly objectives. The alternative is the perpetuation of the current problem-ridden status quo of learned helplessness.

Importance of Culture

Sustainable improvement in any capability area will occur only when implemented in a way that also matures the culture of the IT function.  Culture is commonly defined as a set of shared values, goals, and principles that guide the behaviours, activities, priorities, and decisions of a group of people working toward a common objective (Bohannan, 2010). Weigers (1996) emphasizes several key points:

  1. The improvement of process and product, along with the management of risk, is a key competitive advantage, no matter what changes occur in technology.
  2. This advantage enhances the ability of an organization to make a sustainable work environment while remaining competitive with respect to time to market and price.
  3. A shared culture is a necessary foundation for progressing through the capability maturity sequence, until the discipline of creating repeatable and measurable development processes can be achieved.

Weigers’ observations on the culture of software engineering can be generalized to the entire IT function because promoting sustainable change in the behaviour of the IT function requires deliberate attention to creating a culture of relevance throughout the IT function. This culture emphasizes and promotes the purpose of the IT function, which is to enable and facilitate the firm’s goals – not impede them. Any cultural change needs continuous reinforcement, particularly within the IT function, which can experience 17–22% yearly turnover in staff (Fidato Partners, 2012). Although turnover varies widely in IT organizations depending upon regional and industry differences, this reported level of turnover matches our experience across many industries. We attribute these turnover rates to ongoing changes in technology and competitive inter-firm demand for qualified personnel.

Thus, a change in culture cannot occur without a deliberate focus on executing a capability improvement plan that is tracked with the understanding that this plan is instrumental to the IT function’s survival as a relevant entity. Achieving this level of focus on execution requires ownership, accountability, and responsibility across all management levels. A systematic approach to sustaining the culture will assess, align, and measure the results that the culture produces in the day-to-day running of the firm. Although business goals will change frequently, cultural values should not be that volatile. Instead, the key concern is the dilution of the culture due to employee turnover and management inattention.

Organizing for cultural change is a governance activity that transcends reporting hierarchy and extends to wide-ranging subjects, from how the IT supply chain inventory is categorized to how the IT function measures its capabilities and performance. The capability hierarchy presented by the authors in an earlier article in this series (Renaud et al., 2013)  provides the taxonomy for categorizing technology capabilities within the IT supply chain. The capability hierarchy also provides a self-describing and rigorous means of defining and categorizing capabilities. For example, it is easy to understand what technology capabilities are categorized under a particular capability simply by seeing which other capabilities it depends on.

Conclusion

Continuous, sustainable change to IT capabilities is required by firms seeking agility in innovation. Lack of sustainable change in IT will result in the failure of the firm.

IT change cannot be performed in isolation because the introduction of the most innovative and impactful technology will fail to deliver its promise without supporting process and competency capabilities. A capability perspective is critical to identify gaps in processes, skills, and technology that impede the firm’s goals.

However, capability improvement does not just occur by declaration. Instead, capabilities, which are strongly linked to the discipline of execution, must be well-defined, with inter-relationships and dependencies mapped and underpinned by supporting capabilities.

Proactive improvement by IT executives and change agents requires both a culture shift and alignment with business goals and drivers in order to receive the business unit sponsorship required. Alignment is also necessary so that the IT function’s relevance can properly be linked to the firm’s innovation needs. The alternative is that IT stagnates, ultimately hurting the firm’s ability to innovate.

Recommended Reading

This article completes the authors' six-part series on IT entrepreneurship in the Technology Innovation Management Review:

  1. Process Ambidexterity for Entrepreneurial Firms (Bot, 2012)
  2. Process Ambidexterity for IT Entrepreneurship (Bot & Renaud, 2012)
  3. Enabling Process Alignment for IT Entrepreneurship (Renaud & Bot, 2012a)
  4. Process Adaptability in the IT Supply Chain (Renaud & Bot, 2012b)
  5. Enabling Sustainable Improvement in IT Entrepreneurship (Renaud, Narkier, & Bot, 2013)
  6. Using a Capability Perspective to Sustain IT Improvements (Renaud, Narkier, & Bot,  2014: the present article)

 


References

Bohannan, P. 2010. How Culture Works. New York: Simon and Schuster.

Bossidy, L., & Charan, R. 2002. Execution: The Discipline of Getting Things Done. New York: Crown Business.

Bot, S. D. 2012. Process Ambidexterity for Entrepreneurial Firms. Technology Innovation Management Review, 2(4): 21–27.
http://timreview.ca/article/547

Bot, S. D., & Renaud, P. E. 2012. Process Ambidexterity for IT Entrepreneurship. Technology Innovation Management Review, 2(8): 16–22.
http://timreview.ca/article/596

Curtis, B., Hefley, W. E., & Miller, S. 1995. Overview of the People Capability Maturity Model. Technical Report No. CMU/SEI-95-MM-01. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University.

Dyche, J. 2012. Shadow IT Is Out of the Closet. Harvard Business Review Blog. June 1, 2014:
http://blogs.hbr.org/2012/09/shadow-it-is-out-of-the-closet/

Fidato Partners. 2012. Information Technology Salary Guide and Turnover Report. Philadelphia: Fidato Partners.

Paulk, M. C., Weber, C. V., Garcia, S. M., Chrissis, M. B., & Bush, M. 1993. Key Practices of the Capability Maturity Model. Technical Report No. CMU/SEI-93-TR-025, ESC-TR-93-178. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University.

Renaud, P. E., & Bot, S. D. 2012a. Enabling Process Alignment for IT Entrepreneurship. Technology Innovation Management Review, 2(11): 13–20.
http://timreview.ca/article/626

Renaud, P. E., & Bot, S. D. 2012b. Process Adaptability in the IT Supply Chain. Technology Innovation Management Review, 2(11): 33–40.
http://timreview.ca/article/627

Renaud, P. E., Narkier, S. D., & Bot, S. D. 2013. Enabling Sustainable Improvement in IT Entrepreneurship. Technology Innovation Management Review, 3(6): 28–38.
http://timreview.ca/article/694

Senge, P. M. 2006. The Fifth Discipline: The Art & Practice of The Learning Organization (Revised edition). New York: Crown Business.

The Open Group. 2011. The Open Group Architecture Framework (TOGAF) (Version 9.1). The Open Group.
http://www.opengroup.org/togaf/

Wiegers, K. E. 1996. Creating a Software Engineering Culture. New York: Dorset House.

Zachman, J. A. 1987. A Framework for Information Systems Architecture. IBM Systems Journal, 26(3): 276–292.
http://dx.doi.org/10.1147/sj.263.0276

Share this article:

Cite this article:

Rate This Content: 
No votes have been cast yet. Have your say!

Keywords: capability improvement, capability maturity model, change management, competency capability, enterprise architecture, IT function, organizational culture, organizational learning, process capability, shadow IT, technology capability

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Badbot Fields
If you see these fields, something is wrong.
If you see this field, something is wrong.
If you see this field, something is wrong.
If you see this field, something is wrong.