Research Project: Portfolio Project This week's written activity is a three- part activity. You will respond to three separate prompts but prepare your paper as one research paper. Be sure to include

Combining deductive and inductive approaches for theory building, we develop an initial model based on the literature and then modify it based on the results of a longitudinal embedded mixed-methods study of 13 projects at 2 organizations over a 10-year period. The results provide insights into the development of MU within projects, including (1) how MU changes during projects as a result of cognitive activities (sensegiving and sensemaking); (2) how planning and control mechanisms (and the associated artifacts) affect these cognitive activities; (3) how MU, and achieving it early in the project, affects success; and (4) how stakeholder engagement (in terms of depth, scope, and timing) affects the relationships in (1) and (2). The results also indi- cate that project management mechanisms, stakeholder engagement, and MU may change (either improve or deteriorate) across projects, depending on the disagreements among stakeholders in previous projects, the introduction of new project elements in subsequent projects, and the reflection on previous projects.

Keywords: Information systems development, project planning, project control, cognition, sensegiving, sensemaking, mutual understanding, project stakeholders Introduction 1 Despite being crucial to organizations (Gemino et al. 2007; Wallace et al. 2004), information systems development (ISD) projects continue to show a propensity to fail, with less than half being successful (Hughes et al. 2017; Standish 2015).

This is attributed to reasons such as technical complexity,dynamic power structures, and uncertain and changing requirements (e.g., Davidson 2002; Hughes et al. 2017). Con- sistent with the need to share knowledge among information technology (IT) and business project stakeholders (managers and staff) to address such issues, the primary causes for ISD problems are seen as sociocognitive (Lyytinen 1987; Newman and Noble 1990), such as stakeholders’ conceptions of reality that are different (Cronin and Weingart 2007; Rai et al. 2009) and evolving (Vlaar et al. 2008). Thus, mutual understanding (MU) among key stakeholders (business and IT managers, users, and developers), or the extent to which they have a shared conception of the ISD project, is important to project 1Arun Rai was the accepting senior editor for this paper.

