No abstract

T hough information technology (IT) transformation programs are gaining in importance, we know little about the nature of the challenges involved in such programs and how to manage them. Using grounded theory methodology, we conducted a multiyear case study of a large IT transformation program in a major commercial bank, during which we encountered the interrelated themes of paradoxes and ambidexterity. Grounded in our case, we construct a substantive theory of ambidexterity in IT transformation programs that identifies and explains the paradoxes that managers need to resolve in IT transformation programs. The ambidexterity areas we identified are (1) IT portfolio decisions (i.e., IT efficiency versus IT innovation), (2) IT platform design (i.e., IT standardization versus IT differentiation), (3) IT architecture change (i.e., IT integration versus IT replacement), (4) IT program planning (i.e., IT program agility versus IT project stability), (5) IT program governance (i.e., IT program control versus IT project autonomy), and (6) IT program delivery (i.e., IT program coordination versus IT project isolation). What weaves these six areas together is the combined need for IT managers to employ ambidextrous resolution strategies to ensure short-term IT contributions and continuous progress of IT projects while simultaneously working toward IT transformation program success as a foundation for IT-enabled business transformation. However, in addition to this commonality, we find that the nature of paradoxical tensions differs across the six areas and requires slightly different management strategies for paradox resolution. Ambidexterity areas (1), (2), and (3) are associated with IT transformation strategizing and, in addition to balancing short-and long-term goals, require the mutual accommodation and blending of business and IT interests in the spirit of IT-business partnering to achieve IT-enabled business change and IT-based competitiveness. Ambidexterity areas (4), (5), and (6) are associated with IT program and project execution and, in addition to balancing short-and long-term requirements, require a recurrent and dynamic act of balancing "local" needs at the IT project level and "global" needs at the IT program level.

Information technology (IT) project escalation is a common and costly problem. While much is known about the factors that promote escalation behavior, little is known about the actual escalation process. This article uses an in-depth case study to construct a process model of escalation, consisting of three phases: drift, unsuccessful incremental adaptation, and rationalized continuation. Each phase encompasses several within-phase escalation catalysts and the model also identifies triggering conditions that promote transition from one phase to the next: project framing (antecedent condition), problem emergence, increased problem visibility, and imminent threat to project continuation (triggering the outcome deescalation). The results show that escalation is not necessarily the result of collective belief in the infallibility of a project. Rather, escalation results from continued unsuccessful coping with problems that arise during a project. Furthermore, the results suggest that the seeds of escalation are sown early: the very manner in which a project is framed contributes to whether or not the project will become prone to escalation. As problems ensue, repeated mismatches between attempted remedies and underlying problems contribute to fueling the escalation process. Implications for research and practice are discussed.

No abstract