MANDATORY ARBITRATIONJimmy is 25 years old and recently gradu.docx

MANDATORY ARBITRATION?
Jimmy is 25 years old and recently graduated from Mercer
Pharmacy school. He is a pharmacist working for a drug store
chain and earns about $85,000 a year. His job requires that he
fill prescriptions. This entails a lot of standing and walking
short distances.
Jimmy has been experiencing a lot of lower back pain. He went
to see a neurosurgeon, named Dr. Strange. Surgery was
recommended. He had the surgery but now he is in worse pain
and unable to work because he cannot stand for long period of
time or walk much.
Jimmy went to another doctor. This doctor claims that Dr.
Strange committed malpractice. He writes a report of his
opinion for Jimmy.
Jimmy goes to see Ken Regent, an attorney. Regent gets the
medical records from Dr. Strange. In the medical records is a
document that is 12 pages long in 9 point type and covers a
variety of matters pertaining to the surgery and the consent that
Jimmy gave to Dr. Strange for the surgery to be done.
On page 9 of this document it says the following:
Any dispute arising from the relationship between the doctor
herein and the patient signing this agreement shall be submitted
to binding arbitration and the patient agrees to waive any right
to sue the doctor in a court of law. The arbiter shall be selected
by the doctor from a list provided by the National Association
of Medical Arbitrators.
The National Association of Medical Arbitrators is an

organization developed by the American Medical Association
for purposes of moving malpractice claims from the courtroom
to alternative dispute resolution. The arbitrators on this
association of eligible arbitrators must be doctors currently in
practice and must go through training provided by the
association.
When Jimmy signed the document he was about to be taken into
surgery and was in a lot of pain. The nurse who gave him the
document to sign said it was a form consenting to the surgery.
Regent wants to take the case to court. He believes that the
arbitration may not be fair. He would rather have a jury decide.
Discuss the following (and any other matters you choose):
1. What is arbitration?
2. What is binding arbitration?
3. What are some of the reasons why Jimmy would not want to
go to arbitration?
4. What arguments can be made that Jimmy should not have to
go to arbitration?
5. Should there be a law against some or all binding arbitration
agreements? Which ones? Why? Why not?
6. What arguments can the doctor make that the arbitration
agreement is legal?
7. What arguments can doctors make that such agreements are
in the public interest and should not be made illegal?
Internet-related crime occurs every minute. Cybercriminals steal
millions of dollars with near impunity. For everyone that is
captured nearly 10,000 or not captured. For every one
successful prosecuted in a court of law, 100 get off without
punishment or with a warning. Why is it so difficult to
prosecute cybercriminals?

Response Guidelines
Participants must create a thread in order to view other threads
in this forum.
Main Post is due by the end of Wednesday (250 words).
2 Responses (100 words) using at least one of the following:
· Ask a probing question.
· Offer a suggestion.
· Elaborate on a particular point.
· Provide an alternative opinion.
Please give references to the post he is asking for references
and taking out points.
Managing and Using Information Systems:
A Strategic Approach – Sixth Edition
Keri Pearlson, Carol Saunders,
and Dennis Galletta
© Copyright 2016
John Wiley & Sons, Inc.
Chapter 11
Project Management

2
Rural Payments Agency Case
What were the recurring problems with the RPA’s Single
Payment Scheme project between 2006 and 2014?
What system was rolled out in 2015 to solve the problems? How
did it solve the problems?
What problems occurred in 2015? What was the solution?
What were the causes of the problems?
© 2016 John Wiley & Sons, Inc.
3
Inequities, inaccurate property data, and delays in payments.
Led many farmers to go bankrupt.
Basic Payment Scheme. It fixed inequities and allowed richer
data to be collected (vegetation and terrain).
Identity verification wasn’t working well, the system was at
capacity and slow. The solution was to allow farmers to submit
paper, essentially going backwards 10 years.
Implementation began before the specs were agreed-on. Testing
was inadequate. Warnings were ignored.
3
Failed IS Projects
Standish Group found that:
67% of all software projects are “challenged!”
Late, or
Over budget, or
Don’t perform

Even one failure could endanger a firm!
4
4
Definition of “Project”
“[A] project is a temporary endeavor undertaken to create a
unique product or service.”
Temporary—every project has a definite beginning and a
definite end.
Unique—the product or service is different in some
distinguishing way from all similar products or services.”
-Project Management Institute (1996)
5
5
Project vs