The appendices for this paper are located in the “Online Supplements” section of MIS Quarterly’s website (https://misq.org).

DOI: 10.25300/MISQ/2019/13980MIS Quarterly Vol. 43 No. 2, pp. 649-671/June 2019649 Jenkin et al./Mutual Understanding in IS Development success. However, MU itself may change, developing or deteriorating, over time (Davidson 2002; Gregory et al. 2013).

In this article, we focus on such changes in MU among stakeholders.

The changes in MU among stakeholders can be understood using prior theoretical work on sensegiving and sensemaking (e.g., Vlaar et al. 2008; Weick 1995). Sensegiving involves framing and sharing information, including narratives, explanations, and signals by some individuals to influence how others think and act (Gioia and Chittipeddi 1991; Vlaar et al. 2008), whereas sensemaking involves individuals accessing and interpreting information to develop compre- hension and construct meaning (Stigliani and Ravasi 2012; Vlaar et al. 2008). The need to share knowledge across pro- ject stakeholders is also apparent in the literature on planning and control (e.g., Kirsch 2004; Zmud 1980) in ISD projects.

For example, Wallace et al. (2004) discuss how poor planning and control cause knowledge gaps such as unclear schedules and milestones for evaluating progress. Similarly, Tiwana (2009) examines the relationship between project control and knowledge sharing between IT and client departments. The relationship between project control and MU has also been examined (e.g., Gregory et al. 2013; Kirsch 2004), but sense- giving and sensemaking, which have both been argued to enable MU (e.g., Vlaar et al. 2008), have not been studied in conjunction with project planning and control mechanisms. Thus, the literature recognizes that (1) the use of planning and control mechanisms in ISD projects involves knowledge sharing among stakeholders, (2) such knowledge sharing enables sensegiving and sensemaking, and (3) sensegiving and sensemaking enable MU. But these arguments are inde- pendent of each other, and how project planning and control mechanisms interact with cognitive activities (i.e., sense- giving, sensemaking) to affect cognitive (i.e., MU) and project outcomes is not well understood. Therefore, we seek to provide insights into changes in MU over time when con- sidering project planning and control mechanisms as well as sensegiving and sensemaking. Specifically, we examine how sensegiving and sensemaking by project stakeholders helps explain the effects of planning and control mechanisms on MU, and the changes in MU over time within a project (i.e., within a project stage, or between stages of the same project) and across projects (i.e., from one project to the next, or to one much later). Thus, we address the following research questions:

1. Within a project, how do project management mech- anisms (planning, control) affect cognitive activities (sensegiving, sensemaking) by key stakeholders, cogni- tive outcome (MU among key stakeholders), and project success?2. How do project management mechanisms, cognitive activities, cognitive outcome, and success of an ISD project affect subsequent projects?

To address these questions, we conduct case studies of 13 ISD projects in 2 organizations, mitigating some of the issues with single-project studies (Elbanna 2010). Combining deductive and inductive approaches (e.g., Shepherd and Sutcliffe 2011), we use the literature to propose an initial model and then use empirical findings, based on a longitudinal embedded mixed- methods design (Creswell and Clark 2007), to reach the emergent model.

The rest of this article is organized as follows. We first develop the initial model by integrating concepts of cognition, stakeholders, and planning and control mechanisms. We then discuss our research methods. Next, we summarize the insights from our analyses and present the emergent model.

We conclude with a discussion of the implications and limitations of our study. Theoretical Development Project Success Project success has generally been viewed as including pro- cess efficiency, product effectiveness, user satisfaction, and degree of project completion (e.g., whether the project is smoothly completed, partially abandoned, or totally aban- doned) (Aladwani 2002; Gemino et al. 2007). Process effi- ciency reflects how well the project was executed, and product effectiveness reflects the quality of the system delivered. Past research views evaluations of ISD projects as value laden and social, based on the perceptions and expec- tations of various project stakeholders (e.g., Hughes et al.

2017). Thus, if one stakeholder group is not satisfied, the pro- ject may be viewed as less successful than if all stakeholder groups are satisfied. Mutual Understanding Mutual understanding refers to the extent to which stake- holders have a shared conception of the project regarding, for example, its goals and processes, and stakeholder roles (Greg- ory et al. 2013). Other terms used to describe MU include congruent understanding (Vlaar et al. 2008) and shared under- standing (Gregory et al. 2013). The importance of MU is highlighted in the information systems (IS) literature, such as on IS group performance (e.g., Nelson and Cooprider 1996) and technology innovativeness (e.g., Lind and Zmud 1991). 650MIS Quarterly Vol. 43 No. 2/June 2019 Jenkin et al./Mutual Understanding in IS Development A shared understanding of goals and methods has been linked to project success (Aladwani 2002; Gregory et al. 2013). Dif- ferent interpretations arise in projects (Cronin and Weingart 2007; Lyytinen 1987) because of differing goals, interests, and conceptions of reality (Sambamurthy and Kirsch 2000).

Thus, developing MU is important.

MU among stakeholders changes over time, developing or deteriorating, and at different rates (Gregory et al. 2013; Monin et al. 2013). Prior ISD studies link MU development to project planning (Wallace et al. 2004) and control mech- anisms (Gregory et al. 2013; Kirsch 2004), and sensegiving and sensemaking (Vlaar et al. 2008). However, the relation- ships among project management mechanisms, sensegiving, and sensemaking have not been examined. Thus, under- standing how and why project planning and control mech- anisms affect changes in MU over time through sensegiving and sensemaking provides valuable theoretical and practical insights into the role of these mechanisms beyond their tradi- tional role in project management.

To address this gap, we develop an initial model (Figure 1), focusing on how project management mechanisms and cogni- tive activities (sensegiving, sensemaking) affect MU among project stakeholders, and how MU affects project success.

Within a project, and consistent with the literature (Monin et al. 2013; Vlaar et al. 2008), sensegiving and sensemaking activities influence MU among stakeholders. However, instead of viewing project planning and control mechanisms as affecting MU directly, we reason that they affect MU through their sensegiving and sensemaking potential. Consis- tent with the literature, we argue that MU influences the success of the ISD project (Aladwani 2002; Gregory et al.

2013). Given the limited literature on MU change within and across ISD projects, we do not include these aspects in the initial model but use a data-driven inductive approach to develop propositions about them.

Sensegiving and Sensemaking Activities ISD projects include an ongoing dialogue among IT and busi- ness stakeholders, involving episodes of sensegiving and sensemaking (cognitive activities) (Gioia and Chittipeddi 1991; Stigliani and Ravasi 2012), which affect the MU (the focal cognitive outcome) among these stakeholders (Vlaar et al. 2008). Sensemaking involves constructing and recon- structing meaning, interpreting, 2 and updating cognitive frameworks (Gioia and Chittipeddi 1991). Sensemaking inorganizations involves an interplay between individual and group sensemaking, through conversations and artifacts (Weick et al. 2005).

Through sensegiving, individuals influence others’ interpre- tation of a situation, that is, their sensemaking (Gioia and Chittipeddi 1991). ISD projects include several stakeholders (business and IT managers, users, and developers) who may pursue their own agendas (Sambamurthy and Kirsch 2000).

Influencing others’ sensemaking is one way to do this. Sense- giving and sensemaking 3 affect each other; one or more actors provide sense via artifacts or communication and one or more actors make sense of such stimuli (Gioia and Chittipeddi 1991). Thus, it is important to understand the role of actors as sensemakers and sensegivers. Project Planning and Project Control Mechanisms The ISD literature considers planning and control mechanisms as key ways to guide the project team and stakeholders to increase the likelihood of project success (Barki et al. 2001; Gemino et al. 2007). Accordingly, we focus on these mech- anisms.

Project Planning Project planning involves identifying the scope, structure, and sequence of tasks; allocating resources; and estimating time and costs (Wallace et al. 2004). The literature emphasizes planning to provide information that mitigates uncertainty (Barki et al. 2001). Planning has been viewed as critical to meeting project targets (e.g., lower budget variances), pro- ducing high-quality software (Yetton et al. 2000), and enhancing the project success (Pinto and Slevin 1987).

The literature distinguishes between a comprehensive, formal, and top-down approach to planning and an incremental, or emergent, and bottom-up approach. This distinction is seen in both the IS strategic planning (Chen et al. 2010; Segars and Grover 1999) and broader strategy (Fredrickson 1984; Mintz- berg 1990) literatures, which discuss planning attributes of rationality (i.e., comprehensive, integrated, and formal planning) and adaptability (i.e., frequent planning iterations and a learning orientation). In these literatures, comprehen- sive planning is “top-down” in nature; ideally, senior manage- 2Sensemaking can focus on interpreting past events, that is, retrospective sensemaking (Weick 1995), or envisioning what the future may look like, that is, prospective sensemaking (Gioia and Mehra 1996). 3Past studies identify other cognitive activities (e.g., sense demanding, sense breaking) (Monin et al. 2013; Vlaar et al. 2008) and outcomes (e.g., novel understanding). We focus on sensegiving and sensemaking, which have received the greatest attention and been most directly related to MU.

MIS Quarterly Vol. 43 No. 2/June 2019651 Jenkin et al./Mutual Understanding in IS Development Project Management Mechanisms Mutual Understanding Project Success Sensegi vi ng Sensemaking Cognitive Acti vities Cognitive Outcome Project Outcome Pl anni ng Mechanisms Cont r ol Mechanisms Sensegivi ng Pot ent i al Sensemaking Pot ent i al Figure 1. Initial Model ment and project managers communicate a clear vision of the project’s objectives, and how to achieve them, to the project team and stakeholders. Thus, many of the project details are conveyed up-front to the team by project and organizational leaders. However, detailed plans may not exist in projects with a high level of uncertainty. In such cases, planning pro- cesses are more emergent and “bottom-up” (Segars and Grover 1999), focusing on iteratively developing the project objectives and deliverables. Thus, emergent planning in- volves experimentation, developing prototypes and other artifacts, and dialogue. Project Control Control is viewed as “any attempt to motivate individuals to behave in a manner consistent with organizational objectives” (Kirsch 2004, p. 374). The literature on control distinguishes between the “controller,” who exercises control, and the “con- trollee,” whose behavior is being controlled (Flamholtz et al.

1985). Early studies of ISD projects discussed formal control mechanisms and their effects on project success (e.g., Zmud 1980). Control mechanisms were seen as ways to enable managers to understand project progress and detect deviations early enough to take corrective actions. The literature exam- ines various types of formal and informal control mechanisms (e.g., Henderson and Lee 1992).

Formal controls include outcome and behavior controls.

Outcome controls involve specifying the project’s interim and final outcomes (e.g., requirements, design specifications, and delivery date) and measuring the extent to which they are fulfilled (e.g., quality assurance and testing results) (Choud- hury and Sabherwal 2003; Kirsch 1997). Behavior controls involve the controller providing specifications for the process (e.g., ISD methods) and then assessing the extent to which the controllee behaves according to these specifications (e.g., observation).Informal controls include clan and self-controls. In groups using clan controls, members share a common goal, depend on one another, and influence each other to behave in accept- able ways based on the group’s norms, values, and beliefs (Kirsch 1996). Although project teams are often diverse and temporary, role- or function-specific groups such as program- mers and testers may operate as clans. Clan controls include socialization to develop shared norms, and mechanisms to reward behavior that is consistent with the norms and to sanc- tion behavior that violates them. Self-control, by contrast, stems from individual objectives and intrinsic motivation (Kirsch 1996) and requires controllee autonomy (Tiwana and Keil 2009). Project Management Mechanisms and Cognitive Activities and Outcomes Although prior research discusses the relationships of project planning and control mechanisms with MU (e.g., Gregory et al. 2013; Kirsch 2004), how these mechanisms affect MU is not described. For example, Gregory et al. (2013) find that gaps in MU led to different control approaches being em- ployed, which in turn led to the development or deterioration of MU, but they do not examine how control mechanisms such as status review meetings and socialization activities help develop MU among project stakeholders. Prior research suggests that artifacts, for example, templates and methods (Vlaar et al. 2008), enable sensegiving or sense- making (Gephart 1993; Stigliani and Ravasi 2012). Thus, we incorporate the notion that project planning and control mech- anisms have the potential to support sensegiving and sense- making. For example, outcome controls, such as a plan, have the potential to support moderate levels of sensegiving and sensemaking, as discussed in detail later. In using a mech- anism, the potential is converted into actual sensegiving and sensemaking; the extent to which this potential is realized depends on how the mechanism (e.g., plan) is used. 652MIS Quarterly Vol. 43 No. 2/June 2019 Jenkin et al./Mutual Understanding in IS Development Table 1. Implications of Project Planning and Control Mechanisms for Sensegiving and Sensemaking Type of MechanismPotential for SensegivingPotential for Sensemaking References PlanningComprehensive High LowBowman et al. (1983); Levina (2005); Segars and Grover (1999) Emergent Moderate HighAbdel-Hamid et al. (1999); Levina (2005); Segars and Grover (1999) ControlSelf-control Low HighHenderson and Lee (1992); Kirsch (1996); Tiwana and Keil (2009) Clan control High High Kirsch (1997, 2004) Outcome control Moderate ModerateChoudhury and Sabherwal (2003); Kirsch (1997); Nidumolu and Subramani (2003) Behavior controls Moderate ModerateKirsch (1996, 1997); Nidumolu and Subramani (2003); Orlikowski (1991) We use logic and an extensive literature review to assess the potential for the sensegiver to give sense with each mech- anism (e.g., emergent planning, outcome controls), and the potential for the sensemaker to make sense of what is con- veyed through that mechanism. Table 1 provides the sense- giving and sensemaking potential for each mechanism.

Appendices A and B provide further details regarding the underlying logic and illustrative quotes from the literature, respectively, supporting the connection between each mech- anism and its sensegiving or sensemaking potential.

Extending existing theory, we propose that the greater the sensegiving or sensemaking potential of the mechanisms used in a project, the greater the actual sensegiving or sense- making, respectively.

Stakeholders in ISD Projects In ISD projects, stakeholders give and make sense of elements related to the project, such as the development process and the project deliverables. Given the differences in interpretations, goals, and interests across stakeholders (e.g., Gregory et al.

2013; Lyytinen 1987), it is important to consider which stake- holders give sense and which make sense over the course of the project. Boland and Tenkasi (1995) take this into account in their related concepts of perspective making and perspec- tive taking, differentiated by the groups involved. Perspective making focuses on within-group sensegiving-sensemaking episodes to strengthen the group’s knowledge, whereas per- spective taking considers each group’s viewpoint in across- group sensegiving-sensemaking.

Past studies examine the role of IS versus business stake- holders (e.g., Bassellier et al. 2001; Kirsch 2004), that is, thefunctional home of the stakeholder. The structural position of stakeholders is also deemed important (e.g., Boland and Ten- kasi 1995; Markus and Mao 2004), for example, whether management (e.g., a project manager) interacts with staff (e.g., programmers) or staff interact with peers (e.g., pro- grammers with users) (e.g., Nidumolu 1996). Thus, we dif- ferentiate stakeholder groups along these functional (IT and business) and structural (staff and management) dimensions, resulting in four groups: IT managers (e.g., IT project mana- ger, test lead), business managers (e.g., business unit mana- ger, project sponsor), developers (e.g., programmer, tester), and users (e.g., external customer, internal end-user).

Figure 2 depicts a sensegiving-sensemaking episode between two stakeholders from these groups, showing the iterative nature of the process and how it is affected by planning and control mechanisms. This is a generic depiction, and addi- tional stakeholders could be involved. Consistent with the sensemaking literature (Monin et al. 2013; Stigliani and Rava- si 2012; Vlaar et al. 2008), these sensegiving-sensemaking episodes positively influence MU among stakeholders, which positively affects project success (Aladwani 2002; Davidson 2002; Gregory et al. 2013). Combined with our previous discussion of the effects of project management mechanisms on sensegiving and sensemaking, we propose the following (as shown in Figure 1):

Within an ISD project, project planning and project control mechanisms (through their sensegiving and sensemaking potential) influence sensegiving and sensemaking activities, which affect each other and enable MU among stakeholders, and this MU leads to greater project success. MIS Quarterly Vol. 43 No. 2/June 2019653 Jenkin et al./Mutual Understanding in IS Development Figure 2. Sensegiving-Sensemaking Episode Research Design Our research questions focus on understanding changes in MU among project stakeholders and how these changes depend on planning and control mechanisms and sensegiving and sensemaking activities. To address these research ques- tions, we use a variance approach, a longitudinal embedded mixed-methods design that combines qualitative and quanti- tative methods, and a theory-building approach that combines deduction and induction. The literature suggests that process-oriented research ques- tions can be examined using a variance approach, a process approach, or a hybrid approach (Burton-Jones et al. 2015; Sabherwal and Robey 1995). According to Van de Ven (2007, p. 148), two different definitions of “process” are often used in the literature: (1) a category of concepts or vari- ables that pertain to actions and activities; and (2) a narrative describing how things develop and change .… When the first definition is used, process is typi- cally associated with a variance model …. The second meaning of process takes an event-driven approach that is often associated with a process study of the temporal sequence of events.

We adopt a variance approach (Burton-Jones et al. 2015) and examine process in terms of activities and changes in state(Van de Ven 2007) over time. The initial model (Figure 1) focuses on how the use of project planning and control mech- anisms (states) and sensegiving and sensemaking (activities) affect the level of MU (state) among project stakeholders, and how MU affects success (state) within a project. Qualitative data on the cognitive activities are used to assess these acti- vities in terms of their levels (state). We capture low, moderate, and high levels of sensegiving and sensemaking, and directionality in terms of who gave and made sense:

localized (i.e., between members of the same group), unidirectional, or bidirectional. The literature (Creswell and Clark 2007; Venkatesh et al.

2013) mentions four mixed-methods designs: triangulation, embedded, explanatory, and exploratory. An embedded design uses qualitative or quantitative methods in a study based largely on the other method. We use a longitudinal embedded mixed-methods design, conducting exploratory quantitative analyses in a primarily qualitative study. Speci- fically, we use quantitative analyses to explore the data and qualitative analyses to develop a rich understanding. We study changes over time using temporal bracketing (Langley 1999), that is, dividing each project into early, middle, and late stages.

Moreover, we combine deductive and inductive theory- building approaches (e.g., Shepherd and Sutcliffe 2011). We use the ISD literature to identify the proposed relationships (Figure 1) and develop an episode model (Figure 2) of sense- 654MIS Quarterly Vol. 43 No. 2/June 2019 Jenkin et al./Mutual Understanding in IS Development giving and sensemaking between stakeholders, showing the influence of project planning and control mechanisms. We then use a bottom-up inductive approach to generate emergent propositions (Eisenhardt 1989; Mantere and Ketokivi 2013).

The 10-year case study data, which include rich insights from 13 projects across two organizations, allow us to identify pat- terns, relationships, and insights beyond those described in the literature. Thus, consistent with Eisenhardt’s (1989) recom- mendations for building theory from case studies, we are guided by pre-identified concepts in the initial model but allow unanticipated concepts and relationships to emerge.

This is further discussed in the next section (see Appendix C for a summary).

Data Data Collection To select cases for inductive theorizing, Eisenhardt (1989) recommends theoretical sampling. We first identified two organizations with headquarters in North America: “Alpha” and “Beta” (pseudonyms). We then used theoretical sampling to select contrasting projects, asking the key informant at each organization to choose projects ranging in focus, importance, and success. At Alpha, a global software development firm, we studied seven projects involving the development and enhancement of enterprise software. At Beta, a global manu- facturer and seller of high-tech products, we studied six projects involving the development and enhancement of inter- nally facing (i.e., supporting internal processes) and externally facing (i.e., supporting customer or supplier interactions) sys- tems. Thus, the two organizations provide different kinds of ISD projects. Table 2 summarizes the 13 projects (see Appendix D for further details).

We followed Eisenhardt’s (1989) recommendations on using multiple and flexible data collection methods, combining qualitative and quantitative data, involving multiple investi- gators, and overlapping data collection and analysis. We developed an interview guide based on the initial model and refined through inputs from industry experts and researchers (see Appendix E for the final version of the guide, which we provided to the key informant at each organization to review before the interviews). We discussed the kind of data to collect, developed the interview guide, and considered interim findings to plan subsequent interviews. Because of method- ological and scheduling considerations, one of us conducted the interviews.

We conducted three intensive waves of onsite interviews in 2004, 2005, and 2010, including 24 formal interviews with 21 informants at the two organizations, many of whom com-mented on multiple projects. We conducted 17 interviews at Alpha (informants included a vice president, product man- ager, project managers, department managers, product designers, programmers, team leads, testers, and technical writers) and seven at Beta (informants included project managers and functional managers in both IT and business).

Project documents and informal conversations at each organi- zation provided additional insights. At each organization, a key informant whose experience there spanned the 10-year study period was interviewed about changes over time and was asked to review the results and interpretations. Inter- views were recorded and 214 pages of transcripts were produced. Data Coding Our coding and analysis approach (see Appendix F for details) involved coding data (text from the raw transcripts), analyzing data from the coded transcripts, and iterating between qualitative and quantitative analyses to enhance the reliability of conclusions (Eisenhardt 1989). One author first read the interview transcripts and created narratives of indiv- idual projects, describing the project’s context, how it unfolded, and the outcomes from participant perspectives. All authors then discussed each narrative and developed a coding scheme for the constructs (based on Figure 1) (Eisenhardt and Graebner 2007; Miles and Huberman 1994). Data collection and analyses were iterative. Before the 2010 interviews, all authors discussed the projects studied until then (A1–A5 and B1–B4), which led to clarification questions (Langley 1999; Weick 1995). After these interviews, summaries of the latest projects were created.

In the first step of coding, we (1) identified each quote as pertaining to the early, middle, or late stage of the project; (2) identified the planning and control mechanisms used in each stage of each project; and (3) rated each project’s suc- cess as low, moderate, or high. For example, we coded outcome, behavior, clan, and self-control mechanisms (similar to Kirsch 1997), considering specification and evaluation aspects, and project success, considering the extent to which stakeholder expectations were met (Hughes et al. 2017).

Next, based on expected sensegiving and sensemaking poten- tial for each project planning and control mechanism 4 (see Table 1 and Appendix A), and viewing the use of more mechanisms as adding to the overall sensegiving or sense- 4High, moderate, and low potential ratings were coded as 1, 0.5, and 0, respectively. MIS Quarterly Vol. 43 No. 2/June 2019655 Jenkin et al./Mutual Understanding in IS Development Table 2. Summary of Projects Project Description TimelineInformants*:

Total (Primary) Roles of Informants A1Implemented technical feature to support installation functionality. (Paired with A3)Jan.–Dec.

20014 (2) Project Manager, Programmer, Vice President, Product Manager A2Moved core product to a new technology base and architecture to support future usability enhancements. June 2002– Feb. 20034 (2) Project & Department Manager, Team Lead, Vice President, Product Manager A3Addressed many issues that arose from the newly implemented installation functionality (i.e., from project A1) including lack of breadth and integration, and usability issues. (Paired with A1)Oct. 2002– March 20035 (3) Project Manager, Team Lead and Programmer, Product Designer, Vice President, Product Manager A4Involved porting desktop functionality of a legacy product to the web. (Paired with A5)Oct. 2002– May 20035 (3) Project Manager, Team Lead, Product Designer, Vice President, Product Manager A5Involved enhancing web and desktop functionality. Originally included in project A4, but later removed and made into a separate project. (Paired with A4)Feb.–Sept.

20037 (5) 2 Project Managers, 2 Program- mers, Product Designer, Vice President, Product Manager A6Added several specific features to Alpha’s flagship product. (Paired with A7)Sept. 2008– Aug. 20095 (4) 2 Product Designers, Program- mer, 2 Technical Writers A7Major overhaul of Alpha’s flagship product, including new features and updates to existing features. (Paired with A6)Aug. 2009– Aug. 2010 5 (4) 2 Product Designers, Program- mer, 2 Technical Writers B1Involved implementing a new product for its customers, as well as new technology and business processes. (Paired with B2)Aug. 2001– May 20022 (2) Business Project Manager, IT Project Manager B2Ported legacy application onto new platform implemented in project B1. Originally included in project B1. Removed and made a separate project. (Paired with B1)Aug. 2002– April 20032 (2) Business Project Manager, IT Project Manager B3Insourced an existing customer product that was previously outsourced and implemented new business processes. Feb. 2003– Feb. 20052 (1) IT Functional Manager, Business Project Manager B4Implemented functionality to enable business units to modify their own (customer facing) applications online. March–Aug.

20042 (1) IT Functional Manager, Business Project Manager B5Implemented a third-party order management system, integrated with existing systems, and changed business processes. March–Dec.

20092 (1) IT Functional Manager, Business Project Manager B6Implemented new functionality for customer- facing application and new business processes. July–Dec.

20092 (1) Business Project Manager, IT Functional Manager *The total number of informants with whom each project was discussed is given, with the number in parentheses indicating the number of primary informants focusing on the project. Initial site visits and data collection occurred in 2004 for Alpha and 2005 for Beta. A continued relationship with both organizations and key informants enabled a second data collection in 2010.

656MIS Quarterly Vol. 43 No. 2/June 2019 Jenkin et al./Mutual Understanding in IS Development making potential for that stage (Klein and Kozlowski 2000), 5 we computed aggregated sensegiving (sensemaking) potential for each stage of each project. To measure overall sense- giving (sensemaking) for each project, we averaged sense- giving (sensemaking) across stages.

We then identified sensegiving-sensemaking episodes, the stages in which they occurred, the stakeholder groups en- gaged in them, and the localized, unidirectional, or bidirec- tional nature of the engagement. Thus, using the interview transcripts, we coded actual (versus potential) sensegiving activities and actual sensemaking activities, and then aggre- gated them to assess the levels (low, moderate, or high) and the directionality of sensegiving and sensemaking at each stage (early, middle, late) of each project. 6 The coding of the actual levels of sensegiving and sensemaking was done independently of the coding of project planning and control.

In the rest of the article, we refer to “actual sensegiving” and “actual sensemaking” as “sensegiving” and “sensemaking,” respectively. We also used the transcripts to code MU at each stage of each project as low, moderate, or high (see Appen- dices G and H for examples of the coding of each construct and an illustrative project, respectively).

Through this process, we compiled panel data for the 13 projects at three time points and project success at the end of each project. We used these data to (1) identify relationships across constructs based on regressions and (2) develop visual displays across time for all projects at each organization, which helped us identify patterns (see Figures 3 and 4). Quantitative Analyses and Results As mentioned previously, we conducted exploratory quanti- tative analyses to obtain initial insights into the relationships among constructs. These analyses include correlations and ordinal regressions (see Appendix I for a discussion and detailed results). Regressions using project-level data suggest that MU has a direct effect on project success. We do not posit this well- accepted (Aladwani 2002; Gregory et al. 2013) effect because the qualitative analyses provide more nuanced and richer insights, as discussed later. Regressions using stage-level data, with sensegiving, sensemaking, and MU as dependent variables, suggest that the actual sensegiving (sensemaking) during a stage depends on sensegiving (sensemaking) poten- tial and the actual sensemaking (sensegiving) during that stage, and that MU during a stage depends directly on sensemaking but not on sensegiving. These results suggest the following proposition, which also emerges clearly from the qualitative analyses:

P1: Sensemaking directly affects the level of MU, but sensegiving affects the level of MU indirectly, through sensemaking. Qualitative Analyses and Results The qualitative analyses included three broad steps. First, we reviewed the project narratives, and the coded text and episodes, to summarize each project in a data display and examine the patterns of change in MU within projects.

Second, we identified four “paired projects” (B1–B2, A1–A3, A4–A5, and A6–A7) and examined patterns of change across them. Two projects were considered a “pair” if (1) they involved the same overall system and (2) the second project built on the first, using overlapping resources. Third, to see if these patterns were observed elsewhere, we examined changes across all projects at each organization using data displays and transcripts.

We considered the rich insights revealed by the qualitative analyses in light of the initial model, the literature, and the results of the exploratory quantitative analyses. We con- cluded the qualitative analyses once the emergent model and propositions were consistent with the data and the incremental improvement from further analysis or studying other projects seemed minimal.

Changes Within Projects To identify patterns across projects in terms of MU and project success, we created two 3-by-3 matrices. As recom- mended by Monge (1990), 7 we used one matrix (Figure 5) to 5We computed the sensegiving (sensemaking) potential for control (and similarly for planning) for each stage by adding the potential of all control mechanisms used in that stage. For example, if a project used outcome and behavior control, but not clan or self-control, in a stage, the sensegiving potential through control would be 0.5 (moderate potential for outcome control) plus 0.5 (moderate potential for behavior control) divided by four (because of the four control types), that is, 0.25. The sensegiving potential for each stage of each project was computed by summing the sensegiving potential for control and for planning.

6To assess interrater reliability, we employed an independent judge to code two projects. For categorical data (mechanisms), Cohen’s Kappa was 1.00 (100% agreement); for ordinal data (low, moderate, high), intraclass corre- lation was 0.91, indicating excellent agreement (Cicchetti 1994) 7Monge also discusses the positive or negative trend of the change. No project in this study involves a drop in MU. Thus, the trend is positive, but with different magnitudes, in all projects. MIS Quarterly Vol. 43 No. 2/June 2019657 Jenkin et al./Mutual Understanding in IS Development Figure 3. Evolution of Projects at Alpha 658MIS Quarterly Vol. 43 No. 2/June 2019 Jenkin et al./Mutual Understanding in IS Development Figure 4. Evolution of Projects at Beta Figure 5. Changes in Mutual Understanding Within Projects MIS Quarterly Vol. 43 No. 2/June 2019659 Jenkin et al./Mutual Understanding in IS Development Figure 6. Mutual Understanding and Project Success examine projects based on the initial MU level (low, moder- ate, high) and the magnitude of change (low, moderate, high) in MU during the project. We used a second matrix (Figure 6) to classify projects based on success and average MU. We also used detailed data displays for the projects in Alpha (Figure 3) and Beta (Figure 4). These analyses led to the patterns discussed next.

Pattern 1 included three projects that were highly successful with a high level of average MU: A3 and A4, which started with and maintained a high level of MU (Pattern 1a), and A2, which started with a moderate level of MU that quickly rose to high (Pattern 1b). Sensegiving and sensemaking were con- sistently at moderate to high levels, which are needed to maintain MU at high levels. Throughout each project, the stakeholders in sensegiving-sensemaking episodes tended to be from within the same functional group (Figure 3), with some unidirectional across-group (IT to business, or vice versa) engagement. All three projects were based on existing products and knowledge, reducing uncertainty and the need for bidirectional engagement. For example, A4 replicated existing desktop functionality on the web. The low uncer- tainty enabled comprehensive planning early in the project.

Projects A3 and A4 involved emergent learning in later stages based on feedback from testing and demonstrations to customers.

Furthermore, projects in this pattern used mechanisms such as user experience and design documents, prototypes, and demonstrations to enable sensegiving and sensemaking throughout the duration of the project. For example, through user experience documents, product designers in A4 were able to give sense to programmers, who in turn used this document to make sense of what needed to be developed.

Creating the prototype during planning helped the lead pro-grammer make sense of the product design. In later stages, the prototype served as an outcome control mechanism and enabled sensegiving to other programmers. The use of planning and control mechanisms with greater potential for sensegiving and sensemaking improved sensegiving and sensemaking, and the sensemaking helped maintain a high level of MU, as expected (Figure 1) and supporting P1. 8 The following comment from A2’s team lead illustrates the support for P1:

We had a good clear design and we knew what we wanted to do and we did it with ease … came into the project with a good design note and then we ran with it … I can show you what it looked like before and what it looks like after and you would just drop your jaw. Wow, that is product A?

Pattern 2 contrasts Pattern 1: it is located in the low-low quadrant of both matrices in Figures 5 and 6. Projects following this pattern (B3, B4) began with low levels of MU and did not show much improvement. Although MU developed in some respects (e.g., objectives and require- ments), it deteriorated in others (e.g., feasibility and status).

Figure 4 shows the low levels of sensegiving, sensemaking, and MU throughout (P1), and the impact on project success.

At first glance, both B3 and B4 appear to “follow the rules” of project management at Beta, employing comprehensive planning and both behavior and outcome controls. The plan- ning and control mechanisms used in each project implied moderate sensegiving and sensemaking potential. However, 8For simplicity, henceforth we identify the relevant proposition (e.g., P1) in parentheses.

660MIS Quarterly Vol. 43 No. 2/June 2019 Jenkin et al./Mutual Understanding in IS Development the potential sensegiving (sensemaking) failed to convert into a correspondingly moderate level of sensegiving (sense- making). Several factors contributed to this failure. In both projects, plans lacked detail, limiting the shared information and initial sensegiving. Also, stakeholders in both projects used gate reviews and testing as rituals and failed to disclose technical issues during gate reviews. This led to minimal sensegiving, or rather sensehiding, in the middle of both projects, and late into B3. Relating this to sensegiving- sensemaking episodes (Figure 2), we conceptualize the extent to which stakeholders share information as the depth of stakeholder engagement and suggest that the conversion of potential sensegiving (sensemaking) to sensegiving (sense- making) within an ISD project improves with the depth of stakeholder engagement, which leads to the following proposition:

P2a: The conversion of sensegiving (sensemaking) potential from planning and control mechanisms to actual sensegiving (sensemaking) in an ISD project increases with an increase in the depth of stake- holder engagement.

As a result of the reduced sensemaking in Pattern 2, MU was not developed sufficiently in these projects (P1). Project objectives were not fulfilled, and both projects were seen as failures.

Projects in Patterns 3–5 had moderate levels of average MU but differed in their degree of improvement and project success. Pattern 3 started with low MU but experienced a considerable increase (A7, B1, B5). In contrast to Pattern 1, all three projects started with uncertainty. For example, B1 involved implementing both new IT and new business pro- cesses, which influenced sensegiving and sensemaking as well as patterns of who was giving sense and who was making sense. Either sensegiving or sensemaking, or both, started at moderate levels and increased to higher levels later in each project. Sensegiving-sensemaking episodes occurred both across groups (usually bidirectional between IT and business) and within groups (a mix of unidirectional, e.g., management to staff, and bidirectional, e.g., between staff and management) (Figures 3 and 4). These patterns reflect project stakeholders’ efforts to reduce uncertainty and develop MU.

But these efforts caused turmoil, as illustrated by this remark from A7’s designer:

We had two distinct phases: the introduction of the new process and the churn that followed where there was a lot of strain in relationships between the team—between and within the team. We had the development manager who really didn’t understandhis role in the new process. The team was under the understanding that they no longer needed the devel- opment manager’s guidance or decision-making.

That led to a lot of churn.

Projects in Pattern 3 employed comprehensive planning early, followed by emergent planning later. Projects A7 and B5 used numerous outcome control mechanisms (e.g., prototypes and templates) to enable sensegiving and sensemaking. Clan control was employed early or midway through the projects to cope with change, which contributed to the high level of sensemaking. The uncertainty created by the introduction of new technology and processes in B1 resulted in weak outcome controls early in the project. The team had limited ability to fill in the missing details, which impeded sense- making initially. A7 also suffered from a lack of outcome control early on because the project’s start coincided with the introduction of a new organization-wide development methodology, causing turbulence. However, sensegiving and sensemaking were consistently at higher levels later in these projects, related to the use of control mechanisms and emergent planning, as well as the depth of stakeholder engagement (information shared) (P2a).

Pattern 3 highlights the value of bidirectional stakeholder engagement in sensegiving-sensemaking episodes when MU is initially low, in this case, due to project uncertainty. The bidirectional nature of stakeholder engagement across groups enabled iterative sensegiving and sensemaking. This indi- cates that the scope of engagement (i.e., the number of groups giving sense and the number of other groups making sense) is also important in the conversion of potential sensegiving (sensemaking) to actual sensegiving (sensemaking) in ISD projects, which leads to the following proposition:

P2b: The conversion of sensegiving (sensemaking) poten- tial from planning and control mechanisms to actual sensegiving (sensemaking) in an ISD project increases with an increase in the scope of stake- holder engagement. Thus, in Pattern 3, the greater depth (P2a) and scope (P2b) of engagement led to greater sensegiving and sensemaking and increased MU, overcoming initial uncertainty (P1). Pattern 4 is similar to Pattern 3: both began with low MU and achieved moderate average MU. However, projects in Pattern 4 (A1, A5, B2, B6) encountered only a moderate level of improvement in MU. Pattern 4 includes two types: 4a (A1, A5) and 4b (B2, B6).

In Pattern 4a, sensegiving and sensemaking were delayed until late in the project, which is related to the lack of plan- MIS Quarterly Vol. 43 No. 2/June 2019661 Jenkin et al./Mutual Understanding in IS Development ning and minimal use of control mechanisms. Compared to Pattern 3, fewer mechanisms to support sensegiving and sensemaking were used, and those that were used were either incomplete, containing few details (i.e., low depth of stake- holder engagement), or developed late in the project. Also, sensegiving-sensemaking episodes began later in the project, initiated in both projects by testers (staff). Thus, staff played a key role in giving sense in Pattern 4a. For example, testers in A5 were trying to figure out what to test based on the existing user experience document, which was incomplete.

Aiming to better understand the expected functionality, the testers requested clarification from the product designer, initiating an iterative cycle of sensegiving and sensemaking that included the product designer and the programmer, all staff roles. At this point, the programmer began creating a matrix of functionality options, which enabled sensemaking.

Most sensegiving-sensemaking episodes in A1 and A5 occurred within group, either localized (staff to staff) or unidirectionally from staff to managers. Thus, the depth and scope of engagement were low, as were sensegiving and sensemaking (P2a, P2b).

In Pattern 4b (B2, B6), sensegiving-sensemaking episodes tended to occur bidirectionally both within (between staff and management) and across (between IT and business) groups.

As shown in Figure 4, planning and control mechanisms were employed throughout. Thus, these projects appeared to follow the rules, similar to Pattern 2. However, both projects failed to include a key stakeholder group at some stage (i.e., they had a low scope of engagement). For example, in B6 a key stakeholder group (senior sales representatives) was not included in the decision to turn off the old system. Despite the planning and control mechanisms employed, both projects achieved only a moderate level of sensemaking, reducing MU (P1).

Pattern 5 is similar to Pattern 1: both had low improvement in MU. But unlike the high level of initial MU in Pattern 1, the project in this pattern (A6) had moderate initial MU and, like Patterns 3 and 4, moderate average MU. Similar to Patterns 2 and 4b, A6 appeared to follow the rules, employing planning and control mechanisms throughout. It included sensegiving-sensemaking episodes that were unidirectional within and across groups, from the business or IT manager to IT staff. Thus, the voice of the staff was not included (limited scope of engagement), hindering the conversion of potential sensegiving (sensemaking) to actual sensegiving (sense- making) (P2b), which was at low to moderate levels through- out. Improvement in MU was limited because of the low sensemaking (P1). The following remark by the A6 designer is illustrative:

No clear understanding by the team as to why cer- tain things were being done with the priority theywere being done. And in the way they were being done. Further Analysis of Patterns All the projects in Patterns 3, 4, and 5 had moderate average MU, but the relationship between MU and success varied across projects as shown in Figure 6. For example, B5 (Pattern 3) was similar to B2 (Pattern 4b) as both had moderate average MU and a high level of success, whereas the other projects in these patterns experienced only moderate success. The similarities between B5 and B2 provide insights into what led to project success despite moderate average MU. Both projects had low initial MU due to uncertainty but had bidirectional stakeholder engagement (high scope) within and across groups, and the planning and control mechanisms used in sensegiving-sensemaking episodes shared detailed information (high depth of engagement). Moreover, similar to Pattern 1, both projects had high sensegiving early in the project because of the planning and control mechanisms employed at that time. This highlights the importance of early engagement, as shown in the following proposition: P2c: The conversion of sensegiving (sensemaking) potential from planning and control mechanisms to actual sensegiving (sensemaking) in an ISD project increases with earlier timing of stakeholder engagement.

Furthermore, the timing, depth, and scope of stakeholder engagement allowed B2 and B5 to overcome uncertainty and succeed despite low initial MU. In contrast, the only two projects (A3, A4) that started with high MU were highly successful, suggesting that project success may be related to the timing of MU development, specifically, the earlier, the better. A2, the remaining successful project, started with moderate initial MU that quickly rose to a high level. The relationships among the timing of MU, stakeholder engage- ment, and project success leads to the following emergent proposition:

P3: Projects with higher initial MU have a greater likelihood of success. However, if initial MU is low, better stakeholder engagement (in terms of depth, scope, and timing) enables an increase in MU and subsequently greater project success.

As the central quadrant in Figure 6 shows, five projects (across Patterns 3 (A7, B1), 4a (A5), 4b (B6), and 5 (A6)) were moderately successful and had moderate average MU.

A6 started with moderate MU, whereas the other projects had low initial MU but experienced at least moderate improve- ment to increase MU later in the project. 662MIS Quarterly Vol. 43 No. 2/June 2019 Jenkin et al./Mutual Understanding in IS Development The moderate success of B6 can be understood by comparing it to B2 and B5. In B2 and B5, all key stakeholders were involved in comprehensive planning. Both projects were considered highly successful, despite the exclusion of some stakeholders in the middle of B2. However, in B6, senior sales reps were excluded from the start until they voiced their concerns late in the project. This led to the reversal of the earlier decision to turn off the old system, requiring extensive post-implementation workarounds. Thus, a low initial scope of engagement reduced early sensegiving in contrast to the high levels early in B2 and B5. This further highlights the importance of early stakeholder engagement when MU is initially low (P3).

Despite low to moderate sensegiving and sensemaking and only localized within-group stakeholder engagement, A5 achieved moderate success. MU was developed later in the project once staff members engaged in within-group sense- giving and sensemaking. This MU was translated into the product, enabling moderate project success. However, in A1, sensemaking was low until the late stages and by the time MU increased, it was too late to benefit the project, resulting in a low level of success. A1 was considered a failure, as reflected in the comments of its project manager:

We knew there were shortcomings with the tech- nology. Some of it came out of testing. Some reports opened our eyes to other shortcomings we hadn’t considered … it wasn’t successful from a customer satisfaction point of view.

This comparison between A5 and A1 further demonstrates the importance of timing (P2c, P3). A5 initiated iterative sensegiving-sensemaking episodes in time to increase and act upon MU to achieve moderate success. A1 was too late.

Although earlier is better, being late, but not too late, may allow project stakeholders to salvage some degree of project success. Changes Across Projects We examined the changes across projects by analyzing pro- ject pairs with participants and systems in common (A1–A3, B1–B2, A4–A5, and A6–A7). Our findings indicate that project management mechanisms (planning and control), stakeholder engagement (timing, depth, and scope), and MU all changed across projects as influenced by the factors identified in our analysis (see Table 3). These changes ranged from deterioration to improvement, with some project pairs showing little change. Learning occurs when project team members reflect on their experiences in one project and hence do things differently in the next project. Moreover, learningfrom previous projects can lead to either improvement or deterioration in subsequent projects, whereas a lack of learning always leads to deterioration. We found evidence of experiential learning that resulted in improvements in the second project for three of the pairs (A1–A3, A6–A7, B1–B2). As depicted in Figure 4 and Table 3, pair B1-B2 experienced improvements in the use of planning and control mechanisms. For example, business and IT project stakeholders learned the importance of project controls from problems experienced in B1 and used them to a greater extent in B2 (e.g., gate reviews, testing controls for financial transactions, detailed requirements, and documenta- tion). The result was a greater depth of stakeholder engage- ment, which contributed to B2’s success.

Pair A6–A7 experienced improvements in planning and control mechanism use and stakeholder engagement. For example, unlike A5, which lacked planning, and A6, which relied only on comprehensive planning, A7 started with com- prehensive planning and then shifted to emergent planning.

Again, unlike A5 and A6, which had localized or unidirec- tional within-group stakeholder engagement and low levels of sensegiving and sensemaking, A7 involved bidirectional engagement within and across groups (i.e., greater scope of engagement) and thereby greater sensegiving and sense- making. Using their knowledge of the issues with the prior approach, the A7 team adapted the new methodology and improved the mechanisms for planning (emergent) and con- trol (daily stand-up meetings), seeking better information (reflecting greater depth of engagement). A7 ended up as moderately successful, similar to A6, but with high MU.

Pair A1–A3 showed improvement in planning and control mechanism use, stakeholder engagement, and MU. For example, more stakeholders (e.g., customer, quality assurance (QA) personnel, and product designer) were engaged in sensegiving-sensemaking episodes in A3, and these episodes occurred throughout the project, not just at the end. In using the same technology and requirements, the MU developed in A1 was carried over to A3, resulting in a higher level of MU at the start of the project. Unlike A1, A3 was considered highly successful.

In the preceding examples, participants in the second project learned from problems encountered in the first and experi- enced improvements in at least one of the following: project management mechanism use, stakeholder engagement, and MU among stakeholders. However, we also found a case of deterioration. Although it appears from Table 3 and Figure 4 that stakeholder engagement improved from B1 to B2, it instead deteriorated. There was greater emphasis on across- group stakeholder engagement in B1; however, business-side MIS Quarterly Vol. 43 No. 2/June 2019663 Jenkin et al./Mutual Understanding in IS Development Table 3. Changes Across Projects in Project Pairs* stakeholders perceived IT’s attempts to control changes in scope as political. This resulted in a shift to more within- group stakeholder engagement for both groups in B2 as each attempted to protect its position. Based on the problems in B1, business and IT stakeholders learned how to maneuver politically in B2, which led to cautious sharing of information across groups, resistance by the business to sign off on deliverables, and more within-group engagement to plan negotiations and escalations. Business and IT stakeholders sought safety within their groups in B2, limiting exposure to across-group interactions. Disagreements between business and IT stakeholders adversely affected stakeholder engage- ment in the subsequent project. Therefore, we propose:

P4a: The extent of across-project learning (in terms of project management mechanisms, stakeholder engagement, and MU) increases with a decrease indisagreements across stakeholder groups in the first project.

The learning that occurred among stakeholder groups from B1 to B2 may have extended beyond these projects to the broader business and IT groups, affecting stakeholder engagement in B3 and B4. This may explain the ritualized use of control mechanisms and sensehiding in B3 and B4. Thus, learning by stakeholders may have dysfunctional effects on subsequent projects.

We also found that the introduction of new project elements, such as business processes, requirements, technology, or methodology, in the second project influences whether project management mechanisms, stakeholder engagement, and MU improves or deteriorates. In contrast to A1–A3, where MU improved, the other three project pairs (A4–A5, A6–A7, 664MIS Quarterly Vol. 43 No. 2/June 2019 Jenkin et al./Mutual Understanding in IS Development B1–B2) experienced a deterioration in MU. A1–A3 did not include new project elements, but the other project pairs did.

For example, a new organization-wide system development methodology was introduced at the start of A7, creating the need to understand these new processes. The result was lower initial MU than at the end of A6. Therefore, we propose:

P4b: The extent of across-project learning (in terms of project management mechanisms, stakeholder engagement, and MU) increases with a decrease in the extent to which new project elements are introduced in the second project.

Project pair A4–A5’s deterioration in stakeholder engagement and use of planning and control mechanisms was dramatic compared to the other observed instances of deterioration. A4 was a notable success and, having been the first project to implement a new, more formal agile methodology at Alpha, was viewed as an exemplar. Project A5 directly followed A4; it was spun off of A4 because of A5’s extensive scope.

However, A5 failed to apply what should have been learned from the positive experiences in A4. The project was under- scoped and misunderstood, with an unclear, uncertain set of requirements. Rather than applying the new structured and well-organized approach used in A4, A5 appeared to revert to how projects were run before A4. A5 had no planning, mini- mal controls, and localized within-group stakeholder engage- ment late in the project, reflecting later timing and lower scope and depth of stakeholder engagement; the project was described as chaotic and a failure. Comparing A4–A5 to the other project pairs (see Table 3), we found that this pair was the only one in which the first project was highly successful. Participants in the other three project pairs openly discussed the problems in the first project and the corresponding improvements in the second project. In con- trast, for A4–A5, participants spoke about how well A4 went and how poorly A5 went. Having challenges in a project may trigger project team members to reflect and make sense of what went wrong and how to improve in the next project.

However, A4 was very successful and well executed, but no reflection on why it was successful occurred. As a result, the improvements made in A4 were not internalized by project team members and replicated in A5, a learning failure.

Another reason for this lack of reflection appears to be related to stress from time pressure and resource constraints. A project manager from A5 commented:

The whole development process seemed to be pushed aside because of the time constraint and the resource constraint.The new project elements introduced on A5 contributed further to this stress and lower initial MU. Stakeholder groups focused sensemaking on the new project elements, not on how to adopt A4’s successful approach. This suggests the following emergent proposition:

P4c: The extent of across-project learning (in terms of project management mechanisms, stakeholder engagement, and MU) increases with an increase in the extent to which project participants in the second project reflect on the first project. Discussion In this article, we seek to provide insights into how the MU among project stakeholders changes over time within a project, and how MU changes across projects. We integrate the previously disconnected argument about the effects of project planning and control mechanisms (e.g., Tiwana and Keil 2009; Wallace et al. 2004) and cognitive activities (sensegiving, sensemaking) (e.g., Davidson 2002; Gregory et al. 2013) on MU. The implications of the emergent model, summarized in Figure 7, for theory and practice are elaborated next.

Implications for Theory This article contributes to knowledge about ISD project management in five ways. First, it provides insight into how MU among stakeholders changes during a project through cognitive activities. Specifically, improvisational learning, which occurs in response to an emergent problem (e.g., Miner et al. 2001), can lead to changes in MU during a project. For example, when significant issues were identified midway through project A5, the product designer and programmer used a nonstandard artifact (matrix of functionality) to make sense of the requirements and flesh out the details. By recog- nizing the emergent issues and collaboratively using artifacts to give and make sense, these staff also made sense of recently introduced planning and control mechanisms, rather than mindlessly following an apparent standard. Another example of improvisational learning was the way the A5 team split up the timing of the product release, which included providing an early beta to some customers to meet their time- sensitive need for access to new product features. The A7 project team also displayed improvisational learning in their response to a methodology change. Although it was a chal- lenging experience, the resultant learning improved the outcomes for A7. MIS Quarterly Vol. 43 No. 2/June 2019665 Jenkin et al./Mutual Understanding in IS Development Figure 7. Emergent Model Second, this article extends prior work on the relationship between project planning and control mechanisms and MU (e.g., Kirsch 2004) and on the importance of MU for project success (e.g., Gregory et al. 2013) by proposing a causal logic for these relationships. Specifically, we argue that project planning and control mechanisms possess different levels of sensegiving and sensemaking potential and that the use of mechanisms with greater potential enables the cognitive activities of sensegiving and sensemaking. Qualitative and quantitative results support these arguments. However, the conversion of sensegiving (sensemaking) potential to actual sensegiving (sensemaking) depends on stakeholder engage- ment. Also, the exploratory quantitative analysis suggests that the level of MU affects project success, and the qualita- tive analysis provides richer insights into this relationship, highlighting the importance of (1) achieving MU early in the project and (2) attaining stakeholder engagement. Third, this article offers a rich conceptualization of stake- holder engagement—in terms of depth, scope, and timing—as reflecting the nature of stakeholders and their interactions as they give and make sense within projects. Together, these three dimensions of stakeholder engagement help explain why the conversion of the sensegiving (sensemaking) potential ofplanning and control mechanisms to actual sensegiving (sensemaking) is not necessarily frictionless (P2) and how success can be achieved despite low initial MU (P3).

The depth of stakeholder engagement refers to the amount of information shared via planning and control mechanisms.

Low depth of engagement is related to the concepts of rituals and deception from the ISD literature. The literature (Robey and Markus 1984; Wastell 1999) has discussed how the use of rituals by developers as a defense mechanism leads to negative outcomes. Ritually creating an artifact to adhere to the ISD methodology and avoid blame for issues that may arise leads to fewer details being shared, limiting the depth of engagement and inhibiting sensegiving or sensemaking.

Moreover, deception as a kind of political action has been studied in ISD projects (Sabherwal and Grover 2010). Our results suggest that deception, or sensehiding, may be a defense mechanism to buy time to fix issues or to avoid blame if the project fails. In sensehiding, certain viewpoints are silenced or marginalized, or information is withheld to manage individuals’ interpretations (Vaara and Monin 2010).

Previous work recognizes the importance of “who” is engaged in an activity (e.g., Boland and Tenkasi 1995; Markus and 666MIS Quarterly Vol. 43 No. 2/June 2019 Jenkin et al./Mutual Understanding in IS Development Mao 2004). For example, Markus and Mao (2004) recom- mend that participation research examine the relative propor- tion and structural positions of stakeholder groups. The current article extends research that focuses on the breadth of engagement (i.e., the number of engaged individuals; Liz- arondo et al. 2016), by examining the scope of engagement.

Scope incorporates both (1) the number of engaged groups (functional and structural positions of stakeholders), that is, who is giving and making sense, and (2) the directionality of information flow, that is, whether it is localized within a group, or unidirectional or bidirectional within or across groups. Our findings indicate that both these aspects of scope matter. If sensegiving and sensemaking are localized within a group (e.g., only between staff) or unidirectional within or across groups (e.g., from business to IT), the development of MU across stakeholders would be inhibited by some perspec- tives being ignored. Bidirectional engagement across groups seems to be especially important when initial MU is low (e.g., P3). However, if sensegiving and sensemaking occur exclu- sively across groups (e.g., between business and IT), this would inhibit the deepening of each group’s understanding before (Boland and Tenkasi 1995) and exploration during (Nidumolu 1996) this interaction. Bidirectionality both with- in and across groups is important, allowing stakeholders to consider each other’s interpretations. Directionality can also help shed light on other aspects of ISD projects, such as user involvement (Newman and Noble 1990).

The timing of stakeholder engagement, specifically, earlier engagement, helps develop initially low MU and leverage the sensegiving (sensemaking) potential of planning and control mechanisms. Thus, the timing of engagement matters: the sooner, the better. Examining the timing of events is impor- tant in process research (Van de Ven 2007). For example, prior research has explored how the choice of control mech- anisms changes during a project based on factors such as uncertainty, project performance, and stakeholder interactions (Choudhury and Sabherwal 2003). This article contributes to the ISD literature by indicating that the timing of stakeholder engagement plays an important role in addition to depth and scope.

Overall, engagement may be useful in examining not only cognition and user involvement in ISD projects but also gamification (Liu et al. 2017) and other IT contexts involving interactions over time. Moreover, this article shows that integrating engagement (and its three dimensions) with cogni- tive activities (sensegiving and sensemaking) enables a richer conceptualization of ISD projects than using either construct alone.

Fourth, this article explores artifacts, which may be used in project planning and control, and their effects on cognition.The qualitative analyses suggest that artifacts used in planning and control, such as demos, prototypes, user experience docu- ments, and macro stories, play an important role in sense- giving and sensemaking. For example, user experience documents served as outcome controls and were used by product designers to give sense to programmers. 9 Prior studies have examined how stakeholders use artifacts (e.g., wireframes) to arrive at the final ISD design (Levina 2005) and how material practices involving artifacts (e.g., idea boards) support the collective sensemaking for new product design (Stigliani and Ravasi 2012). The Project Management Office (PMO) literature also highlights the value of em- bedding knowledge in artifacts such as templates and method- ologies (Julian 2008; Liu and Yetton 2007). We extend this work by studying how artifacts, as planning and control mechanisms, differ in their sensegiving (sensemaking) poten- tial and thereby support cognitive activities in ISD projects.

Fifth, this article focuses on changes across projects. Our findings suggest that aspects of an ISD project may differ from those of prior project(s) because of experiential or vicarious learning, 10 as discussed in the ISD context (Boh et al. 2007; Peng et al. 2013) and in organizations in general (Argote and Miron-Spektor 2011). However, a failure to learn from experience, as observed in project pair A4–A5, has also been identified in both the ISD (e.g., Lyytinen and Robey 1999) and broader management (e.g., Edmondson 2002) literatures. The PMO literature highlights the difficulty in learning across projects (Julian 2008; Müller et al. 2013) and the PMO’s role in facilitating such learning (Julian 2008; Liu and Yetton 2007). In this article, changes across projects often led to improvements, but a deterioration was observed in some cases, influenced by (1) disagreements between stakeholders in the first project, (2) incorporation of new project elements in the second project, and (3) lack of reflection in the second project.

This article suggests that disagreements between stakeholders may lead to learning at the stakeholder level but dysfunctional effects at the project level. Groups may learn from experience in a way that fulfills their goals, but not those of the project.

For example, sensehiding across groups and ritual use of control mechanisms in both B3 and B4 may have been the result of knowledge being transferred from the stakeholder 9Moreover, demos were used in A4, A6, and A7 to give sense and enable sensemaking. Prototypes enabled sensemaking by the lead programmers in A2 and A4. User experience documents and macro stories helped sense- giving and sensemaking in A3, A4, A6, and A7.

10For example, learning from A1 resulted in improved use of planning and control mechanisms in A3.

MIS Quarterly Vol. 43 No. 2/June 2019667 Jenkin et al./Mutual Understanding in IS Development groups in B1 and B2 to the broader IT and business groups.

Thus, project stakeholders vicariously “learned” from stake- holders in prior projects that withholding knowledge may help their groups but to the detriment of their projects.

Understanding how the incorporation of new project elements affects across-project learning is related to IS research on how experience with similar tasks and systems affects learning (e.g., Boh et al. 2007). Although similar tasks and systems may enable learning, introducing new elements may be equally important to a project’s success. We find that new project elements, for example, new requirements or method- ologies, may trigger the need to make sense of them.

Sensegiving-sensemaking episodes supported by high-quality stakeholder engagement can result in improvements. This is consistent with prior findings (Liu and Yetton 2007) that a PMO has a greater impact on across-project learning in situations that involve greater change. Thus, greater support for learning, including high-quality stakeholder engagement, is needed when new project elements are introduced.

Lack of reflection on experience has been noted as a reason for learning failure (Edmondson and Nembhard 2009). Rea- sons for lack of reflection include time constraints and lack of psychological safety (Edmondson 2002). Related to this lack of reflection is organizational forgetting, that is, the inability to retain created knowledge (de Holan and Phillips 2004).

According to the PMO literature, projects often focus on “red light” learning or learning from problems, which may inhibit learning from successes (Julian 2008). Our results suggest that reflection on the earlier project may be less likely when that project was a success, resulting in forgetting.

Implications for Practice Our results have several potential implications for practice.

First, the emergent model provides insights that can help develop MU among project stakeholders and enhance ISD success. It suggests that managers should focus on cognitive activities that lead to MU. Specifically, it indicates the impor- tance of emphasizing both sensegiving and sensemaking activities; pursuing one of these activities at the expense of the other is counterproductive because sensemaking depends on sensegiving and directly enables MU.

Second, this article suggests that planning and control mech- anisms are two important levers that project managers can deploy to promote sensegiving and sensemaking. Specifi- cally, using artifacts, such as prototypes and user experience documents early and demonstrations later, can help promote higher levels of sensegiving and, in turn, sensemaking.Third, this article indicates that project managers should plan for stakeholder engagement, using the broader view of engagement. That is, managers should pay attention not only to the depth of engagement but also to its timing, and recog- nize the importance of bidirectional stakeholder engagement both within and across groups. They should also monitor stakeholder engagement and use mechanisms to avoid or quickly address (e.g., through an anonymous mechanism for whistle-blowing) dysfunctions such as rituals and deception.

Fourth, insights into the patterns of MU change and their links to project success can be of value to managers. Periodic assessment of MU among key stakeholders can serve as a valuable tool in diagnosing potential issues and identifying mechanisms to increase MU. This will allow project man- agers to target specific mechanisms and engage appropriate stakeholders. Although our findings suggest that earlier is better, they indicate that late recoveries are also possible and illustrate potential ways (e.g., the functionality matrix in A5) to achieve them.

Finally, although organizations may employ project planning and control mechanisms, these mechanisms should be updated to prevent deterioration in MU due to issues such as organiza- tional forgetting and dysfunctional consequences from disagreements. Assessing such risks can enable managers to take mitigating actions. The results suggest that managers should recognize when improvisational learning is beneficial and encourage its use, especially as improvisation may be seen as antithetical to project management. Limitations The study’s findings should be viewed in light of its limita- tions. First, the core business of both focal organizations (Alpha and Beta) involved IT products and/or services.

Further research is needed to examine whether the findings apply to projects from non-IT organizations. Second, the informants provided retrospective accounts during each data collection period. We partly addressed this by developing ongoing relationships with key informants, whom we con- tacted for updates between visits, and by focusing on recently completed projects. Third, we did not use objective measures of the focal constructs. Instead, ratings were based on the informants’ perceptions. Measuring cognitive constructs raises additional challenges, which we tried to address by using multiple informants for each project in each period.

Fourth, this study focused on planning and control mech- anisms, but other mechanisms, such as roles, dialogue, and other boundary objects (e.g., Majchrzak et al. 2012), may enable sensegiving and sensemaking. Further research is 668MIS Quarterly Vol. 43 No. 2/June 2019 Jenkin et al./Mutual Understanding in IS Development needed to examine the effects of these other ways to give and make sense. Finally, the sample sizes for the regression analyses were small, although the quantitative analysis was only a part of the primarily qualitative study.

Conclusion This article offers insights into the patterns of MU change, both development and deterioration, and within and across projects. The emergent model describes relationships among project management mechanisms, cognitive activities (sense- giving, sensemaking), stakeholder groups, and MU within and across projects, and how MU affects project success. Thus, this article provides insights into how project planning and control mechanisms affect MU through their influence on sensegiving and sensemaking. Although project planning and control mechanisms differ in their potential to support sense- giving and sensemaking, our results show that successfully converting this potential into actual sensegiving and sense- making is not frictionless. Stakeholder engagement and its dimensions of depth, scope, and timing help explain this relationship, as well as that between MU and project success.

We also identify potential causes of deterioration in MU, patterns of stakeholder engagement, and the use of planning and control mechanisms across projects: disagreements be- tween stakeholders in the first project, new project elements in the second project, and lack of reflection in the second project. Recognizing and understanding the cognitive chal- lenges in projects, as well as identifying ways to develop MU among project stakeholders, are important steps forward in enabling organizations and managers to achieve higher levels of project success.

References Abdel-Hamid, T. K., Sengupta, K., and Swett, C. 1999. “The Impact of Goals on Software Project Management: An Experi- mental Investigation,” MIS Quarterly (23:4), pp. 531-555.

Aladwani, A. M. 2002. “An Integrated Performance Model of Information Systems Projects,” Journal of Management Infor- mation Systems (19:1), pp. 185-210.

Argote, L., and Miron-Spektor, E. 2011. “Organizational Learning:

From Experience to Knowledge,” Organization Science (22:5), pp. 1123-1137.

Barki, H., Rivard, S., and Talbot, J. 2001. “An Integrative Contin- gency Model of Software Project Risk Management,” Journal of Management Information Systems (17:4), pp. 37-69.

Bassellier, G., Reich, B. H., and Benbasat, I. 2001. “Information Technology Competence of Business Managers: A Definition and Research Model,” Journal of Management Information Systems (17:4), pp. 159-182.Boh, W. F., Slaughter, S. A., and Espinosa, J. A. 2007. “Learning from Experience in Software Development: A Multilevel Analy- sis,” Management Science (53:8), pp. 1315-1331.

Boland, R. J., and Tenkasi, R. V. 1995. “Perspective Making and Perspective Taking in Communities of Knowing,” Organization Science (6:4), pp. 350-372.

Bowman, B., Davis, G., and Wetherbe, J. 1983. “Three Stage Model of MIS Planning,” Information & Management (6:1), pp.

11-25.

Burton-Jones, A., McLean, E. R., and Monod, E. 2015. “Theore- tical Perspectives in IS Research: From Variance and Process to Conceptual Latitude and Conceptual Fit,” European Journal of Information Systems (24:6), pp. 664-679.

Chen, D. Q., Mocker, M., Preston, D. S., and Teubner, A. 2010.

“Information Systems Strategy: Reconceptualization, Measure- ment, and Implications,” MIS Quarterly (34:2), pp. 233-259.

Choudhury, V., and Sabherwal, R. 2003. “Portfolios of Control in Outsourced Software Development Projects,” Information Systems Research (14:3), pp. 291-314.

Cicchetti, D. V. 1994. “Guidelines, Criteria, and Rules of Thumb for Evaluating Normed and Standardized Assessment Instruments in Psychology,” Psychological Assessment (6:4), pp. 284-290.

Creswell, J. W., and Clark, V. L. P. 2007. Designing and Con- ducting Mixed Methods Research, Thousand Oaks, CA: SAGE Publications.

Cronin, M. A., and Weingart, L. R. 2007. “Representational Gaps, Information Processing, and Conflict in Functionally Diverse Teams,” Academy of Management Review (32:3), pp. 761-773.

Davidson, E. J. 2002. “Technology Frames and Framing: A Socio- Cognitive Investigation of Requirements Determination,” MIS Quarterly (26:4), pp. 329-358.

de Holan, P. M., and Phillips, N. 2004. “Remembrance of Things Past? The Dynamics of Organizational Forgetting,” Management Science (50:11), pp. 1603-1613.

Edmondson, A. C. 2002. “The Local and Variegated Nature of Learning in Organizations: A Group-Level Perspective,” Organization Science (13:2), pp. 128-146.

Edmondson, A. C., and Nembhard, I. M. 2009. “Product Develop- ment and Learning in Project Teams: The Challenges Are the Benefits,” Journal of Product Innovation Management (26:2), pp. 123-138.

Eisenhardt, K. M. 1989. “Building Theories from Case Study Research,” Academy of Management Review (14:4), pp. 532-550.

Eisenhardt, K. M., and Graebner, M. E. 2007. “Theory Building from Cases: Opportunities and Challenges,” Academy of Management Journal (50:1), pp. 25-32.

Elbanna, A. 2010. “Rethinking IS Project Boundaries in Practice:

A Multiple-Projects Perspective,” Journal of Strategic Informa- tion Systems (19:1), pp. 39-51.

Flamholtz, E. G., Das, T. K., and Tsui, A. S. 1985. “Toward an Integrative Framework of Organizational Control,” Accounting, Organizations and Society (10:1), pp. 35-50.

Fredrickson, J. W. 1984. “The Comprehensiveness of Strategic Decision Processes: Extension, Observations, and Future Direc- tions,” Academy of Management Journal (27:3), pp. 445-466. MIS Quarterly Vol. 43 No. 2/June 2019669 Jenkin et al./Mutual Understanding in IS Development Gemino, A., Reich, B. H., and Sauer, C. 2007. “A Temporal Model of Information Technology Project Performance,” Journal of Management Information Systems (24:3), pp. 9-44.

Gephart, R. P. 1993. “The Textual Approach: Risk and Blame in Disaster Sensemaking,” Academy of Management Journal (36:6), pp. 1465-1514.

Gioia, D. A., and Chittipeddi, K. 1991. “Sensemaking and Sense- giving in Strategic Change Initiation,” Strategic Management Journal (12:6), pp. 433-448.

Gioia, D. A., and Mehra, A. 1996. “Sensemaking in Organiza- tions,” Academy of Management Review (21:4), pp. 1226-1230.

Gregory, W. G., Beck, R., and Keil, M. 2013. “Control Balancing in Information Systems Development Offshoring Projects,” MIS Quarterly (37:4), pp. 1211-1232.

Henderson, J. C., and Lee, S. 1992. “Managing I/S Design Teams:

A Control Theories Perspective,” Management Science (38:6), pp. 757-777.

Hughes, D. L., Rana, N. P., and Simintiras, A. C. 2017. “The Changing Landscape of IS Project Failure: An Examination of the Key Factors,” Journal of Enterprise Information Management (30:1), pp. 142-165.

Julian, J. 2008. “How Project Management Office Leaders Facilitate Cross-Project Learning and Continuous Improvement,” Project Management Journal (39:3), pp. 43-58.

Kirsch, L. J. 1996. “The Management of Complex Tasks in Organi- zations: Controlling the Systems Development Process,” Organization Science (7:1), pp. 1-21.

Kirsch, L. J. 1997. “Portfolios of Control Modes and IS Project Management,” Information Systems Research (8:3), pp. 215-239.

Kirsch, L. J. 2004. “Deploying Common Systems Globally: The Dynamics of Control,” Information Systems Research (15:4), pp.

374-395.

Klein, K. J., and Kozlowski, S. W. J. 2000. “From Micro to Meso:

Critical Steps in Conceptualizing and Conducting Multilevel Research,” Organizational Research Methods (3:3), pp. 211-236.

Langley, A. 1999. “Strategies for Theorizing from Process Data,” Academy of Management Review (24:4), pp. 691-710.

Levina, N. 2005. “Collaborating on Multiparty Information Sys- tems Development Projects: A Collective Reflection-in-Action View,” Information Systems Research (16:2), pp. 109-130.

Lind, M. R., and Zmud, R. W. 1991. “The Influence of a Conver- gence in Understanding between Technology Providers and Users on Information Technology Innovativeness,” Organization Science (2:2), pp. 195-217.

Liu, D., Santhanam, R., and Webster, J. 2017. “Towards Meaning- ful Engagement: A Framework for Design and Research of Gamified Information Systems,” MIS Quarterly (41:4), pp.

1011-1034.

Liu, L. L., and Yetton, P. Y. 2007. “The Contingent Effects on Pro- ject Performance of Conducting Project Reviews and Deploying Project Management Offices,” IEEE Transactions on Engi- neering Management (54:4), pp. 789-799.

Lizarondo, L., Kennedy, K., and Kay, D. 2016. “Development of a Consumer Engagement Framework,” Asia Pacific Journal of Health Management (11:1), pp. 44-49.

Lyytinen, K. 1987. “Different Perspectives on Information Sys- tems: Problems and Solutions,” ACM Computing Surveys (19:1), pp. 5-46.Lyytinen, K., and Robey, D. 1999. “Learning Failure in Informa- tion Systems Development,” Information Systems Journal (9), pp. 85-101.

Majchrzak, A., More, P. H. B., and Faraj, S. 2012. “Transcending Knowledge Differences in Cross-Functional Teams,” Organi- zation Science (23:4), pp. 951-970.

Mantere, S., and Ketokivi, M. 2013. “Reasoning in Organization Science,” Academy of Management Review (38:1), pp. 70-89.

Markus, M. L., and Mao, J.-Y. 2004. “Participation in Develop- ment and Implementation—Updating an Old, Tired Concept for Today’s IS Contexts,” Journal of the Association for Information Systems (5:11-12), pp. 514-544.

Miles, M. B., and Huberman, M. A. 1994. Qualitative Data Analysis: An Expanded Sourcebook, Thousand Oaks, CA:

SAGE Publications.

Miner, A. S., Bassoff, P., and Moorman, C. 2001. “Organizational Improvisation and Learning: A Field Study,” Administrative Science Quarterly (46:2), pp. 304-337.

Mintzberg, H. 1990. “Strategy Formation: Schools of Thought,” in Perspectives on Strategic Management, J. Fredrickson (ed.), New York: Harper Business, pp. 148-163.

Monge, P. 1990. “Theoretical and Analytical Issues in Studying Organizational Processes,” Organization Science (1:4), pp.

406-430.

Monin, P., Noorderhaven, N., Vaara, E., and Kroon, D. 2013.

“Giving Sense to and Making Sense of Justice in Postmerger Integration,” Academy of Management Journal (56:1), pp.

256-284.

Müller, R., Glückler, J., Aubry, M., and Shao, J. 2013. “Project Management Knowledge Flows in Networks of Project Managers and Project Management Offices: A Case Study in the Pharma- ceutical Industry,” Project Management Journal (44:2), pp. 4-19.

Nelson, K. M., and Cooprider, J. G. 1996. “The Contribution of Shared Knowledge to IS Group Performance,” MIS Quarterly (20:4), pp. 409-432.

Newman, M., and Noble, F. 1990. “User Involvement as an Inter- action Process: A Case Study,” Information Systems Research (1:1), pp. 89-113.

Nidumolu, S. 1996. “A Comparison of the Structural Contingency and Risk-Based Perspectives on Coordination in Software- Development Projects,” Journal of Management Information Systems (13:2), pp. 77-113.

Nidumolu, S. R., and Subramani, M. R. 2003. “The Matrix of Control: Combining Process and Structure Approaches to Managing Software Development,” Journal of Management Information Systems (20:3), pp. 159-196.

Orlikowski, W. J. 1991. “Integrated Information Environment or Matrix of Control: The Contradictory Implications of Informa- tion Technologies,” Accounting, Management and Information Technologies (1:1), pp. 9-42.

Peng, G., Mu, J., and Di Benedetto, C. A. 2013. “Learning and Open Source Software License Choice,” Decision Sciences (44:4), pp. 619-643.

Pinto, J. K., and Slevin, D. P. 1987. “Critical Factors in Successful Project Implementation,” IEEE Transactions on Engineering Management (34:1), pp. 22-27.

Rai, A., Maruping, L. M., and Venkatesh, V. 2009. “Offshore Information Systems Project Success: The Role of Social 670MIS Quarterly Vol. 43 No. 2/June 2019 Jenkin et al./Mutual Understanding in IS Development Embeddedness and Cultural Characteristics,” MIS Quarterly (33:3), pp. 617-641.

Robey, D., and Markus, M. L. 1984. “Rituals in Information System Design,” MIS Quarterly (8:1), pp. 5-15.

Sabherwal, R., and Grover, V. 2010. “A Taxonomy of Political Processes in Systems Development,” Information Systems Journal (20), pp. 419-447.

Sabherwal, R., and Robey, D. 1995. “Reconciling Variance and Process Strategies for Studying Information System Develop- ment,” Information Systems Research (6:4), pp. 303-327.

Sambamurthy, V., and Kirsch, L. 2000. “An Integrative Frame- work of the Information Systems Development Process,” Decision Sciences (31:2), pp. 391-411.

Segars, A. H., and Grover, V. 1999. “Profiles of Strategic Informa- tion Systems Planning,” Information Systems Research (10:3), pp. 199-232.

Shepherd, D. A., and Sutcliffe, K. M. 2011. “Inductive Top-Down Theorizing: A Source of New Theories of Organization,” Academy of Management Review (36:2), pp. 361-380.

Standish Group. 2015. Chaos Report, Boston, MA: The Standish Group.

Stigliani, I., and Ravasi, D. 2012. “Organizing Thoughts and Connecting Brains: Material Practices and the Transition from Individual to Group-Level Prospective Sensemaking,” Academy of Management Journal (55:5), pp. 1232-1259.

Tiwana, A. 2009. “Governance-Knowledge Fit in Systems Devel- opment Projects,” Information Systems Research (20:2), pp.

180-197.

Tiwana, A., and Keil, M. 2009. “Control in Internal and Out- sourced Software Projects,” Journal of Management Information Systems (26:3), pp. 9-44.

Vaara, E., and Monin, P. 2010. “A Recursive Perspective on Discursive Legitimation and Organizational Action in Mergers and Acquisitions,” Organization Science (21:1), pp. 3-22.

Van de Ven, A. H. 2007. Engaged Scholarship: A Guide for Organizational and Social Research, New York: Oxford University Press.

Venkatesh, V., Brown, S. A., and Bala, H. 2013. “Bridging the Qualitative-Quantitative Divide: Guidelines for Conducting Mixed Methods Research in Information Systems,” MIS Quarterly (37:1), pp. 21-54.

Vlaar, P. W. L., van Fenema, P. C., and Tiwari, V. 2008. “Co- creating Understanding and Value in Distributed Work: How Members of Onsite and Offshore Vendor Teams Give, Make, Demand, and Break Sense,” MIS Quarterly (32:2 ), pp. 227-255.

Wallace, L., Keil, M., and Rai, A. 2003. “How Software Project Risk Affects Project Performance: An Investigation of the Dimensions of Risk and an Exploratory Model,” Decision Sciences (35:2), pp. 289-321.Wastell, D. G. 1999. “Learning Dysfunctions in Information Systems Development: Overcoming the Social Defenses with Transitional Objects,” MIS Quarterly (23:4), pp. 581-600.

Weick, K. E. 1995. Sensemaking in Organizations, Thousand Oaks, CA: SAGE Publications.

Weick, K. E., Sutcliffe, K. M., and Obstfeld, D. 2005. “Organizing and the Process of Sensemaking,” Organization Science (16:4), pp. 409-421.

Yetton, P., Martin, A., Sharma, R., and Johnson, K. 2000. “A Model of Information Systems Development Project Perfor- mance,” Information Systems Journal (10:4), pp. 263-289.

Zmud, R. W. 1980. “Management of Large Software Development Efforts,” MIS Quarterly (4), pp. 45-55. About the Authors Tracy A. Jenkin is Associate Professor and Distinguished Faculty Fellow of Management Information Systems at the Smith School of Business, Queen’s University. She has published on IT projects, knowledge discovery and data analytics, and environmental sustain- ability in journals such as Business and Society, Decision Sciences, Information and Organization, Journal of Business Ethics, and Journal of Information Technology. She has a Ph.D. from Queen’s University.

Yolande E. Chan is Associate Dean (Research and PhD-MSc Programs) and E. Marie Shantz Professor of MIS at Queen’s Univer- sity. She holds a Ph.D. from Western University, an M.Phil. in Management Studies from Oxford University, and S.M. and S.B.

degrees in Electrical Engineering and Computer Science from MIT.

She is a Rhodes Scholar. Yolande studies IT strategic alignment and innovation, and publishes in leading journals such as MIS Quarterly and Information Systems Research. Yolande has served as an asso- ciate editor for several journals and as senior editor for Journal of Strategic Information Systems and MIS Quarterly Executive. She is a Fellow of the AIS.

Rajiv Sabherwal is Edwin & Karlee Bradberry Chair and Depart- ment Chair of Information Systems in the Walton College of Busi- ness at the University of Arkansas. He has published on the management, utilization, and impacts of IT and knowledge in jour- nals including Information Systems Research, MIS Quarterly, Management Science, Organization Science, and the Journal of MIS.

He has served as editor-in-chief for IEEE Transactions on Engi- neering Management and senior editor or guest editor for MIS Quarterly, Journal of AIS, and Information Systems Research. He is a Fellow of both the IEEE and the Association of Information Systems, with a Ph.D. from the University of Pittsburgh. MIS Quarterly Vol. 43 No. 2/June 2019671 RESEARCH ARTICLE M UTUAL U NDERSTANDING IN INFORMATION S YSTEMS D EVELOPMENT : C HANGES W ITHIN AND A CROSS P ROJECTS Tracy A. Jenkin and Yolande E. Chan Smith School of Business, Queen’s University, Kingston, ON CANADA K7L 3N6 {[email protected]} {[email protected]} Rajiv Sabherwal Sam M. Walton College of Business, University of Arkansas, Fayetteville, AR 72701 U.S.A. {[email protected]} Appendix A Proposed Sensegiving and Sensemaking Potential of Project Planning and Control Mechanisms Mechanisms Sensegiving (Actor: Sensegiver) Sensemaking (Actor: Sensemaker) Planning Mechanisms Comprehensive High In comprehensive planning processes, there tends to be a clear project vision developed, with the high-level details known up front: what, how, and why. The sensegiver provides these details to the sensemakers, typically as directives.

Thus, the potential to give sense with this mechanism is high.Low The sensemakers are given the vision and project details by the sensegiver(s). With these details in hand there is little uncertainty, so the sensemakers have little additional analysis and interpretation to do to gain an understanding. With the interpretation given, the potential for sensemaking is low. That is, not much sensemaking needs to be done. Emergent Moderate Although few details (i.e., what, how, and why) are known up front and uncertainty is high, the planning process is iterative and techniques are very interactive between project stakeholders.

Artifacts such as prototypes and storyboards are created and used to ultimately give sense.

Uncertainty is reduced by such artifacts. Thus, the potential to give sense with this mechanism is moderate.High There are few details known up front, with a high level of uncertainty. There is a high degree of interaction between sensegivers and sensemakers to analyze, discuss, and anticipate the project details. This is often a very iterative process. Therefore, the sensemakers must actively engage in dialogue and with artifacts to make sense and flesh out the details.

Thus, the potential for sensemaking is high. MIS Quarterly Vol. 43 No. 2, Appendices/June 2019A1 Jenkin et al./Mutual Understanding in IS Development Mechanisms Sensegiving (Actor: Sensegiver) Sensemaking (Actor: Sensemaker) Control Mechanisms Self- Control Low With self-control, there is only one individual involved. Thus, no one else is trying to influence that individual’s behaviors and interpretation.

Therefore, the potential for sensegiving is low.High With self-control, there is only one individual involved.

That individual is responsible for analyzing and inter- preting the pertinent project details. Since no sense is being given, the individual has to flesh out all details and resolve any uncertainty. Thus, the potential for sensemaking is high. Clan Control High The clan strongly influences the behaviors of its members through interactive socialization mech- anisms. Thus, each member of the clan has the opportunity to act as the sensegiver of the clan’s norms and goals. What (goal), how (behavioral norms), and why are often known and provided by the sensegiver(s). Sensegiving is also seen when clans reward appropriate behavior and sanction inappropriate behavior. Thus, the potential for sensegiving is high.High The taken-for-granted nature of clan norms and goals results in little sensemaking. However, when clan norms and goals conflict with the project’s norms and goals, sensemaking is required to resolve the resulting conflict. Clans have the ability to interact frequently, through multiple channels, so that this conflict can be resolved. Thus, the potential for sensemaking is high. Outcome Control Moderate Specifying outcomes: Many details are speci- fied by the sensegiver, typically the what (e.g., requirement) and why associated with the out- comes. The how, or process, may be left up to the sensemaker. There is some uncertainty and details to be determined by the sensemaker.

Specification is typically accomplished using impersonal formats (i.e., artifacts).

Measuring outcomes: The results being mea- sured provide some details regarding the degree to which the performance metrics have been achieved. These are often high level and may require some analysis and interpretation (in this case, the sensegiver is the controllee who generates the results to be measured by the controller, the sensemaker). Thus, the sense- giving potential is moderate.Moderate Specifying outcomes: The what and the why are typically provided (e.g., requirements document); however, the how is often left up to the discretion of the sensemaker. Thus, there is some uncertainty to resolve in terms of the process. The specification is typically provided as an artifact (e.g., document).

Measuring outcomes: The sensemaker of the results (i.e., the controller) completes some analysis and reflection to determine the degree to which the results are meeting performance expectations. These results are high level and may require some analysis on the part of the controller (sensemaker). Thus, the potential for sensemaking is moderate. Behavior Control Moderate Specifying behaviors: With behavior controls, sensemakers are told how to do their work (develop software), and often why it is important to do it that way. What to develop is not speci- fied. It is up to the sensemaker to determine this.

Specification of behaviors tends to be via imper- sonal formats (i.e., artifacts such as standards and methodologies).

Measuring behaviors: Observation, status reports, and gate reviews provide some informa- tion indicating whether the process is being followed and if not, why. The controllee is the sensegiver of this high-level information. Thus, the sensegiving potential is moderate. Moderate Specifying behaviors: Although “how” to do the work and often “why” it is important to do it that way are given to the sensemaker, (s)he is not told specifically what to develop. The sensemaker is left to determine this aspect. Also, adaptation of the specified behaviors is often acceptable and requires inter- pretation on the part of the sensemakers to determine.

Measuring behaviors: The sensemaker of the given reports, verbal status, or observations has to assess the extent to which the behavior is as specified. The sensemaker is the controller. Not all details are pro- vided in reports, nor can all behaviors be observed.

Therefore, there is some level of uncertainty requiring analysis and interpretation by the sensemaker. Thus, the potential for sensemaking is moderate. A2MIS Quarterly Vol. 43 No. 2–Appendices/June 2019 Jenkin et al./Mutual Understanding in IS Development Appendix B Linkage between ISD Project Planning and Control Mechanisms and Sensemaking and Sensegiving Mechanisms Sensegiving Sensemaking Planning Comprehensive “Information analysts then construct alternative structures for the overall MIS architecture subject to the MIS objec- tives, strategies, and constraints enu- merated as the MIS strategy set. The general alternatives are then presented to management” (Bowman et al. 1983, p. 17).“When the new members officially joined the team, they were given copies of deliverables from the planning phase. In a ‘knowledge dump’ meeting, the planning phase strategists walked the newcomers through the planning phase deliver- ables presentation” (Levina 2005, p. 121). Emergent “Structured problem solving and experi- mentation through the use of cross- functional teams tend to produce high levels of understanding regarding organizational processes ... a noted drawback of the philosophy is its ten- dency to promote strategic drift as many actors continually bounce back and forth between competing strategic perspec- tives” (Segars and Grover 1999, p. 222).“As the third week of the planning phase approached—a time when, according to the Eserve service delivery model, consul- tants should be up to speed on their client’s business—Eserve conducted a brainstorming workshop with the intention of generating ideas as to what kind of functionality the website should support” (Levina 2005, p. 119). Control Self- Control “Self-control therefore requires that the controller grant autonomy to the con- trollee without imposing any other forms of control” (Tiwana and Keil 2009, p. 21).“He monitors how well he is progressing over time; and intrinsically rewards himself for completing the job” (Kirsch 1996, p. 3). Clan Control “Team-building sessions and meetings served to incent stakeholders to embrace common values. The System Development Manager explained various approaches for generating this level of commitment and shared goals” (Kirsch 2004, p. 383).“During this phase, control can be characterized as ‘collective sensemaking’ in which informal mechanisms of control are used jointly by IS and business stakeholders to clarify ambiguous project goals, reach consensus on a common business process, and negotiate a set of global system requirements” (Kirsch 2004, p. 388-389). Outcome Control “In outcome control, the controller focuses on the outputs (both final and interim) of the project without regard to the process by which these outputs are achieved” (Choudhury and Sabherwal 2003, p. 293).“that define outcome metrics for software in great detail (high standardization of performance criteria). However, the contracts allow project teams to have discretion in adopting the standards to suit the context of specific projects” (Nidumolu and Subramani 2003, p. 168). Behavior Control “A detailed systems development methodology may be viewed as a mechanism of behavior control if it articulates the precise steps to follow to successfully develop a system” (Kirsch 1997, p. 217).“While younger consultants … tended to interpret the method- ology literally, and follow its procedures ‘to the letter,’ … experienced employees seemed less constrained, relying on their initiative to direct production work, and using the method- ology primarily as a coordination device to manage impres- sions through appropriate behavior packaging. Thus, while the methodology is prescriptive in documentation, in practice, its tenets were often modified, overridden, or ignored” (Orlikowski 1991, p. 16).

Legend: Low Moderate High MIS Quarterly Vol. 43 No. 2, Appendices/June 2019A3 Jenkin et al./Mutual Understanding in IS Development Appendix C Research Method Summary: Building Theory from Cases (Eisenhardt 1989) Recommendation This Study Planning the Study Getting started: Define the research question and identify a priori research constructs.Used a combination of top-down inductive and deductive theorizing to start the study as recommended by Shepherd and Sutcliffe (2011), followed by bottom-up inductive theorizing described below in this appendix.

Selecting cases: Identify the population of interest and use theoretical sampling.Defined population as projects focused on the development and enhancement of systems at global IT firms with headquarters in North America. Sample included projects completed over a 10-year time span (2000 to 2010) at two organizations (Alpha and Beta). Examined 13 projects (7 at Alpha, 6 at Beta). Collecting Data Crafting instruments and protocols: Use multiple data collection methods, combine qualitative and quantitative data, and involve multiple investigators.Developed and refined interview guide before the interviews. Most data were quali- tative, although some quantitative data were also captured (e.g., team members per project, years of experience for each team member). The authors jointly developed the interview guide. One author conducted the interviews and immersed herself in the case details and project context, enabling the other authors to bring a “very dif- ferent and possibly more objective eye to the evidence” (Eisenhardt 1989, p. 538).

Entering the field: Overlap data collection and analysis, and use flexible methods to collect data.Data collected in 2004, 2005, and 2010, through 24 interviews with 21 informants at the two organizations. Data collection and analysis overlapped over this time period. For instance, the authors jointly considered the interview findings (in the form of narrative summaries) to plan subsequent interviews and data collection. At least one respondent at each organization was interviewed in multiple time periods.

Interviews were recorded, producing 214 pages of transcripts. Developing Propositions Analyzing data: Analyze within-case data and search for cross-case patterns.Qualitatively coded quotes from transcripts based on the constructs in the initial model (Figure 1) and the project stage. Used iterative process with multiple cycles with all authors involved. Next, used coded transcripts to rate each project’s stages in terms of the focal constructs in the initial model as high, moderate, or low. Also identified planning and control mechanisms that were used in each project stage to code and calculate sensegiving (sensemaking) potential. In the final phase, identi- fied sensegiving-sensemaking episodes, coding when it occurred, the stakeholder groups who gave and made sense, and directionality. Result was panel data for 13 projects at three points in time. Created multiple data displays for within and cross- case analysis. Regressions using the quantitative data supplemented the qualitative results.

Shaping hypotheses: Itera- tively compare theory and data so that emergent theory fits the data.Employed a longitudinal embedded mixed-methods design approach (Creswell and Clark 2007). Used regressions to develop an initial understanding of the potential relationships. Used the extensive qualitative data to develop more nuanced insights into various relationships. Triangulation through the use of quantitative data (regressions), qualitative data (the coded text from the raw transcripts), and overall perceptions (narrative summary, data displays in Figures 3, 4, 5, and 6).

Enfolding literature: Com- pare theory and hypotheses with the literature.Compared the patterns and relationships uncovered through the qualitative analy- ses with the initial model, the prior literature, and the quantitative analyses. Devel- oped an emergent model and propositions based on these new relationships and patterns.

Reaching closure: Achieve saturation (i.e., minimal improvement). Reached closure in data analyses once the emergent model and propositions were consistent with the data (including the transcripts, key informants’ remarks, and quantitative results), and the incremental improvement from continuing the analysis or examining other projects seemed minimal. A4MIS Quarterly Vol. 43 No. 2–Appendices/June 2019 Jenkin et al./Mutual Understanding in IS Development Appendix D Supplementary Project Details 1 23 Proj. Background Size 2 Novelty Key Events 3 Key Outcomes A1 New feature requested by customers, referred to as a “customer escalation.”3 to 5 • New technology for Alpha • New product feature• Quality assurance (QA) finding issues during testing was the initial stimulus for the team thinking there were issues.

• Customer reports of significant issues with the software confirmed that there were major issues with the new feature and technology.

• Post-implementation discovery that other users of this IT had similar issues.• Late delivery with a number of defects, resulting in customer complaints. Followed up with patches to provide short-term fixes.

A2 Architecture project to introduce new IT and struc- ture to an old legacy prod- uct. This would enable future user interface en- hancements. Proposed by team lead.6 to 8 • Existing product functionality implemented on new technology platform• Prototyping to assess technical feasibility and whether to proceed with the project.

• Decision to proceed based on successful prototype.• Successfully imple- mented architecture changes and fixed a number of long- standing defects in the product.

A3 Initiated to resolve the issues associated with the new feature implemented on A1.4 to 7 • Technology introduced on A1 • Product feature introduced on A1• Decision to consult and work with another office (in Alpha) and reuse one of their code components. • Issue with Windows disrupted development for four weeks.

• Cut scope back due to time constraints.• Successful delivery that resolved problems in A1 and met customer needs.

A4 Existing functionality from a 15-year-old product was being incrementally ported to a web-based platform in multiple projects, including A4. Identified as important by sales and marketing.6 to 9 • Existing product functionality implemented on new web-based platform • New methodology introduced• Usability testing of prototype at a user conference found usability issues before development began.

• Decision to split off functionality to create project A5.• Successful delivery of product to customers, with minimal defects.

Held up as the ideal way to run a project, but delivered later than target date due to problems with A5.

A5 Originally part of the requirements of A4, but spun off as a separate project given the scope of the required functionality.

A4 was dependent on the functionality being implemented in A5.6 to 9 • New product features for existing platform and new web- based platform • New methodology recently introduced, but not applied here• Decision to split off functionality to create project A5.

• Realization that scope was larger than initially estimated.

• Tester posed questions seeking clarifications regarding user experience document, which initiated sensegiving- sensemaking episodes to further define requirements. • Decision to split release of the product to provide select customers with an early version of the product (with defects). • Delivered required product functionality late and with defects.

Split release allowed some customers to receive functionality earlier than others, based on urgency of needs.

• Failed to implement methodology and lessons from A4.

Significant problems with the process led to lessons learned at the end of the project. 1For timeline information, see Table 2.

2Size is in terms of the number of individuals working on the project, which changed over time. In addition to the IT project team members, it includes the business sponsor, the business project manager, any business-side team members, and the vendor project manager as applicable.

3These are the significant events in the project that impacted the project or subsequent projects.

MIS Quarterly Vol. 43 No. 2, Appendices/June 2019A5 Jenkin et al./Mutual Understanding in IS Development Proj. Background Size Novelty Key Events Key Outcomes A6 Involved implementing several “specific” features to Alpha’s flagship product.

The goal was for customers to switch to it from legacy product. Considered a point release. Not all features were relevant to all customers.14 to 16 • Minor feature updates to existing product and platform• Change in product manager midway through the project.

• Decision to drop large, more complex feature to meet deadline.

• Decision to release patches to fix issues post-release after customers called to complain.• Product was imple- mented on time, but with some quality issues. Specifically, customers were not entirely satisfied with the product because some older problems still existed. • Patches were released to fix these issues.

A7 A major overhaul of Alpha’s flagship product (same as A6), including new features and improvements to existing features. Also added integration with Alpha’s suite of products.

Considered a full release. 14 to 16 • New features and feature updates to existing product and platform • New methodology introduced• Organization-wide introduction of new methodology, creating turmoil on project.

• Identified and agreed upon adjustments to new methodology. • Decision to drop large feature (same feature dropped in A6).• Dropped feature and turmoil at project start hurt perceptions of success. • Otherwise, product was successfully launched.

• Process improve- ments and adaptation of the new method- ology.

B1 Implemented a new product and new technology platform and business processes to support it. Considered strategic, with product launch seen as key to the company’s survival.20 to 30 • New technology platform, con- sisting of multiple new and existing systems • New business processes • Period of high intensity of change requests, resulting in significant turmoil on the project. • Decision to implement the project according to scheduled release date.• Delivered project on time but with numerous defects.

Turmoil and defects negatively impacted perceptions of success. • Did achieve the objective of launching new product.

B2 Originally part of project B1, involved porting legacy application to the new technology platform implemented in B1. 20 to 30 • Existing legacy system features implemented on IT platform intro- duced in B1• Late change request from critical business partner.

• Decision to postpone project by one month to accommodate request.• Delivered project one month later than original plan, due to postponement.

B3 Considered a strategic project that involved insourcing an existing customer product that was previously outsourced.15 to 22 • New features on existing IT platform • New business processes linked to the new product• Programmers hid technical issues. • Decision to reduce scope late in the project due to technical issues, which had not been disclosed earlier.• Significantly over budget, late and defect-ridden.

Technical issues resulted in reduced scope and manual workarounds.

B4 Added functionality to enable business units to modify own (customer facing) applications and accelerate implementation of business initiatives.20 to 25 • New features and processes on existing technology platform• Programmers hid technical issues, just like in B3. • Decision to drop a large portion of project’s scope at the last minute due to technical deficiencies, which had not been disclosed earlier. Just like in B4.• Due to scope reduc- tion, project objec- tives not met. Busi- ness stakeholders were not satisfied.

• A new project was initiated.

B5 Focused on improving global procurement and order management systems, information, and processes. 15 to 20 • New third-party technology platform • New business processes • Changes to methodology • Implemented request by programmers to change process for managing issues.

• Process changed back when it did not have the intended effect.

• Change in methodology declared by senior management.• Project successfully delivered the desired functionality for the business. Business and IT stakeholders perceived project as successful.

A6MIS Quarterly Vol. 43 No. 2–Appendices/June 2019 Jenkin et al./Mutual Understanding in IS Development Proj. Background Size Novelty Key Events Key Outcomes B6 Involved implementing functionality and processes that would allow a business unit to expand its marketing capabilities. Similar capabilities, systems, and processes were implemented in another unit.17 to 27 • New features in an existing IT platform • New business processes • Similar to pro- cesses and features in a related system• As requested by the project manager, business management agreed to turn off old system so that the new features did not have to be implemented on it.

• Reversal of this decision at project end when senior sales reps became aware of the impending system retirement. • Post-implementation workarounds.• The issue with the senior sales reps resulted in significant workarounds after go- live. All other aspects of the project were considered success- ful. Not all stake- holders perceived the project as a success. MIS Quarterly Vol. 43 No. 2, Appendices/June 2019A7 Jenkin et al./Mutual Understanding in IS Development Appendix E Interview Guide The following questions were used as a guide during the interview. Each interview was emergent: the interviewer adapted questions and asked additional probing questions as needed.

Please recall a recently completed project that was considered strategic (important to the business). We will discuss this project throughout the interview.

1. What is the name of the project?

2. What was your role on the project?

3. How long have you been with the company? In this role?

4. When did the project start and end?

5. Was there a business sponsor? (Probe: Ask about steering committee and other senior management support mechanisms.) 6. Can you describe the project organization chart? Is this typical for the organization?

7. Why was this project considered strategic (important to the business)?

8. Do you know what priority level was assigned to this project?

9. Did this project need to be justified formally before it was approved? If so, what justifications were provided?

10. What were the purpose, goals, and objectives of the project? (Probe: Discuss linkages or dependencies on other systems or projects.) 11. What changes occurred during the project?

12. At any time, was this project’s priority changed?

13. At any time were there resource changes on the project? If so, why were those changes made?

14. Were there any changes to requirements during the project? How were changes in requirements handled?

15. Were you given adequate ownership and decision-making ability in running this project? (for Project Manager) 16. What do you think makes a great project manager?

17. How did you handle roadblocks (problems, unexpected issues, surprises)? Did you have predetermined escalation paths? (Probe: Discuss risks and risk management approach; also discuss any major issues and why they arose.) 18. What, if any, methodology was followed? Describe. How closely did you follow it? (Probe: Describe the phases and what was done in those phases. Specifically, initiation, planning, design, development, testing and implementation phases.) 19. At a high-level, explain your testing methodology. (Probe: Describe any problems detected during testing, such as defects.) 20. Were periodic reviews of the project conducted? (Including testing, gate reviews, deliverable reviews, status reviews, etc.) 21. Was a final evaluation of the project conducted? What were the criteria used for the evaluation? What was done with the results? (For example, formal post-mortem review with the business? Surveys?) 22. Was a formal process followed for the implementation (deployment to “production” or “generally available”) of this project? If yes, what was it? If no, what was involved in coordinating the implementation of this system?

23. Most important best practice? Biggest mistake?

24. How did the business (for example, product managers, marketing, sales) communicate with the project team? How did the project team communicate with the business? (Probe: Were there any problems with communication and coordination? How were users involved?) 25. How would you describe the relationship you had with the business? (for development team members) How would you describe the relationship you had with the development project team members? (for business team members) (Probe to see if there were there any problems with the relationship.) 26. In your opinion, how well do the development project team members understand the business? Conversely, how well do the business team members understand development?

27. Was the project implemented on time? Did this project have an accelerated timeline to meet market-timing constraints? Or was timing based on estimated effort?

28. Was the project implemented on budget?

29. Was this project considered successful? Why or why not?

30. How does your company measure the success/performance of a project?

31. Did the initial objectives and goals for the project change during the project? Were all of the objectives and goals of the project met?

32. Were some objectives for this project not met? Was this a conscious decision (for example, ran out of time or money)? If some objectives were not met, what was done as a result?

33. Was the business (and users) satisfied with the results of the project?

34. Was the development team satisfied with the results of the project?

A8MIS Quarterly Vol. 43 No. 2–Appendices/June 2019 Jenkin et al./Mutual Understanding in IS Development Appendix F Coding and Analysis Approach MIS Quarterly Vol. 43 No. 2, Appendices/June 2019A9 Jenkin et al./Mutual Understanding in IS Development Appendix G Quotes Illustrating the Coding of Constructs Construct Type Illustrative QuoteProject (Stage) Planning Compre- hensive“Because of the high risk of this project, I had put together an MS Project plan with the team lead. We mapped out the whole process and defined the details” (Project Manager).A2 (E) Emergent “We cut back a little on what we were going to deliver.” When asked if this was done because of timing, he responded, “Yes. Because of scope. So we decided to do it in a phased delivery of functionality” (Project Manager).A3 (L) Control Self-control “[The initial document] was a high-level vision. This is how we see it happening.

The developer thought that it was exactly what should be happening and then started developing and there wasn’t time to go to a more detailed design of here is how the screens will actually look” (Product Designer).A5 (E) Clan control“No training, no rollout, no explanation. Half of the documents are gone, or the documents we had been using have no meat in them anymore. I went out to look at the test spec and it was ‘huh?’ And people came to me asking me if I had an old copy of the template. And I say ‘yes we have it on our Sharepoint site’” (QA Manager).B5 (M) Outcome control“Reviews were being done, but primarily between the development manager and the product manager in terms of ‘have you delivered this yet.’ Very centralized” (Product Designer).A6 (M) Behavior control“We had weekly reviews of the actual specifics of the project in the Exec Sponsor’s project review meeting. So any large efforts that are being worked in his group are talked about in this forum—a weekly Friday meeting with all of his direct reports and stakeholders throughout the business that own pieces of his business (e.g., risk manager). That was his forum for Q and A, if he had ques- tions about what we were doing or we needed answers for something, we would bring those up in that meeting” (Business Project Manager).B6 (M) Sensemaking Low “I did find there was a lot of coming and saying ‘this is what I am getting’ and then me saying ‘well that is what you are supposed to get. It is by design. If you had read the document you would know that’” (Programmer 2).A5 (M) High “Having a dedicated product designer, a usability person/product designer, to help define the stories and then having review sessions with the team where people can ask questions and change the stories if issues are brought up … took a lot of time, but was a really helpful process. And great for us (documentation).

Also good for the product” (Technical Writer).A7 (M) Sensegiving High “The business area originally felt they could wait until after implementation to address their needs … resulted in a last-minute escalation to the project steering committee and the CEO .... Very political move” (IT Project Manager).B2 (L) Low “We were compliant … in form, but not in function. There was a lot of spin going on. IT couldn’t speak to the business truthfully” (QA Manager).B3 (M) A10MIS Quarterly Vol. 43 No. 2–Appendices/June 2019 Jenkin et al./Mutual Understanding in IS Development Construct Type Illustrative QuoteProject (Stage) Mutual Understanding High “Everybody knew what everybody else was going to do and how it is going to work in the system” (Team Lead).A4 (E) Low “At the beginning, there was an organization-wide decision … that generated a lot of confusion and lack of clarity within the team.… this team, as well as other teams within the organization, were led to question some fundamental things about the way they were working” (Product Designer).A7 (E) Project Success Low “In the end, it didn’t really accomplish what it was intended to do. The users weren’t that satisfied” (Project Manager).A1 (L) High “That one went quite nicely. It was one of those classic ‘yeah that’s the way you do it’” (Product Designer).A4 (L) MIS Quarterly Vol. 43 No. 2, Appendices/June 2019A11 Jenkin et al./Mutual Understanding in IS Development Appendix H Quotes Illustrating the Coding of a Project: Project A7 Stage Early Middle Late Planning (overview)The requirements for the project were determined by the product manager at the start. Planning was not as inclusive as it could be given that customers were not consulted. However, planning was disrupted in the early stages of the project because of the methodology change. Once this change was resolved and planning resumed, planning was conducted collaboratively and emerged incrementally during each iteration.

Coding Comprehensive Emergent Emergent Illustrative Quotes“They had a very ambitious set of objectives initially.… But very quickly that was taken off the list of goals because it was just too ambi- tious. I'm not sure how serious that goal ever was, but it was there.

That was unfortunate but then they had a more realistic set of goals to replace that and I think it’s been really successful, the process” (Technical Writer 1).“A lot of collaboration between the new product manager, the dev manager and myself to set a common direction for the team, to really agree on the priorities for the release and to react very flexibly to changes in priority. So that has been very effective” (Product Designer).“But lately it is more visible because every two weeks we get together to discuss what’s new” (Programmer).

Explanation Product manager set the list of ambitious objectives upfront on the project. These objectives were updated to become more realistic.

Demonstrates comprehensive planning upfront. Other comments also show that all the requirements were determined upfront, but things were added and taken away during the agile iterations.Collaboration between the product designer, development manager, and product manager show that these three stake- holders helped to set priorities and update those priorities as needed when changes arose.

This began after things settled down following the methodology change. Other comments demonstrate that this collabora- tion enabled the team to adapt to changes flexibly across iterations, reflecting an emergent learning approach to planning. Applies to both middle and late stages of the project. At the beginning of each iteration, the new things to be implemented in that iteration were discussed and planned in more detail. This demonstrates emergent planning in both the middle and late stages of the project.

Control (overview)At the start of the project, there was little control. Clan control helped team members focus on overcoming the challenges associated with the methodology change. The new methodology was a form of behavior control, but it was not yet understood and was being compared to the old ways. Midway in the project, outcome controls were added: macro stories (requirements) served as outcome specifications and frequent testing and reviews served as outcome measurement. Behavior control was stronger now, as the methodology was more clearly understood. Daily reviews also helped measure behavioral compliance.

Coding Behavior, Clan Behavior, Outcome Behavior, Outcome Illustrative Quotes“Conflicts between product designer and developers early on over the new process because there was a new role for the designers and I think it was just a matter of sorting out what the roles would be. But there were some pretty significant conflicts” (Technical Writer 1).“It helps things from getting too far off track. Because if someone has done something but maybe they haven't emailed you or let you know. But then they mention it and you know right away.

Before when a developer changed something without telling“Reviews were done at the end of each iteration. There would be a demo to interested parties as to what was achieved” (Programmer). A12MIS Quarterly Vol. 43 No. 2–Appendices/June 2019 Jenkin et al./Mutual Understanding in IS Development Stage Early Middle Late you for whatever reason, it could be weeks or months before you found out about it. Whereas now, you could know the same day” (Technical Writer 1). Explanation Conflicts were resolved using clan control, leveraging past history of norms and beliefs for the group, who had just completed project A6.

Other quotes show that sanctions were imposed on members who did not accept new norms and roles.Daily stand up meetings, which were conducted in both middle and late stages, served as an outcome control because they enabled outcome measurement.

As noted above, this also enabled behavioral compliance to the adapted methodology. Other comments demonstrate the value of macro stories as outcome specifications.Refers to the reviews and demos that occurred at the end of each iteration, in both the middle and later stages. These reviews served as a mechanism to measure outcomes. This demonstrates outcome control. Cognitive Activities:

Sensegiving (overview)At the start of the project, there was moderate sensegiving from the espoused new methodology. This adapted methodology was a helpful sensegiving device throughout the rest of the project. Midway and later in the project, macro stories, interim builds (prototypes), daily stand-ups and frequent reviews gave the team sense, which in turn supported sensemaking.

Coding Moderate High High Illustrative Quotes“I think the introduction of the new process was a good stimulus for looking at some of the practices and improving the way the team does its work. And I think we have become more agile, not necessarily because of the introduction of the new process, but perhaps even in spite of it, by realizing that there were certain things that were important that we could be doing. It turned out to be a positive development definitely” (Product Designer).“The other thing that was a best practice that emerged out of this release was early review of requirements and design with the dev team and with QA and docu- mentation staff and even with support. So we have formalized a process, well not formalized, but we have a consistent process for doing these reviews and engaging the rest of the team in providing early and often feedback to priorities, well maybe not so much to priorities but definitely to design decisions.

And that has been really key to effectively deliver the more complicated features we have in this release” (Product Designer).Paraphrased: The amount of information and detail made writing up the documentation in parallel to development a lot easier. It allowed you to know what the functionality was going to look and act like when it was done. Things were completely itemized in detail and planned out (Technical Writer 2 Paraphrase: participant asked not to be directly quoted).

Explanation Moderate sensegiving early in the project via the new methodology announcement. Other comments suggest that training and the project objectives provided sensegiving.

However, sensegiving was only moderate, not high, because the methodology and training were too high level and not directly applicable to the Alpha and project A7 context.

See sensemaking comments for how the team made sense of this. A high level of sensegiving in the middle and later stages as the result of the reviews between the product designer and the devel- opment team, QA and technical writers and updating these stake- holders on design decisions and the rationale behind those deci- sions. Other comments also sug- gest that the macro stories (user experience stories) developed by the product designer to describe and explain the design to this same set of stakeholders provided a high level of sensegiving. Demonstrates the sensegiving provided through the macro stories provided in each iteration in both middle and late stages of the project. This brought further sensegiving to the reviews, keeping a high level of sense- giving in both the middle and later stages. Other comments suggest that the daily stand up meetings, interim builds and demos enabled a high level of sensegiving. MIS Quarterly Vol. 43 No. 2, Appendices/June 2019A13 Jenkin et al./Mutual Understanding in IS Development Stage Early Middle Late Cognitive Activities:

Sensemaking (overview)At the start of the project, the level of sensemaking was high due to the team interpreting and adapting the methodology to suit their needs and resolving the uncertainty that came from the change. Midway and later in the project, macro stories, interim builds (prototypes), daily stand-ups and frequent reviews gave the team sense, which in turn supported sensemaking.

Coding High High High Illustrative Quotes“The way the process was rolled out was not done very well. As a result, this team, as well as other teams within the organization, were led to question some fundamental things about the way they were working.

And there was quite a bit of churn and discussion that had to result before the team could settle back down and be effective in imple- menting the things they needed to implement” (Product Designer).“I wouldn't say that was so much a feature of the formal process, but more of a feature of constant collaboration between what I like to call the customer team—so the product manager, the dev mana- ger, and myself. As soon as time-sensitive things came up we immediately discussed them, we talked to the development team to understand the repercussions, got rough effort estimates and based on that quickly responded whether or not it was something that we could incorporate into the release or push off to a future release” (Product Designer).“For A7, we have had the regular demos of the completed func- tionality for the whole team. And especially this was helpful in involving QA and documentation and support in understanding what had been delivered in each of the iterations preceding the demo” (Product Designer).

Explanation A high level of sensemaking occurred early in the project as all team members tried to understand and work out how the new method- ology could be applied to the project context of A7 and Alpha more broadly. Part of this sensemaking included reflecting on problems with the current process and how to adapt the new methodology to improve this process. Other comments demonstrate that the end result was an improved process. Describes the sensemaking pro- cess engaged in by the “customer team” (product designer, develop- ment manager, and product manager) to understand impacts, develop estimates and make decisions. Along with the other comments that demonstrate the sensemaking that occurred via regular reviews, demos, and macro stories, this reflects a high level of sensemaking on a daily and weekly basis during the iterations.A high level of sensemaking continued in the middle and later stages of the project. This comment demonstrates the sensemaking that the demos enabled for QA, technical writers, and the support team.

Other comments demonstrate the benefit of regular reviews and macro stories in helping programmers, QA and technical writers make sense of the requirements as well as the functionality that had been implemented by programmers.

Cognitive Outcome:

Mutual Under- standing (overview)At the beginning of the project, there was a low mutual understanding of the process and roles due to the change in methodology. Midway through the project, there was some uncertainty regarding why the large feature was dropped. However, the mutual understanding of the project process and the requirements progressively developed over the course of the project due to the high levels of sensegiving and sensemaking midway and later in the project.

Coding Low Moderate High Illustrative Quotes“At the beginning of [project A7], there was an organization-wide decision and a series of training sessions rolled out to support that decision to move to a more industry standard agile process. Not entirely industry standard but closer to those standards. That generated a lot of confusion and lack of clarity within the team” (Product Designer).“And for IDP, you are supposed to have a post-mortem at the end of each iteration. So every three weeks or two weeks. I think those eventually died because no one said anything. Initially, it was good because I think when the process was still being nailed down it was helpful to be able to vent. But as people got accus- tomed to it, there was less need for that” (Technical Writer 1).Paraphrased: in the new pro- cess, there are macro stories and micro stories provided and we have daily stand-up meetings. As a result, everyone on the team has a good sense of what is going on in terms of who is working on what, what is not working, and what is working well (Technical Writer 2 Paraphrase).

A14MIS Quarterly Vol. 43 No. 2–Appendices/June 2019 Jenkin et al./Mutual Understanding in IS Development Stage Early Middle Late Explanation The methodology change resulted in confusion regarding the impact of the change on roles and the process. Thus, there was low mutual understanding at the start of the project. Other comments further support the uncertainty and confusion that ensued in the early stage of the project while the team was working this out. Post-mortems at the end of each two-week iteration were con- ducted initially when mutual understanding of the project and the product needed to be further developed. This mutual under- standing grew to a moderate level during the middle of the project.

Other comments note that a feature was dropped because of uncertainty regarding the required functionality. By dropping the feature, the team could focus on the better understood features. Artifacts of the new process resulted in a high level of mutual understanding of the product being developed and the status of the project via the sensegiving and sensemaking enabled by these artifacts. In addition to the macro stories and daily stand up meetings, other comments demonstrate that regular demos and reviews with the entire team also helped in this regard.

Project SuccessModerate Success (success is evaluated at the end of each project).

Coding Moderate Illustrative Quotes“I think A7 has done a much better job of addressing the strategic roadmap goals of the product. Again, one of the strategic roadmap goals was that one large feature that got dropped. At the same time, arguably, by not taking on that very complicated and risky feature, we have delivered a better and more stable product in a lot of other ways” (Product Designer).

Explanation Project stakeholders perceived the project to be moderately successful and not highly successful because of the important feature that was dropped from the project due to timing constraints. Other comments indicate that there was a gap created by the missing functionality, which impacted perceptions of success.

Further, other comments demonstrate that the initial chaos caused by the methodology change had a negative impact on perceptions of project success. MIS Quarterly Vol. 43 No. 2, Appendices/June 2019A15 Jenkin et al./Mutual Understanding in IS Development Appendix I Quantitative Analyses and Results We coded variables into low, medium, and high. Since we cannot assume equal gaps between low and medium and between medium and high, the data is ordinal in nature. Therefore, we used Kendall’s Tau to measure correlation (Conover 1999) and conducted ordinal logistic regressions. Tables I1 and I2 present the descriptive statistics, correlations and the results for four regression models. All four regressions included two control variables: project duration (months) and number of primary informants for the project.

The first three regression models used stage-level data, with sensegiving, sensemaking, and MU as dependent variables. The planning and control mechanisms used in each stage were included at an aggregate level as sensegiving potential and sensemaking potential. Model 1 suggests that sensegiving during a stage depends on sensegiving potential and sensemaking during that stage. Similarly, Model 2 suggests that sensemaking in a stage depends on sensemaking potential and sensegiving in that stage. Thus, sensegiving and sensemaking affect each other, as expected. Moreover, sensegiving and sensemaking seem to depend on sensegiving potential and sensemaking potential, respectively, of the planning and control mechanisms used, as was also expected.

We expected both sensegiving and sensemaking to affect MU. The results for Model 3 differ somewhat from these expectations, suggesting that MU during a stage depends directly on sensemaking but not on sensegiving. Combined with the results for Model 2, this leads to the emergent proposition P1.

Model 4 used project-level data as project success, the dependent variable, was assessed at the end of the project. Although the sample size of 13 is a limitation and implied a low statistical power (0.36 with medium effect size), the effect of MU on project success was significant.

Also, when sensemaking and sensegiving were added as independent variables, and a stepwise ordinal regression was conducted (due to the small sample size), only MU was found to have a significant direct effect on project success. 4 Table I1. Descriptives and Correlations Correlations 1 Mean S.D. Min Max SG_P SM_P SG SM MU Sensegiving Potential (SG_P)0.46 0.25 0.00 0.88 Sensemaking Potential (SM_P) 0.37 0.25 0.13 1.00 0.18 Sensegiving (SG) 2.18 0.721.00 3.00 0.28** 0.22* Sensemaking (SM) 2.00 0.79 1.00 3.00 0.09 0.28** 0.39*** Mutual Understanding (MU) 1.97 0.78 1.00 3.00 -0.05 0.20* 0.26* 0.40*** Project Success (SUCC) 2.15 0.80 1.003.00 0.27 0.310.49* 0.50* 0.53** 1Kendall’s Tau statistics are reported for correlations. N = 13 for Project Success and correlations involving it. N = 39 for other constructs and correlations. *p < 0.05; **p < 0.01; ***p < 0.001. As expected (Conover 1999), the results are consistent in significance when using Spearman’s Rho.

4The results for this additional regression are not reported in Table I2 due to space constraints. Moreover, sample size limitations precluded quantitative tests of the mediating effects.

A16MIS Quarterly Vol. 43 No. 2–Appendices/June 2019 Jenkin et al./Mutual Understanding in IS Development Table I2. Regression Results 1 Model 1 2 Model 2 Model 3 Model 4 3 Dependent Variables Sensegiving SensemakingMutual UnderstandingProject Success Control Variables Project duration (months) 0.00 (0.82) -0.12 (0.10) -0.34 (0.22) -0.01 (0.11) Number of primary informants for the project -0.47 (0.17) 0.40 (0.33) 0.61 (0.39) -0.27 (0.37) Independent Variables  Sensegiving 2.16** (0.67) 0.59 (0.78) Sensegiving Potential 5.72* (2.56) Sensemaking 2.62** (0.85) 1.88* (0.93) Sensemaking Potential 4.02* (1.97) Mutual Understanding 6.56** (2.69) N 39 39 39 13 Wald’s 4 χ² 10.49* 11.64* 25.97*** 12.75** McFadden R² 0.417 0.359 0.325 0.457 Highest Variance Inflation Factor 1.08 1.21 1.72 1.42 1Instandardized regression coefficients are given with robust standard errors in parentheses. All significance levels are indicated as follows: *p < 0.05; **p < 0.01; ***p < 0.001.

2 For Models 1–3, we first conducted panel-data ordinal regressions (using xtologit in Stata 15), with panels based on projects. Results of estimated variance components and likelihood-ratio tests indicate that xtologit does not improve over a standard ordered logistic regression. So, results of ordinal regressions (the ologit command) are reported in this table. We used the “vce(cluster)” option with clustering based on the project. The results are substantively the same when using either panel-data ordinal regressions (xtologit) or multiple regressions with the data clustered by project, and with a dummy for organization. Results for the other models are excluded due to space considerations.

3 Model 4 is tested using ordinal regression (the ologit command) with the “vce(robust)” option to obtain robust standard errors (for consistency with Models 1–3). The results for a model including a dummy for organization are substantively the same, and are excluded due to space constraints.

4 Using G*Power (http://www.gpower.hhu.de), medium effect size, and four (Models 1-3) or three (Model 4) predictors (excluding controls), statistical power is 0.77 for Models 1–3 and 0.36 for Model 4.

References Bowman, B., Davis, G., and Wetherbe, J. 1983. “Three Stage Model of MIS Planning,” Information & Management (6:1), pp. 11-25.

Choudhury, V., and Sabherwal, R. 2003. “Portfolios of Control in Outsourced Software Development Projects,” Information Systems Research (14:3), pp. 291-314.

Conover, W. J. 1999. Practical Nonparametric Statistics, Hoboken, NJ: Wiley.

Creswell, J. W., and Clark, V. L. P. 2007. Designing and Conducting Mixed Methods Research, Thousand Oaks, CA: SAGE Publications.

Eisenhardt, K. M. 1989. “Building Theories from Case Study Research,” Academy of Management Review (14:4), pp. 532-550.

Kirsch, L. J. 1996. “The Management of Complex Tasks in Organizations: Controlling the Systems Development Process,” Organization Science (7:1), pp. 1-21.

Kirsch, L. J. 1997. “Portfolios of Control Modes and IS Project Management,” Information Systems Research (8:3), pp. 215-239.

Kirsch, L. J. 2004. “Deploying Common Systems Globally: The Dynamics of Control,” Information Systems Research (15:4), pp. 374-395.

Levina, N. 2005. “Collaborating on Multiparty Information Systems Development Projects: A Collective Reflection-in-Action View,” Information Systems Research (16:2), pp. 109-130.

Nidumolu, S. R., and Subramani, M. R. 2003. “The Matrix of Control: Combining Process and Structure Approaches to Managing Software Development,” Journal of Management Information Systems (20:3), pp. 159-196.

Orlikowski, W. J. 1991. “Integrated Information Environment or Matrix of Control: The Contradictory Implications of Information Technologies,” Accounting, Management and Information Technologies (1:1), pp. 9-42.

Segars, A. H., and Grover, V. 1999. “Profiles of Strategic Information Systems Planning,” Information Systems Research (10:3), pp. 199-232.

Shepherd, D. A., and Sutcliffe, K. M. 2011. “Inductive Top-Down Theorizing: A Source of New Theories of Organization,” Academy of Management Review (36:2), pp. 361-380.

Tiwana, A., and Keil, M. 2009. “Control in Internal and Outsourced Software Projects,” Journal of Management Information Systems (26:3), pp. 9-44. MIS Quarterly Vol. 43 No. 2, Appendices/June 2019A17 Copyright ofMIS Quarterly isthe property ofMIS Quarterly anditscontent maynotbe copied oremailed tomultiple sitesorposted toalistserv without thecopyright holder's express writtenpermission. However,usersmayprint, download, oremail articles for individual use.