Credit: Getty Images
Social alignment among groups of stakeholders occurs when different stakeholder groups share understanding of a business outcome and commit to the outcome and the means to achieve it.12 Project management is more effective and efficient when stakeholders are socially aligned because it reduces friction each time a project decision is made. Without agreement among stakeholders as to what needs to be accomplished and how to do so, success becomes harder to achieve. While the benefits of stakeholder social alignment are clear, how project stakeholders can move toward and sustain social alignment remains unknown.13
To address this issue, we sought to determine how social alignment or misalignment develops, and how leaders can improve social alignment over time. We had a unique chance to learn answers to these questions through our involvement in a longitudinal case study of a digital transformation. The case involved the launch of one of Australia's first large-scale digital hospitals, one of the most significant organizational changes ever undertaken by an Australian health service.a Given the size and consequences of transformational projects, this is a context where social alignment is likely to be critical.
We found in our research that the process of achieving social misalignment involved four phases as did the process of achieving social alignment. These processes were linked, such that stakeholders moved through misalignment and alignment in a non-linear fashion. When we studied the trajectory closely and mapped it out, we noticed improvements in the trajectory due to practices that managers adopted. We also noticed poor trajectories when managers enacted these practices ineffectively or not at all. Through analysis, we identified three practices that help improve social alignment—Ramping, Holding, and Peaking.
In this article, we identify and describe the characteristics of these practices for improving social alignment in large complex projects. We begin by describing the project's context, because every project is different and the context of our site may have affected what we observed. With this context laid out, we then describe how alignment and misalignment developed at the sites,b followed by the practices that helped improve alignment.
We studied the rollout of a Digital Hospital implementation across public hospitals in a state in Australia. Two prior attempts had failed and it was widely agreed this was the final chance. Many factors involved were similar to those in comparable cases internationally, for example, major work practice changes, significant training, the required buy-in of clinical groups.11 However, some factors were also very influential in this local setting. We highlight two:
Institutional complexity and risk: The rollout was supported by the state government but each hospital service across the state was quasi-independent. Thus, each hospital's implementation involved multiple layers of governance—state, health-service, and hospital. The prior failed implementations had been led by the state, but this time the hospital services were taking greater control. Risks were significant because the health sector had experienced numerous recent IT scandals, including one of the largest IT failures in Australia's history.4 Digital hospital implementations globally were also being criticized.8
Strong funding and leadership: The project was relatively well-funded, with over AUD$0.5B invested by the state and other funds co-invested by each health service to go-live. The project also benefited from strong leadership. The CEO of one health service was a strong advocate and took it upon him/herself to wrest control of the project from the State, volunteer for his/her service to go live first, and prepare the health service for change.
We found the process of social misalignment involved four phases as did the process of achieving social alignment.
Two hospitals were selected to be the lead hospitals in the rollout, with others to follow. Each hospital was to implement a U.S.-developed Digital Hospital solution configured to the Australian context, with each site joining the one system instance (that is, one system for the state).c The two lead sites were called configuration sites because the system was configured to their needs as representatives of the other hospitals. To reduce risk, the implementation at the configuration sites and first few rollout sites was split into two waves. The first involved implementing modules for scheduling, documenting, order-entry and results-reporting, and wireless device integration. The second involved modules for research trials, anaesthetics, and medications. Reports and dashboards were also developed across both waves.
The findings in this article stem mostly from our findings at the larger of the two co-lead hospitals, which was the first hospital to go live in the state. The board meetings for the statewide rollout, which we attended, were held at this site. Through our attendance in these meetings, we observed how social alignment evolved during the implementation, not just at this site, but at other sites too. We also conducted 30 interviews with members from all major groups during the project to learn their perceptions and experiences over time, following an inductive research approach.7
We found that social alignment evolved non-linearly during the digital hospital project, shifting between misalignment and alignment. As Figure 1 shows, we identified four phases of social misalignment and four phases of social alignment.5 The accompanying table provides illustrative quotes from our interviews describing each phase.
Figure 1. Social alignment and misalignment observed in the case.
Our interpretation of our data was that periods of misalignment and alignment operated like two opposing pyramids that stakeholders scaled, with alignment and misalignment as the two peaks. We refer to them as pyramids because the lower levels appeared to provide the conditions for higher levels. For instance, the first phase of misalignment (separation) seeded the conditions for disrespect to emerge, which in turn seeded the conditions for lack of cross-disciplinary participation, which then led to social misalignment. Each higher level then fed into and reinforced conditions at lower levels, in turn deepening the issues at higher levels.
Fortunately, we found periods of misalignment could be broken if the stakeholders self-corrected and shifted adaptively toward alignment. The trigger was to identify feelings of separation as signaling the need to reconnect. For instance, project managers and clinicians typically come from very separate professional groups, but they could learn much from each other. Once they reconnected, stakeholders began to learn from each other, which led to respect, which then provided the foundation for cross-disciplinary participation and onto social alignment. Unfortunately, we also found social alignment was not necessarily self-sustaining because stakeholders could shift maladaptively back to periods of misalignment.
Figure. Example quotes to illustrate the phases of alignment and misalignment.
When we began our data collection at the project's inception phase, the first stage we observed was separation. This was natural because the different groups (clinicians, project managers, and executives) had such different backgrounds and historically had not been part of the same team. During the early period of our data collection, well before the first go-live, we found separation led to disrespect and growing social misalignment. However, as go-live approached, we found the negativity of misalignment and the presence of separation became salient, leading stakeholders to switch mindsets. They began to reconnect which helped them learn and respect each other and then work together. This led to a peak of social alignment around the go-live date. We then observed that the team reverted back to previous silos after go-live, leading to a phase of misalignment, only to rise again for the second go-live. In short, we observed an inverted S-shaped curve, falling, rising, falling, and rising again.
The Baseline case in Figure 2 shows our first impression of this curve. However, as we analyzed our interview data, we found it did not paint a correct picture because the second period of misalignment did not appear as strong as the first, while the second period of alignment appeared stronger. This led us to collect more data to learn what was causing the improved trajectory. We discovered several practices that were improving alignment over time. That is, while some aspects of the process we were observing were quite natural and perhaps to be expected, it did not have to be that way. We felt these insights could help other researchers and practitioners too given that prior studies have observed performance dips and learning curves in past work and have explicitly called for further study of them.9
Figure 2. Improved social alignment.
Figure 2 illustrates the practices we discovered in the case and how they helped improve the alignment trajectory. We identified the practices from our data and confirmed them with stakeholders at the study site. The graphs are stylized rather than derived from quantitative data, but they reflect our interpretation of our data.d Next, we discuss each practice and then discuss their combination in terms of effective/ineffective practice.
Ramping practices accelerate alignment by getting stakeholders to commit at a faster rate than they otherwise would. This is shown in Figure 2, where the second rise in the curve for Ramping rises faster than the second rise in the Baseline curve. Three practices appeared to improve Ramping. The common idea underlying all three is that to commit early and strongly, stakeholders had to believe the project was credible—that it would go ahead and succeed. There was a long history of failed IT projects in that region, and in EMR projects globally. No one wanted to be part of a failure.
Creating multifunctional teams with recognized leaders. The first important Ramping practice was to create multifunctional teams with recognized leaders at all levels. Project teams included clinicians from all major professional groups, directly enabling the cross-disciplinary participation shown earlier in Figure 1. Individuals were sought who had strong leadership qualities and peer respect. Getting doctors involved was especially critical and the hospital involved key doctors who had respect across all subspecialties and across all levels of seniority. In addition to helping internally, this helped motivate external stakeholders to get involved.
For instance, the Deputy Chair of one medical division began leading one project subgroup. Until that time, junior vendor representatives attended these meetings but at the end of an early meeting, the doctor stressed that he/she expected someone of his/her equivalent level to attend. From then on, a leader from the vendor attended all those meetings. Likewise, clinicians from outside the hospital who needed to provide input at key stages gave input early, and caused less obstruction when they disagreed, because they knew the reputation of those involved.
Motivating attention to operational matters as the foundation for innovation. The second important Ramping practice was to attend to operational matters as the foundation for innovation. Week after week, the researchers observed project meetings in which senior leaders went into great operational detail regarding the implementation. Several of them told us they wished they did not have to engage in such detail but they knew the need to get these details right if the system was to provide the platform for innovation they desired. Although this was recognized in both waves, a senior clinician with a very strong reputation for attention to detail was brought in during the second wave to bolster this effort. By getting their hands dirty in the detail, the leaders could then talk credibly with colleagues from across the hospital who were nervous about the system and who did not trust outsiders to honestly tell them about its fitness. By getting into operational detail, the leaders were building the respect they needed to further improve participation across the hospital.
Managing not avoiding risk. The third important Ramping practice we observed was to manage rather than avoid risk. The project was being implemented at a time when past IT failures were in everyone's mind. There were great pressures to reduce risk by delaying and descoping work, but project leaders also knew this would reduce the project's chance of ever being implemented because the public sector was so risk averse. Therefore, project leaders kept deadlines firm and managed risk rather than avoiding it (for example, giving clinicians the autonomy needed to act quickly and ensuring adequate support was on hand for them). This increased the project's credibility in everyone's eyes. As one of the most senior doctors stressed to all other doctors in a medical 'Grand Round' in the months before go-live, the project was simply going ahead and they all had to get on board to ensure its success. Moreover, their success in managing risk during the first wave's go-live gave them confidence in their ability to do so in the second wave. They were effectively honing their risk management capabilities over each wave, which in turn improved alignment.
Holding practices maintain alignment in the face of pressures to separate. This is shown in Figure 2, where the second fall in the curve for Holding falls slower and shallower than the second fall in the Baseline curve. We observed three practices that facilitated Holding at the hospital. The common idea underlying all three is the transformation was now owned by the business and the business needed to partner with IT to "bed down" and improve the system. In short, these practices gave the motivation and the structures to stay together.
Adjusting governance structures. First, the organization adjusted its governance structures to transition from a project mentality to a business-as-usual mentality. This involved giving user groups and the hospital's executive more decision-rights over the system's assimilation, with IT having a strong partnering role. For instance, while the project team made decisions regarding training in the pre-go-live state, the hospital and its divisions took greater responsibility over training post go-live and the IT group shifted to a partnership role by working with user groups to have 'adoption coaches' available to help clinicians as needed across the hospital.
Reallocating funding and resources. Second, the organization reallocated funding and resources in a timely manner to maintain momentum. Because projects are temporary and often underfunded, funding often dries up after projects go live, even though much remains to be done. Such shortfalls can derail projects, leading key staff to leave and misalignment to grow. To avoid such problems, leaders reallocated funding shortly after the project go-live, for example, by identifying how the new system could allow the organization to remove a number of staff positions and how this financial saving could be used to create a new set of roles focused on optimizing the system.
Managing expectations and knowledge-sharing. Third, the organization managed users' expectations and knowledge-sharing. This was critical because the rush to get the system ready for go-live meant that changes to the system still needed to be made and more training and practice changes were required after go-live. Predictably, many change requests were raised. Some units wanted the system to revert to old practices while others wanted even-more advanced features. The IT group needed to manage expectations, but they had to do so in a way that allowed the business to feel it owned the transformation. They did so by mining usage logs to identify business units that were using the system in advanced ways as well as business units that required more support. They then encouraged leaders from these units to interact to share knowledge about strengths and weaknesses of the system. By doing this at regular intervals, the IT group was able to facilitate knowledge sharing while still ensuring the business groups owned the project.
Peaking practices increase alignment to even higher levels. This is shown in Figure 2, where the second rise in the curve for Peaking rises higher than the corresponding rise in the Baseline curve. To achieve peaking required team members to be more able and motivated than previously. When we observed practices that facilitated Peaking, the common factor was that they related to the base of the pyramid in Figure 1—connection and respect. Connection gave teams a common identity and motivation and facilitated mutual learning that enabled members to perform to even higher levels, while respect enabled staff to put differences aside, trust each other, and focus on achieving the best solution possible.
Co-locating teams. One practice that facilitated Peaking was co-locating teams. Doing so gave team members the time and place to learn from one another and understand their differences. Keeping teams separate proved costly. For instance, at one stage, one team at an external site did not communicate the fact they were not meeting deadlines until their deadlines were well exceeded. In contrast, relationships with the vendor improved on the second go-live because they were co-located with the project team in the command center while in the first go-live they were given a separate room. We were told this improved relationships so much the vendor and client staff saw themselves as one while working together.
Because projects are temporary and often underfunded, funding often dries up after projects go live, even though much remains to be done.
Getting the right people at the right time in the right roles. A second practice that facilitated Peaking was getting the right people at the right time in the right roles. On one hand, some people were kept on during the project. Their knowledge and networks naturally grew over time, making them increasingly able to facilitate strong alignment. Meanwhile, other key people were replaced with new team members and new roles evolved. For instance, as the project shifted from implementation to assimilation, a new team of Adoption Coaches was created and influential clinicians from across the hospital were recruited into the lead roles. This increased respect for the project across the organization because the team members had the right skills at the right times.
Understanding the 'why?' A third practice that facilitated Peaking was clarifying the answer to "why are we doing this?" Because so much attention to operational detail was required to get the system implemented, it was easy to lose sight of the end goal and become demotivated. This was especially in the down periods in the months immediately after go-live when staff were experiencing what one executive likened to post-natal depression. To overcome this, the organization worked hard to clarify the 'why', and do so in the language of clinicians, that is, focused on supporting improvements in patient care. An important positive that came out of this was that it allowed the team to reflect on the clinical benefits that emerge from a successful project. This success of the first wave buoyed them and motivated them to see additional benefits that could stem from the next wave. Greater motivation could then be reached on the second wave because the end goal was clearer and more compelling.
Once the practices of Ramping, Holding, and Peaking, are understood, we can see how their combination, or lack thereof, can shape best practice and poor practice. As Figure 2 shows, best practice involves effective Ramping, Holding, and Peaking practices. Each dip becomes shorter, each rise becomes steeper, and each rise hits a new peak. Ineffective practice involves the opposite. Each dip is sharper, each rise is slower, and each new peak is lower. While the graphs in Figure 2 are stylized rather than based on quantitative data, we found evidence of both trajectories in the project we studied. At the lead hospital we studied, where all the practices described earlier were implemented, the trajectory was positive. The drop to misalignment was slower, the rise to social alignment was faster, and the level of social alignment was greater on the second go-live compared to the first.
We observed the opposite trajectory when these practices were enacted poorly or not at all. Our evidence for the opposite trajectory comes from a composite case we gathered data on during the study.e While the team came together for the first go-live, it soon became clear they had not laid the foundation for that alignment (that is, the base of the pyramid)—their alignment was more appearance than substance. They had, in fact, struggled with each practice we discussed. Ramping suffered because senior and powerful clinicians were not included sufficiently in the project. Disgruntled clinicians then resisted the system soon after go-live and voiced their concerns to external media. Holding suffered because the organization failed to reallocate funding and manage user expectations. This led users to lose faith in the system fueling disrespect on all sides. Peaking suffered because the site had used a large number of external consultants rather than internal staff in key roles. While the consultants could and did play an important role, the hospital simply did not have the right internal people in the right roles at the right times. Peaking became infeasible; the aim became salvaging any semblance of alignment at all. Of course, our conclusions here are bounded by the time of our study. In the period since we completed the study and wrote this article, our informal observations of the composite case have been that social alignment has recovered somewhat, with greater clinical involvement and realignment of key positions. While the process of recovery lay outside the scope of our study, it appears to conform to the framework in Figure 1, in that misalignment, even if severe, can return to alignment.f
Social alignment can be viewed as the glue that holds projects together. It helps people work together, stick together, and strive for shared goals. This article provides practical insights for how to achieve social alignment in complex projects when there are many factors working against it, such as when there are strong and diverse professional groups, multiple organizations, high stakes, and long periods. By collecting detailed evidence as a transformation project unfolded, and by comparing and contrasting different cases, we identified three practices that improved social alignment—Ramping, Holding, and Peaking. These practices motivated stakeholders to align, stay aligned, and strengthen alignment over time. While some of the practices can be found in prior work, this article contributes by revealing how they can come together in a coordinated way to improve social alignment over time and the consequences of not doing so.g While some of these practices might have been expected in advance, not all of them were. In particular, one of the Holding practices (adjusting governance structures) proved particularly challenging and represents an area where more attention could be placed in future projects. We hope the results of this study will motivate future research to test and extend the insights we have offered.
This research was supported by the Australian Research Council (FT130100942, DP140101815, LP170101154), University of Queensland (UQFEL1719117), and Metro South Health.
1. Austin, R.D., Nolan, R.L. and Cotteleer, M.J. Cisco Systems, Inc.: Implementing ERP. Harvard Business School Case, 2002, 1–19.
2. Burke, T.K. Providing ethics a space on the page: Social work and ethnography as a case in point. Qualitative Social Work 6, 2 (2007), 177–195.
3. Burton-Jones, A., Akhlaghpour, S., Ayre, S., Barde, P., Staib, A. and Sullivan, C. Changing the conversation on evaluating digital transformation in healthcare: Insights from an institutional analysis. Information and Organization 30, 1 (2020), 1–16.
4. Chesterman, R.N. Queensland Health Payroll System Commission of Inquiry. State of Queensland, 2013.
5. Gilchrist, A., Burton-Jones, A. and Green, P. The process of social alignment and misalignment within a complex IT project. Intern. J. Project Management 36, 6 (2018), 845–860.
6. Gilchrist, A., Burton-Jones, A., Green, P. and Smidt, M. The process of social alignment and misalignment within a complex IT project. In Proceedings of the 38th Intern. Conf. Information Systems, (Seoul, Korea, 2017).
7. Glaser, B.G. and Strauss, A.L. The Discovery of Grounded Theory. Aldine, Chicago, 1967.
8. Martin, S.A., and Sinsky, C.A. The map is not the territory: Medical records and 21st century practice. Lancet 388 (2016), 2053–2056.
9. McAfee, A. The impact of enterprise information technology adoption on operational performance: An empirical investigation. Production and Operations Management 11, (2002), 33–53.
10. Nelson, R.R., and Jansen, K.J. Mapping and managing momentum in IT projects. MIS Q. Executive 8, 3 (2009), 141–148.
11. Ranganathan, C., Watson-Manheim, M.B., and Keeler J. Bringing professionals on board: Lessons on executing IT-enabled organizational transformation. MIS Q. Executive 3, 3 (2004), 151–160.
12. Reich, B.H., and Benbasat, I. Factors that influence the social dimension of alignment between business and information technology objectives. MIS Q. 21, 1 (2000), 81–113.
13. Van der Hoorn, B. and Whitty, S.J. The praxis of 'alignment seeking' in project work. Intern. J. Project Management 35, 6 (2017), 978–993.
a. It was transformational due to its size (a large, multi-site implementation) and its effect (dramatically changing how the service functioned). For a similar definition, see Burton-Jones et al.3 After implementation, the site achieved Stage 6 on the HIMSS Electronic Medical Record Adoption Model (EMRAM), one of only three Australian hospitals at that time, and the largest of them, to be so designated.
b. Earlier versions of this first part of our analysis are available in Gilchrist et al.5,6
c. Such systems are often known by their component functionality, such as an electronic medical record (EMR), electronic prescribing (e-prescribing), computerized decision support system (CDSS), and computerized physician order entry system (CPOE). The implementation we studied comprised all these components together with wireless device integration and a full (and growing) set of reporting and data analytic components, with the aim of transforming how the hospitals provided their services.
d. The method used to plot our findings was inspired by studies of momentum, see Nelson and Jansen.10
e. A composite case is a case that combines characteristics of multiple cases rather than one case. We use a composite case because the implementation program is ongoing and it is more constructive to learn general lessons than to single out individual cases; see Burke.2
f. While we do not have formal data on how alignment improved at the composite case, we hypothesize that it is due to the implementation of some of the best practices noted earlier. We hope to verify this in future.
g. For instance, the case study of Cisco's ERP implementation provides vivid examples of what we would describe as peaking practices and holding practices, see Austin et al.1
©2020 ACM 0001-0782/20/9
Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and full citation on the first page. Copyright for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or fee. Request permission to publish from [email protected] or fax (212) 869-0481.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2020 ACM, Inc.
No entries found