OperationsCharacteristicsOperationsProjectsPurposeSustain the
firmReach a goalWhen to changeWhen operations no longer
serve the goalsWhen a goal is reachedQuality
controlFormalInformalTasksRepetitiveUniqueDurationOngoing
Temporary
6
Project Stakeholders
Anyone (or any firm)
Involved
With affected interests
Obvious players:
Project manager, project team
Project sponsor (general manager funding it)
Customers (huge variety)
Employees
7
Programs vs Projects
A program is a set of related projects that accomplish a strategic
objective
Examples: TQM; workplace safety

8
Project Management
“Application of knowledge, skills, tools, and techniques to
project activities in order to meet project requirements.”
Trade-offs must be made
9
Pick any two!
Time
Cost
Scope
Project Triangle
10
10

Picking any two
Fast and cheap: It won’t be good!
Slapped together or using interns
Fast and good: It won’t be cheap!
Purchase solution/hire “rock star” skilled team
Cheap and good: It won’t be fast!
This option is possible if you would wait for open source
solution or use
11
Project Management Software
Top five PM systems
Microsoft Project
Atlassian Jira
Podio
Smartsheet
Basecamp
12
Project Management Office
Project support
Project management process and methods
Training

Project management home base
Internal consulting and mentoring
Project management software tools and support
Portfolio management (managing multiple projects)
13
Essential Elements
Project management
Project team
Project cycle plan
Common project vocabulary
14
Element 1: Project Management
Identifying requirements
Defining the team’s structure
Assigning team members
Managing risks / leveraging opportunities
Measuring the project’s status
Making the project visible to others
Comparing project status against plan
Taking corrective action when necessary
Providing project leadership

Require planning
Require
taking
action
15
Project Leadership
Strong project leaders focus, align, and motivate members by
managing
Team composition
Reward systems
Strong processes trade off against strong leadership (next slide)
16
16
Project
Leadership
Project

Management Process
More leadership
Needed
Less leadership
Needed
No PM process
Team is new to PM process
Team does not value process
PM process exists
Team is fully trained in process
Team values process
Project leadership vs. project management process
17
17
Element 2: Project Team
Helpful: collect a set of people with the needed
Skills
Knowledge
Experiences
Capabilities
They must also represent their departments
18

Element 3: Project Cycle Plan
Organizes the steps and defines dates
Breaks work into phases
End is “go live” date
“Control gates:” ready to move to next phase?
Tools include PERT/GANTT
19
PERT
20
Gantt
21

Template – Other Views
Unfreezing
Change
Refreezing
22
Element 4: Common Project Vocabulary
Make sure everyone knows what the following mean:
“End of year”
“Divestment” vs “sale”
“Acquisition” vs “purchase”
“Customer” vs “user”
23
Difficulties

IT projects are difficult to estimate and most fail to meet their
schedules and budgets
Highly interactive, complex sets of tasks
Closely interrelated with each other (coupled)
Most projects cannot be made more efficient simply by adding
labor
Some are actually slowed down (Brooks’ Law)
24
24
Systems Development Life Cycle
SDLC typically consists of typical phases such as:
Initiation of the project
The requirements definition phase
The functional design phase
The system is actually built
Verification phase
The “cut over:” The new system is put in operation
The maintenance and review phase
Different models have different numbers of phases
25

25
Limitations of SDLC
Traditional SDLC methodology for current IT projects are not
always appropriate:
Sometimes costs are difficult to estimate
Sometimes uniqueness makes previous experience hard or
impossible to find
Objectives may reflect a scope that is
Too broad (can’t solve it), or
Too narrow (not ambitious enough)
Might take too long when the business environment is very
dynamic
26
26
Alternative Approaches – for speed
Iterative approaches enable evolutionary development
27

27
Other Approaches
Prototyping
Build a high-level version of the system very quickly and get
feedback
Advantages:
User involvement early and throughout the development process
Disadvantages:
Documentation may be difficult to write
Users may not have a realistic scope of the system while making
decisions
RAD (Rapid Application Development) prototyping + 4-step
SDLC
Like prototyping, RAD uses iterative development tools to
speed up development:
GUI, reusable code, code generation, databases, testing,
debugging
Goal is much faster building of the system
28
28
Other Approaches (continued)
JAD (Joint Application Development) – IBM
Users are involved throughout the process
“Agile” approaches speed things up
XP (Extreme Programming), Scrum, etc.

29
User-centered design
Focuses on usability but uses many of the tools of RAD, JAD,
Agile, prototyping
Users participate and continuously evaluate usability
Usability.gov provides 209 guidelines
Technology is advancing so they are dated (e.g., touchscreen
tablets are not included)
“How or why” for touch PC O/S not yet settled
Requires multidisciplinary approach: psychology, graphic art,
Internet technologies, business needs, etc.
30
Open source approach
Uses crowdsourcing
Code is available for all to see and improve
Linux: the basis for
Android
Some Garmin GPS
Some Sony TVs

OS/X is based on BSD
BSD and Linux come from Unix
31
Comparison of
approachesMethodologyAdvantagesDisadvantagesSDLCStructur
ed approach
Phase milestones and approvals
Uses system approach
Focuses on goals and trade-offs
Emphasizes documentation
Requires user sign-offs Systems often fail to meet objectives
Needed skills are often difficult to obtain
Scope may be defined too broadly or too narrowly
Very time consuming Agile DevelopmentGood for adapting to
changing requirements
Works well when user requirements change continuously
Allows face-to-face communication and continuous inputs from
users
Speeds up development process
Users like it Hard to estimate system deliverables at start of
project
Under-emphasizes designing and documentation
Easy to get project off-track if user goals are
unclearPrototypingImproved user communications
Users like it
Speeds up development process
Good for eliciting system requirements

Provides a tangible model to serve as basis for production
version Often under-documented
Not designed to be an operational version
Often creates unrealistic expectations
Difficult-to-manage development process
Integration often difficult
Design flaws more prevalent than in SDLC
Often hard to maintain
32
What Makes a Project Risky?
Risk Framework
Complexity
Many parts? Impacts on rest of system? Global? Unfamiliar
hardware/software/databases? Changing requirements?
Clarity
Hard to define the purpose, input, and output?
Size
Cost, staff, duration, team, departments affected, lines of code
They are geometric, not linear (additive):
Having all three of these would be much more than three times
as bad as one of these.
33

33
Managing Risk from Complexity
Strategies to deal with complexity:
Leverage the Technical Skills of the Team such as having a
leader or team members who have had significant experience
Rely on Consultants and Vendors – for additional expertise
Integrate Within the Organization such as
Having frequent team meetings
Extensive documentation
Regular technical status reviews
34
34
Managing Risk from Clarity
Strategies to deal with low clarity
Rely more heavily upon the users to define system requirements
Manage stakeholders by balancing the disparate goals
Sustain Project Commitment
35

35
Project Commitment –
Important for project
successDeterminantDescriptionExamplesMore likely for
commitment if:ProjectObjective attributes of the projectCost,
benefits, expected difficulty, and durationThere is a large
potential payoff.PsychologicalFactors managers use to convince
themselves things are not so badPrevious experience, personal
responsibility for outcome, and biases.There is a previous
history of success.SocialElements of the various groups
involved in the processRivalry, norms for consistency, and need
for external validationExternal stakeholders have been publicly
led to believe the project will be
successful.OrganizationalStructural attributes of the
organizationPolitical support, and alignment with values and
goalsThere is strong political support from executive
levels.Cultural Cultural attributesAppreciation for teamwork or
a focus on technical issuesThere is a culture of teamwork.
36
Pulling the Plug
Often projects in trouble persist long after they should have
been abandoned—Pull the plug!
Many projects are 99% complete for 50% of the project!
People can go to great lengths to sustain a doomed project when
there are
Sunk costs
High penalties for failure

Emotional attachment to the project by powerful individuals
37
37
Four dimensions of success
Shenhar, Dvir and Levy’s (1998) four dimensions of success:
Resource constraints: does the project meet the time and budget
criteria?
Impact on customers: how much benefit does the customer
receive from the project?
Business success: how high and long are the profits produced by
the project?
Prepare for the future: has the project enabled future success?
Future impact?
38
38
Figure 11.11 Success dimensions for various project types.

39
Managing and Using Information Systems:
A Strategic Approach – Sixth Edition
Keri Pearlson, Carol Saunders,
and Dennis Galletta
© Copyright 2016
John Wiley & Sons, Inc.
RESEARCH ARTICLE
MUTUAL UNDERSTANDING IN INFORMATION SYSTEMS
DEVELOPMENT: CHANGES WITHIN AND ACROSS
PROJECTS1
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]}
Although information systems development (ISD) projects are
critical to organizations and improving them has
been the focus of considerable research, successful projects
remain elusive. Focusing on the cognitive aspects
of ISD projects, we investigate how and why mutual
understanding (MU) among key stakeholder groups
(business and information technology managers, users, and
developers) changes within and across projects,
and how it affects project success. We examine relationships
among project planning and control mechanisms;
sensegiving and sensemaking activities by, and MU among,
these stakeholder groups; and project success.
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/13980 MIS Quarterly Vol. 43 No.
2, pp. 649-671/June 2019 649

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).
650 MIS Quarterly Vol. 43 No. 2/June 2019
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 in
organizations 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 sensemaking3 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 2019 651
Project Management Mechanisms
Mutual
Understanding
Project
Success
Sensegiving
Sensemaking
Cognitive Activities Cognitive Outcome Project Outcome
Planning
Mechanisms
Control
Mechanisms

Sensegiving
Potential
Sensemaking
Potential
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.
Table 1. Implications of Project Planning and Control
Mechanisms for Sensegiving and Sensemaking
Type of
Mechanism
Potential for
Sensegiving
Potential for
Sensemaking References
Planning
Comprehensive High Low
Bowman et al. (1983); Levina (2005); Segars

and Grover (1999)
Emergent Moderate High
Abdel-Hamid et al. (1999); Levina (2005);
Segars and Grover (1999)
Control
Self-control Low High
Henderson and Lee (1992); Kirsch (1996);
Tiwana and Keil (2009)
Clan control High High Kirsch (1997, 2004)
Outcome control Moderate Moderate
Choudhury and Sabherwal (2003); Kirsch
(1997); Nidumolu and Subramani (2003)
Behavior controls Moderate Moderate
Kirsch (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, the
functional 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.
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-
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 mechanism4 (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.
Table 2. Summary of Projects
Project Description Timeline
Informants*:
Total
(Primary) Roles of Informants
A1
Implemented technical feature to support
installation functionality. (Paired with A3)

Jan.–Dec.
2001
4 (2) Project Manager, Programmer,
Vice President, Product Manager
A2
Moved core product to a new technology
base and architecture to support future
usability enhancements.
June 2002–
Feb. 2003
4 (2) Project & Department Manager,
Team Lead, Vice President,
Product Manager
A3
Addressed 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 2003
5 (3) Project Manager, Team Lead
and Programmer, Product
Designer, Vice President,
Product Manager
A4
Involved porting desktop functionality of a

legacy product to the web. (Paired with A5)
Oct. 2002–
May 2003
5 (3) Project Manager, Team Lead,
Product Designer, Vice
President, Product Manager
A5
Involved enhancing web and desktop
functionality. Originally included in project
A4, but later removed and made into a
separate project. (Paired with A4)
Feb.–Sept.
2003
7 (5) 2 Project Managers, 2 Program-
mers, Product Designer, Vice
President, Product Manager
A6
Added several specific features to Alpha’s
flagship product. (Paired with A7)
Sept. 2008–
Aug. 2009
5 (4) 2 Product Designers, Program-
mer, 2 Technical Writers
A7
Major 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
B1
Involved implementing a new product for its
customers, as well as new technology and
business processes. (Paired with B2)
Aug. 2001–
May 2002
2 (2) Business Project Manager, IT
Project Manager
B2
Ported 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 2003
Project Manager
B3
Insourced an existing customer product that
was previously outsourced and implemented
new business processes.

Feb. 2003–
Feb. 2005
2 (1) IT Functional Manager, Business
Project Manager
B4
Implemented functionality to enable
business units to modify their own (customer
facing) applications online.
March–Aug.
2004
Project Manager
B5
Implemented a third-party order
management system, integrated with
existing systems, and changed business
processes.
March–Dec.
2009
Project Manager
B6
Implemented new functionality for customer-
facing application and new business
processes.

July–Dec.
2009
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.
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.

Figure 3. Evolution of Projects at Alpha
Figure 4. Evolution of Projects at Beta
Figure 5. Changes in Mutual Understanding Within Projects
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.
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 understand
his 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-
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 they
were 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.

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, learning
from 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
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 in
disagreements 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,
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
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
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.
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 of
planning 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

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.
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
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

MANDATORY ARBITRATIONJimmy is 25 years old and recently gradu.docx

MANDATORY ARBITRATIONJimmy is 25 years old and recently gradu.docx

Recommended

Recommended

More Related Content

Similar to MANDATORY ARBITRATIONJimmy is 25 years old and recently gradu.docx

Similar to MANDATORY ARBITRATIONJimmy is 25 years old and recently gradu.docx (20)

More from alfredacavx97

More from alfredacavx97 (20)

Recently uploaded

Recently uploaded (20)

MANDATORY ARBITRATIONJimmy is 25 years old and recently gradu.docx