1 Introduction

Many large-scale transformation projects do not live up to expectations (McAfee and Andrew 2003; Scott and Vessey 2000) and are considered ‘failures’ (Loukis and Charalabidis 2011). Projects can be delayed, become more expensive and provide less functionality, or they may even completely fail and have to be redone. What a failure exactly constitutes is often open to discussion and depends on the stakeholders’ views on a project. Where one stakeholder might consider the project successful, another might think that it failed. Different stakeholders have their own metrics for determining success or failure. Transformation projects can be deemed as failures due to their inability to meet requirements or create a working system, and might be viewed as successful even if exceeding the deadline and/or budget or delivering only part of the desired functionality. From this viewpoint, project failure can be ranked on a scale ranging from not delivering the required functionalities to complete failure in which almost all efforts and funds are wasted. Oftentimes projects are evaluated based on the delivered functionalities, budget used and time spent in finishing the project.

Project failure has been studied extensively (Daniels and LaMarsh 2007; Lu, Liu, and Ye 2010; Pinto and Mantel 1990; Yeo 2002). There are several categorisations of project failure, including failures of people, process, product and technology (McConnell 1996). Nelson (2007) uses this categorisation to list classical project management mistakes. Factors like complexity, uncertainty, scope creep, opposing stakeholder requirements, lack of top-management support and resistance are frequently mentioned in the literature as factors that contribute to project failure (Daniels and LaMarsh 2007; Lu et al. 2010; Nelson 2007; Pinto and Mantel 1990; Yeo 2002). The internal and external business environments are often evolving at a rapid pace during the project resulting in changes in customer requirements, markets and regulations. During a project many incidents ensue which originate from the inability to predict and anticipate all events and concerns (Besson and Rowe 2001). Bottom-up processes can result in often unintended or unforeseeable consequences of individual-level behaviours (Nan 2011). This changes and emergent behaviour suggests that a project’s dynamics influence its management and make it hard to follow any predefined plan. Development methods are used for reducing risks of failures by managing of the complexity of the information systems development process and product. Traditional methodologies, however, are not adequately equipped for dealing with non-linear interactions endemic to such complex systems (Samoilenko 2008).

Large transformation projects contain a multitude of actors interacting with each other resulting in project dynamics. These actors are self-interested and are influenced by changes which might reinforce each other. The inability to deal with these dynamics is often a major cause of project failure. Although project dynamics are acknowledged as an important failure factor, they are given limited attention in the literature. The exception is work concerning solutions for the investigation of scheduling dynamics, often from a systems dynamics viewpoint (Rodrigues and Bowers 1996; Rodrigues and Williams 1998). The research suggests that the interrelationships between a project’s components are more complex than previously considered. Yet none of the research takes a Complex Adaptive Systems (CAS) view which is suitable for looking at the interactions among the agents. CAS views the dynamics among technology and human agents over time. Nan (2011) argues that the CAS lens achieves a deeper and more holistic analyses and provides a natural scheme for researchers to conceptualize the dynamic nature in which technology and human actors play a role. Viewed through a CAS lens, factors that generate the dynamics associated with project failure are recognised and will be investigated in this paper.

Lewin and Regine (1999) translated CAS concepts to the organisation realm. They claim that healthy organisations function much like a flock of birds, with individuals following simple rules and interacting with others to form a cohesive and dynamic whole. Large-scale projects can be viewed as CASs. Although large-scale projects are managed, there are so many persons involved, including sponsors, champions, project managers, users and other actors, and they all influence the outcomes, that centralised, hierarchical control is not possible. A project does not exist in isolation; it is subject to all kinds of influences of its environment. There is no entity that has the power or the position to control the system, and the dynamics are created by interaction among the actors and with the environment. Each actor has an idiosyncratic view on the project, and the interactions among all actors make up the project as a whole.

CAS is closely linked to chaos and complexity theory. Whereas chaos theory demonstrates that events might have unpredictable consequences; complexity theory describes how certain interventions can results in non-linear behaviour but might produce simple effects (Holland 1996) and tend to be self-organizing evolving towards order (Anderson 1999). The management of CAS is based on the acknowledgement of having both emerging and planned parts. Although parts of the situations are planned and can be controlled to some extent other parts might not be or are hidden from the view of the management. Large projects cannot be completed detailed and planned from the start, as the complexity is simple too high and as over time, their purpose and use may change, which in turn may influence their development.

Nan (2011) concluded that CAS provides a conceptual view of the inner workings of a bottom-up information technology use process, but has not yet surfaced explanatory or predictive statements. Yet, CAS suggests that complex systems can be guided with relatively simple principles (Anderson 1999; Janssen and Kuk 2006; Johnson 2010). In the typical example of a CAS being like a flock of birds, the individual birds continually adapt to changes in their environment, but obey the rules of alternative position and distance to each other. These birds are able to self-organise in such a way that certain phenomena arise. CAS aims at understanding, predicting and controlling phenomena arising from interacting objects (Johnson 2010). By conceptualising complex situations, CAS managers can gain a better understanding of the dependencies involved and develop principles to guide individual behaviour to direct a project’s evolution (Janssen and Kuk 2006). In a similar vein, management principles can be used for self-organising in complex projects and to attain certain benefits. CAS has been successfully applied in various domains (Auyang 1998; Innes and Booher 1999; Merali 2006), but to our knowledge it has not been used for understanding the dynamics in large-scale projects and for identifying self-organising principles.

In this paper we use complex adaptive systems theory as our empirical lens to examine the dynamics in a large-scale and complex project. We investigated a large-scale transformation project that had been running for over 6 years. The project was initiated as a project in which businesses and organisations were making a transition from using paper forms to digital information, whereas the need for transformations appeared throughout the project. To reap the gains of digitization, business processes and relationships among stakeholders need to be changed and systems altered. From interviews we gained in-depth knowledge of the factors influencing failure and adoption by users.

This paper is structured as follows. In the next section the background of CAS is presented followed by the research methodology in Section 3. The case study description is presented in Section 4. From the case study we derive factors affecting the dynamics, which are discussed in Section 5. This is followed by the identification of management principles for dealing with the dynamics. Finally we draw conclusions and provide recommendations for further research.

2 Background

CAS are a certain type of complex systems. The CAS lens focuses on complex and emergent properties of the systems (Holland 1996). The theory of CAS can be used to characterise and understand organisational behaviour (R. Lewin and Regine 1999; Merali 2006; Nan 2011) by looking at the dynamic interactions among entities (Holland 1996). Whereas organization theory has treated complexity as an independent variable, in CAS behaviour of complex systems is hard to predict because it is nonlinear (Anderson 1999). Capturing the nonlinear outcomes of many interacting components has been difficult that both social and natural scientists have tended to select more analytically tractable problems (Casti 1994). The complexity is created by the many different users and systems and changes over time.

In essence, CAS is the study of systems built of individual entities, often called agents, that are capable of interacting with each other and with an environment especially the attempt to understand how the individual affects system-level responses (Auyang 1998). Intervening to change a parameter can result in emergent behaviour and might drastically change the whole system. The system can become very different from the sum of the parts resulting in a complete reconfigurations of the elements. Emergence refer to the patterns arising out of a multiplicity of interactions among the interacting agents. In projects individuals interact can results in collective phenomenon. During these interactions inscribed schemes and rules are activated, in this way shaping the behaviour of actors involved (Orlikowski 2000). CAS resists reductionist analyses and focusses on understanding the complex system by looking at the individual agents and their interactions.

Although there is no uniform definition, CAS can generally be defined as “a system that emerges over time into a coherent form, and adapts and organizes itself without any singular entity deliberately managing or controlling it” (Holland 1996, p. 10). Anderson (1999) argued that complex adaptive systems can be summarized in terms of four properties; agents with schemata, self-organization, co-evolving agents, and system evolution.

  1. 1.

    Agents with schemata; the basic idea is that the level of analysis is at a lower level of aggregation. In other words the behaviour of a system is made up of interacting subsystems. Translated to projects, a project is made up of individuals, coalitions that have non-linear interactions. The dynamic behaviour needs to be understood. Only by influencing the behaviour of individual agents system level changes can be accomplished.

  2. 2.

    Self-organization: Agents are connected to and interacting with each other resulting in dynamic behaviour. These interactions can result in feedback without that there is a single coordinator directing these interactions; which is named self-organization. In self-organization of actors aspects like goals, interest, mutual understanding, goodwill and trust, but also resistance and other social factors might play a role. Although project managers are coordinating, project members, users, experts and other actors will interact with each other resulting in self-organization.

  3. 3.

    Ce-evolving agents. Individual agents are directed by others and their own goals and interest. Continuous changes are needed to maintain its fitness relative to the others agents it is co-evolving with. An event generated by one agent might result in a reaction by other agents which are adapting to the environment. For example, as a consequence of feedback loops a small delay might result in a whole chains of delays resulting in a significant delay for the whole project.

  4. 4.

    System evolution. New agents can enter and others can disappear and the linkages among agents can change over time resulting in system evolution. New persons might start working on a project and others might leave, also new technology might be introduced or technology systems might be abandoned.

CAS models have an inherently multilevel nature as direction and order is an emergent property that depends on how lower-level behaviours of individual agents. CAS are often modelled using agent-based systems (Alberola et al. 2013; Nan 2011), which takes the individual level as starting point to understand the system level. CAS models consists of individual agents following a set of rules in which interactions results system-level behaviour. The emergence of adaptive behaviour can only be influenced indirectly by altering the behaviour of the individual agents or by altering their relationships in a network. The analysis conducted in this study is by analysing the stakeholders and their interactions in a large and complex project.

3 Research approach

Due to the complex nature of the project and the need to gain a deeper understanding of the factors influencing the project dynamics, a qualitative approach based on case study research was adopted for this research (Yin 2009). The case study was selected because it concerned a large-scale project for which a large amount of information and reports were available, which helped us to understand the project dynamics. Furthermore, interviewees were relatively easy to identify and to access. We conducted a search on the Internet and of two major Dutch ICT-magazines. This helped to create a retrospective picture of the project dynamics. This picture provided us with the content and the scope of the project.

Sources of project failure literature were used to derive factors influencing the dynamics in the case study. Publicly available documents were systematically analysed first. This helped us to understand the project dynamics and the management interventions taken in the past. In the following step fifteen semi-structured interviews were carried out over the course of a three-month period. The fifteen interviewees included project managers, software developers, user associations and various types of users. Representatives from both small and medium-sized enterprises (SMEs) and large user organisations were interviewed. This allowed us to understand the diversity of users. All interviews lasted between 60 and 90 min. Most interviews were conducted by two researchers who compared results afterwards; some interviews were conducted by one interviewer. Transcripts of the interviews were made, and all interviewees were given the resulting report (Janssen et al. 2010). The interviews allowed us to gain an overview of the factors influencing project failure, user adoption and project dynamics as well as the impact of management strategies. The initial interviews were followed by six additional interviews conducted between September 2011 and February 2012. These six interviewees included project managers, software developers and a large user organisation. This allowed us to gain a longitudinal perspective and to understand the project dynamics and its impact.

4 Case study of XBRL and SBR: Background

Business-to-government information sharing happens in many areas, ranging from tax information to social statistics. Business-to-government information sharing is said to be the a next frontier for reducing government spending while improving performance (Bharosa et al. 2013). Businesses have to report all kinds of information so that governments can monitor the extent to which companies comply with the established laws and regulations. The introduction of the international Extensible Business Reporting Language (XBRL) standard and the initiation of Standard Business Reporting (SBR) in the Netherlands was set up to transform the process of legally required financial reporting by companies. This project has aimed to deal with the fragmentation caused by the current situation, in which a large number of documents must be submitted on paper to various public organisations. The goal is that after the project’s completion information can be electronically reported a single time and the information will then be distributed to the appropriate public agency.

Given the scope of this project, an immense number of organisations are involved. The public organisations all posed their own reporting standards and requirements. Figure 1 gives a simplified overview of the desired situation, in which reports are based on a shared taxonomy and submitted over a common gateway. Instead of all government agencies defining their own requirements for these financial reports, a taxonomy was created to harmonise definitions used by the Dutch government in the financial domain. A common process infrastructure is still under development to be used for submitting all financial reports. Although the XBRL standard can be used for financial reporting across many sectors, the current project set-up includes only a few reports: tax reporting to the National Tax Service (Belastingdienst), the submission of financial year reports to the Chambers of Commerce, and the submission of data to the National Bureau for Statistics (CBS) (Bharosa et al. 2013). The process infrastructure that was developed to facilitate data exchange consists of a unified gateway for transferring bulk data to various government agencies. For the delivery of financial information the companies report financial and other information to the government and are the end-users. Companies often use software or Software-as-a-Service (SaaS) solutions to submit their information to the government. Furthermore, most businesses use financial intermediaries for preparing and auditing their reports. Software providers and financial intermediaries also use the gateway and are called users.

Fig. 1
figure 1

Information exchange between the main actors

Full size image

Because financial reports will be generated using an open standard, organisations are able to innovate. New applications may emerge, and new organisations may develop new services. This will likely result in a transformation of the situation in the traditional value chains. It is expected that especially the role of financial intermediaries will change. An example of this is that in the future banks might also receive information using XBRL (See Fig. 1), although this probably will be done using a different infrastructure and accompanying gateway.

The project has aimed to contribute to the central government’s agenda of achieving a decrease in the administrative burden to businesses. In 2007 the central government estimated that around 350 million euros worth of businesses’ administrative tasks could be cut and around a million tax filings using XBRL could be achieved yearly by 2008. Also, it was expected that in 2007 the first version of the process infrastructure developed for exchanging data based on XBRL would be ready. However, it was not expected that an authentication mechanism needed to be developed. In 2009, however, it appeared that none of the above-mentioned goals were met or would be met within a short time frame. Throughout the project the visions and objectives had become lost, and the focus had shifted from reducing administrative burden towards a focus on technology in which users were given hardly any attention. Generally, businesses and government agencies claimed that they were not yet ready for implementing the XBRL standard or submitting their reports. They often stated that they were waiting for the central government to make decisions before they invest. A set of factors affected the adoption by users and end-users which will be discussed next.

Table 1 gives an overview of the main events. A more detailed account can be found in (Janssen et al. 2010). From the overview it is clear that there were very high expectations at the beginning of the project which could not be realised. Furthermore, only after some time was the awareness raised about feasibility and were discussions begun about the money spent to realise the objective. User needs evolved over time, there were changes in platform and target technologies, and new insights were gained during the project that were incorporated on the fly. The initial idea was changed over time, and new issues were added. The history also shows that limited attention was initially given to the users (businesses), while other public and private parties were heavily involved.

Table 1 Historical overview
Full size table

5 Project dynamics

In this paper we focused on the dynamics of the project instead of the adoption principles, which can be found in Janssen et al. (2013). The case study showed a number of patterns characterising the dynamics of the project. We clustered the patterns in a number of categories to make them more manageable. The patterns are sometimes related to and dependent on each other; they are not mutually exclusive.

5.1 Piecemeal and organic growth

A large number of stakeholders, coming from both the public and private sector, are involved in the project. The project was initiated at the ministerial level and a large-scale approach was taken, involving as many stakeholders as possible, resulting in organic growth. One reason for this large-scale involvement was to ensure the commitment of all organisations and to allow all possible requirements to be identified and all voices to be heard. By involving all stakeholders, the idea was that less resistance would be created and the transformation would take place more easily.

What happened was the opposite. By involving a large number of various players the progress was delayed. There were struggles concerning which requirements to include. Instead of creating supporters, resistance grew. Whereas there were supporters at the start, users became disillusioned by the limited progress. The direct visible results took a long time to realise. Over time the disadvantages and risks took on greater properties than the possible benefits.

The involvement of a large and diverse set of stakeholders requires that an incremental and piecemeal approach be taken. The project developed organically and has been influenced by the many stakeholders pushing and promoting certain issues. The initial focus of the project was not on developing and making a system work but on identifying all possible conflicting views. Consequently, the project grew of its own accord and all kinds of opinions were presented and communicated. One interviewee mentioned “there were so many players and they all seems to favour something differently sometimes even opposite”. Stakeholders pursued other directions and vented their opinions in online discussion groups and newspapers, undermining the project’s credibility (one reason for doing this was that their core values were affected, see below).

Due to the complexity and the many stakeholders, the time horizon of the project was extended and the initial IT was succeeded by new technologies. The project chased the new technology, whereas the old technology was not yet under control. The hope was that the new technology would solve ‘the problem’. Yet instead it created even more delay. The focus remained on innovation instead of on implementation and ensuring a stable and sustainable platform. Overall, the organic and piecemeal growth resulted in a situation of muddling through. It delayed and frustrated the project instead of furthering the intention of ensuring commitment and overcoming resistance.

5.2 Scope creep: Changing ambition levels

The scope and size of the project changed several times. Changes in the scope influenced the business case for adopters. This influence was strengthened by the high ambition level. The project was announced as offering a solution for companies that would enable them to provide all information required by the government by pressing a single button. Other activities needed, such as the collecting and processing of this information, were not mentioned. During the project this caused resistance, as people had not expected it.

Instead of making the system work for one sector (financial reporting) the project focused on broadening the scope and involving more companies coming from other sectors. The project tried to involve the banking sectors as well, as these were also interested in the new financial reporting option. This was expressed by an interviewee as “the adding of the banks was a good idea to gain more commitment, however, it also resulted in more tensions and complexities”. Instead of lowering resistance and gaining acceptance, this resulted in new requirements being laid on the system and on the companies providing the information. Ultimately this scope creep resulted in more delay and resistance.

Potential users were lured in with a promising business case, and they often made the initial arrangement to adopt. After some time it became clear that new elements had been added and that there was no working system that they could yet adopt. In order to adopt the system they would need to change their processes and systems once again, requiring another round of adoption investments to be made. Due to the uncertainty of continuity and a lack of a working system, most users opted to not adopt but to wait for a full-fledged version to arrive. In other words: a ‘first mover disadvantage’ emerged. As a result the enthusiasm of the initial early adopters was lost.

Development problems were tackled by adding new elements to solve the initial problems. Although this sometimes solved the actual problem, it also resulted in additional complexities that then needed to be managed. It also introduced new risks. The way these risks were handled was the same way that the risks had been created, by adding new elements, which again added to the complexities. This continued until the complexity reached such a level that the project could no longer be managed. Overall, the scope creep resulted in an increased complexity, further delay, and a blurred picture concerning the ambition level. This influenced the adoption of stakeholders, as the initial enthusiasm of most of the early adopters was lost.

5.3 Continual changes as a certainty

The many changes throughout the project resulted in the stakeholders becoming uncertain about the direction of the project, what it would deliver and how it would help them. This uncertainty was further aggravated by the absence of a plan for continuation after the end of the project. In the project there were constant changes, resulting in uncertainties about outcomes and a focus on dealing with incidents. One interviewee expressed the project as being very volatile: “I was lost in the landscape, one day it seemed to be perfectly all right, the next day the landscape looked different”. The many uncertainties and changes were expressed by the many news items that were published in magazines throughout the project. These news items found in the magazines were a way for stakeholders to express their opinions. The negative news items not only influenced the direction of the project, but also had a negative effect on the adoption by users, creating a vicious circle.

Realising process change and transformation proved to be time consuming without some reference point for actors. In other words: in this time of continual change some form of freezing seemed necessary. During the project, new applications of the technology were found. Initially these kinds of features were added and included. After a while there was awareness that this would not advance the project. A clear scope was defined to ensure that part of the system could be developed. Freezing, however, proved to come with a price. The scope was found to be too narrowly defined. This resulted in the need for users to have multiple processes in place and in the need to change their processes in the future. The narrow scope resulted in a system that did not have all needed functionality to deal with all types of processes. Finalising one software component did not contribute to creating any value, as all components are necessary for the system to work. The potential efficiency gains, however, are tightly intertwined with the implementation of the complete process infrastructure. “XBRL as such does not lead to a decrease in the administrative burden, as it is about the way in which it is applied”. In conclusion, there is a continuous tension between expanding the project and limiting the functionalities. The first results in a delay, whereas the second results in fewer and lesser benefits for the users.

The simultaneous innovation and development of the system resulted in uncertainties about the outcomes. The innovation about how the new infrastructure would look was never completed. Instead, when new developments and technologies entered the project, the stakeholders tried to include them in the system development, resulting in changes in the project and the resulting outcomes. The mixing up of system innovation and system development resulted in unclear goals and uncertainty about what would be delivered. One interviewee concluded that “the changes contribute to less adoption … due to the many changes the project will be in the news again, resulting in yet another uncertainty to adopt”.

During the project there was uncertainty about the control and maintenance that would be available once the project had ended. The project concerned the development of a new system, but no budget was reserved for maintaining the system after the project’s completion. Stakeholders were reluctant to adopt, as there was no certainty about its continuity. Users would have to change their processes and systems at the risk that once the project ended they would no longer be able to use the system. Only at a later stage was long-term sustainability created, by involving the control and maintenance organisations of the government, which would ensure control and maintenance in order to keep the system functioning.

Finally, due to the long duration of the project, key personnel moved away and with them the knowledge they possessed. This blocked organisational learning, as new staff first needs to understand what is going on. Organisational memory disappeared, resulting in the same failure being made several times. This then resulted in the uncertainty of still others, as contact persons disappeared and were replaced by others who had a (slightly) different view and who made other promises.

5.4 Stalemates due to catch-22 s

The case study is a public project that relies on adoption by both public and private actors. A complicating factor for its adoption proved to be the dependencies between the law and technological development. During the project questions were raised as to whether electronic reporting is legally allowed and about the degree to which these financial reports created had sufficient quality to comply with the law. The conformity with law was contested several times, resulting in further delays. A tension was whether technology innovation is necessary before the law can be changed, or if the law needs to be changed before a technology innovation can materialise. A ‘catch-22’ emerged. The intertwinement of law and technology clouded what should be done first: a legal change or the development of a working infrastructure. This catch-22 resulted in stalemates, because neither the lawmakers nor the adopters had the urge to make the next move. Whereas lawmakers prefer to codify rather than modify, adopters feel much more comfortable if their potential investments are indeed necessary, even compulsory. The project technology development was therefore waiting for a change in the law, whereas a legal change first had to wait for the technology innovation to be ready. Not having both in place resulted in many stakeholders making no critical decisions and furthermore resulted in ambiguity and expectations that could not be met.

5.5 Business case as a moving target

The project was launched with the promise that all information would be delivered by pressing a single button. The efficiency gains were presented to feed the business cases of the adopters. This was called the ‘reduction of the administrative burden’ of reporting to the government. This promise made the project attractive for many parties – both public and private – but of course neglected organisational realities. It would prove not to be about pressing a single button, but that a range of tasks would need to be conducted before the information could be transmitted. The simplified introduction guaranteed political and administrative commitment and could well have been essential for the project to exist at all. The price of this framing, however, has been high, sometimes even leading to unrealistic expectations.

New opportunities arise through the standardisation of financial reporting and the implementation of a common gateway. When more and more businesses and government organisations start using XBRL for their information exchange processes, business models and processes are likely to change. This in turn is likely to result in new opportunities. For example, in the future it will be possible to report also non-financial data using XBRL, such as data on insurances or inventory systems, and to allow for process integration beyond the boundaries of individual companies. This will result in benefits in other areas than initially expected. Although the project impacts the way information is reported and requires a considerable transformation of both businesses and government, it was primarily viewed as a technology project. The change in business processes was given only limited attention, whereas the collaboration with software developers and vendors was given a lot of attention, reinforcing the focus on the technology aspects. By focusing on these types of stakeholders most attention was given to the technology, instead of to realising the business case and creating value for the users. In the literature it is recognised that the focus on the technology resulted in a loss of emphasis on the business purpose to be achieved and a neglect of the fundamental organisational and behavioural changes implicated in (Willcocks et al. 1997). Another reason for focusing on the technology was the immaturity of the technology at the start of the project. It was not proven that the technology could achieve the intended solution, and there were hardly any working examples that could function as benchmarks. The focus was on making the technology work rather than on the reduction of the administrative burden for companies.

After time the promised reduction of the administrative burden became questionable. Initially the anticipated reduction of the administrative burden due to the technology innovation was expected to be higher. The requirements for gaining the benefits were different per stakeholder group. In compromising, these maximum benefits could not be achieved. This impacted the business case, yet the business case was not revised. More and more, users expected that efficiency gains could not be accomplished on their side, but no realistic alternative was given as to what would be possible. Nevertheless they were willing to collaborate if this would result in efficiency gains on the government side. “I’m happy to collaborate to help the government so they can reduce their costs, but don’t let them tell me that my costs will be reduced, since they will not”. Large-scale standardised tax filing can be used to accomplish large efficiency gains for the Dutch tax administration. However, the tax administration also claimed that its investments are higher than its gains. It argued that it switched to digital tax filing for businesses already in 2005, based on a different data standard. Simply switching to another standard (XBRL) will not result in a large efficiency gain. As such the whole business case that was made for both companies and the government was challenged and no revised business case was made.

5.6 Unexpected resistance because of unanticipated impacts

A related pattern is the changing perceptions of the impact of the project. At the beginning this impact seemed to be limited for many organisations. They expected that the information exchange would be automated, which would result in lower costs. It might have been framed in that way, as suggested before. In some cases, the interrelations of factors that we now can see in hindsight were simply unknown at the moment of decision-making. Public organisations were not expecting that this would result in pressure to collaborate more closely with others and even adapt their processes. Accountants and financial intermediaries were not expecting that their existing business models would be violated and their profit margins would vaporise. Their business models are largely based on entering and checking their clients’ information and creating accounting reports, which would become an automated task if XBRL were introduced for information sharing and knowledge rules were used for checks, controls and the creation of reports. The companies saw that their revenue model would need to change and that fundamental changes in their value-adding roles and processes would be necessary. Like in other industries, for example tourism, the role of intermediaries will necessarily change due to the ability to directly connect using lower transaction costs. Traditional roles will vanish due to increased direct contact and new roles will take their place.

This stakeholder group is quite diverse, as there are a few large international accountancies and many smaller companies operating locally. They are affected heavily, as they can be easily bypassed by automating the process. Furthermore, their traditional revenue model is challenged, and as they are afraid that the landscape might diminish their revenue model, they have no sense of urgency to collaborate. One interviewee commented, “the project was not able to communicate the vision … it remained vague”. On the other hand, using XBRL can make the work of accountants more efficient, as they would need to carry out fewer tasks and create fewer reports. There are some smaller and innovative intermediaries that see this as a source of competitive advantage and are interested in adoption.

This problem is further complicated by the fact that this has often not been part of the rationality in which the project has been communicated. Instead of clarifying the problem and starting the discussion about the impact on the organisations, the necessary changes and the new possible roles, the changing business model of financial intermediaries has not been addressed. It was only discovered more recently that violation of core values was a root cause of the resistance.

6 Managing the unmanageable? Some principles

The initiation of the project was based on a bird’s eye view of a desired situation, which proved to be more complicated when getting down to the details. Throughout the project decisions were not able to be made based on a sound business case. Despite the many changes the business case was not updated and could not be used as a basis for the guiding decisions. A logical consequence of the project dynamics was dealing with them in an ad hoc way and focusing on managing incidents. This resulted in non-linear behaviour in which the complexity grew. Eventually, the focus on the initial objective and providing user value was lost. Scope creep, changing requirements, negative news, incidents, blurred vision, a changing impact and other factors had had a devastating effect on the entire project. Users who initially had held high expectations became disappointed.

The analyses of the case study shows that a large number of factors contributed to the project dynamics. It is difficult to pinpoint what pattern contributed most to project failure. These patterns are often interrelated and reinforce each other. As one interviewee summarised, “it is the interplay between events that resulted in our decision to postpone adoption”. The analysis over time also showed that a number of problems could be tackled by following relatively simple principles. The confirms the idea behind CAS, which suggests that by guiding the behaviour of individual agents by simple rules the overall systems behaviour will be changed (Janssen and Kuk 2006; Johnson 2010). Those principles may be used by managers and other individual agents. The individual then can continually adapt to changes in their environment, but obey the principles which will be presented hereafter. The principles guide the actions of individual agents when dealing with the project dynamics and by directing the individual behaviour the whole system should move towards success instead of failure.

The management principles can be used to self-organise in complex projects like CAS to realise certain benefits. However, we are not talking about a flock of birds. The idea of simple management principles for transformation projects may neglect the responsiveness of actors involved in the transformation project. Actors have certain interests and – unlike birds – may anticipate or react individually to interventions from outside in a rather unpredictable manner. Responses from individual actors might change the game considerably. Managers will have to be aware of this, which makes the management of complex adaptive systems dynamic in itself. All principles are applicable to transformation projects but can also have adverse effects if applied blindly. Sometimes even a counter principle might be more effective at a certain moment. That’s why in our descriptions below we close each simple principle with a counterargument and ultimately present management as a conscious balancing act between simple but sometimes contradicting principles.

6.1 Principle 1: Manage growth

If a project is set up in a piecemeal manner and allowed to develop organically, it can result in scope creep and the introduction of additional complexities. For example, the addition of banks was used to stimulate adoption but finally resulted in additional complexity, conflicting requirements and further delay. Organic growth was at the heart of the project failure, resulting in stakeholders pursuing other directions and creating an ending date that goes beyond the time horizon. Furthermore, it contributed to uncertainty about the outcomes and resulted in scope creep, which could not be allowed to continue. The addition of new stakeholders such as banks and the introduction of new technology and applications resulted in further delay and blocked process. Instead of implementing and realising what should be done, piecemeal and organic growth complicated implementation. In essence, problems were tackled by adding new elements to solve it. Although this may have solved the actual problem, it also resulted in additional complexities that needed to be managed and also introduced new risks. The way these risks were handled was the same way as in which they had been created, namely by adding new elements, which again adds to the complexities. In principle this scenario can continue until it reaches the level that it cannot be managed anymore. Piecemeal and organic growth is fine within a short time frame, but can destroy a project within a larger time frame.

The quests for ensuring participation resulted in the involvement of a large number of stakeholders, such as banks, large organisations, SMEs, accountants software vendors and so on. These stakeholders were not uniform, and consequently more and more different stakeholders were involved. This resulted in trying to develop a system that would satisfy a large and varying need base, resulting in a level of complexity that could not be handled anymore. Managed growth means involving a user base that is small enough to handle and representative enough to ensure scalability to a broader user base.

Of course, the question ‘what is small enough?’ is hard to answer. The quest for support resulted in an open development process, in which several interested actors participated. This support is inevitable if the results of the process are still uncertain. The open process may ensure trust and commitment, which will be necessary if negative surprises occur. The price of this openness is an unmanageable variety of actors involved. A competing principle is closure, which may ensure the progress of development but may add to resistance from those not involved (De Bruijn et al. 2010).

6.2 Principle 2: Create robustness and slack

Policymakers have high expectations and deterministic views on the case study project. Yet there have been many incidents and unexpected events. Black swans appeared, which are high-impact events that are rare and unpredictable but in retrospect seem not so improbable (Taleb 2007). Many highly consequential events in history come from unexpected situations which are explainable in hindsight. Taleb argues that robustness should be created. In a similar vein the project should be robust. In this project there were continuous changes, resulting in uncertainties about outcomes and a focus on dealing with incidents. The manner in which these changes were dealt with was not anticipated at the beginning. However, in later phases robustness was created by making additional funding available for unforeseen circumstances, focusing the planning on certain stakeholders groups instead of viewing them as a heterogeneous population, and involving experts in the planning to think about possible events that might happen. The latter can be taken into account in the planning and budgeting, or measures might be developed at an early stage, even if they might not come true. Foreseeable changes can be viewed by performing a few ‘back of the envelope’ calculations (Fairley and Willshire 2003). For example, the effect of information sharing and intermediation is well-researched, and simulation models could be developed to investigate possible impacts prior to implementation (see for example Fu-Ren et al. 2002).

However, robustness and slack are expensive. Projects that appear ‘mean and lean’ tend to be more attractive for politicians and businesses to invest in. That’s why it is attractive and might even be inevitable to frame large transformation projects as being leaner than they actually are. The challenge here is to present the project as being ‘lean and mean’ while at the same time respecting the complexities by creating robustness – in other words, to match the ‘front stage’ story with the muddling-through processes that is often the reality back stage.

6.3 Principle 3: Offer prospects

Large projects are likely to fail due to their multiple complexities, uncertainties and high numbers of stakeholders involved. Yet a small-scale approach is often not feasible, as there are too many issues that need to be addressed simultaneously. Therefore a key concern is operating within a stable situation in which the number of changes are manageable and the user perspective is given dedicated attention.

For user adoption a reliable and working system should be available, as a number of organisational changes are necessary and stakeholders have to agree on the necessity of this change. Furthermore, continuity should be guaranteed. If users expect a short project lifetime, they will not be prepared to make any decisions favouring the adoption. When the project should be adopted is dependent on the uncertainties of the users. Some early adopters were disappointed by the limited progress and the many changes during the project. The many changes made it difficult for them to prepare. In addition, due to changes, the initial investment in adopting their systems to submit XBRL-based reporting did not pay off and they had to make an investment once again. One uncertainty was caused by the lack of prospects after the project’s completion. The project is supposed to facilitate the handing over of the resulting software to the control and maintenance department and ensure that a governance structure is in place which will guarantee long-term stability and solid prospects.

This way governance and maintenance aspects should be involved early in the project and can be part of the business case. This ensures long-term commitment to the changes that are hard to undo. This moves the ‘point of no return’ forward. Involving the business case in this is, however, a bit of a ‘leap of faith’ if the exact outcome of the project is still unsure. This move implies considerable political risks, because if the business case proves to be less-than-desirable, severe damage to the project is likely. A competing principle is trying to leave room for a ‘point of return’ regarding the decision-making process. The direction of the project is formulated on an abstract level, but enough of a prospect of gain to all involved is ensured. Commitments can be attained, for example, by insisting that core values – such as the existence of the intermediaries – are respected (De Bruijn et al. 2010). This does not make the course of the project clearer, but it prevents sudden strikes of resistance driven by new knowledge about consequences.

6.4 Principle 4: Separate innovation from implementation

The sluggishness between phases causes problems, as innovation keeps on going when implementing the systems. By doing so the implementation process has to change under the pressure of new innovations and becomes unmanageable. No proven technology was used in the implementation process, and innovation resulted in scope creep and a change of the business case. The idea was not stable and kept changing. Innovation should be separated from the development aspects. Innovation should also be halted at a certain point and not interfere in the actual implementation. Implementation is already complex on its own, and interference from innovation makes it even more complicated. The innovation should deliver a software architecture and standards that are technically feasible and can be developed with the current technologies. This helps to make a business case that is realistic and not subject to too many changes. Innovating first also enables the project managers to plan for control and maintenance and give a more realistic time frame to the implementation. Innovation should allow for failure and the pursuit of various directions, in order to give the flexibility needed to steer toward what is feasible and desired. Implementation is focused on creating a working project within a relatively short time frame. If there are major changes, new innovations and implementation projects can be created.

In a way this principle involves freezing the innovation process to make the project more manageable. A drawback of this approach is that opportunities provided by innovation are missed. That’s why at certain moments it can be wise to unfreeze it a bit, i.e., to leave the door a bit open for new ideas. Of course the gatekeeper function is essential here to safeguard manageability. The concepts of ‘freezing’ and ‘unfreezing’ are often used in organisational change for the same motive, namely to ensure the manageability of dynamic processes (based on K. Lewin 1947).

6.5 Principle 5: Provide unity of command

Full control and co-ordination of large-scale projects is virtually impossible, as this is affected by many stakeholders. The project organisation in the case study was subject to several changes. Parts of the project control, co-ordination and development were outsourced, leaving little means to steer. Multiple sourcing parties are involved, as the management and software developments are separated and the project team is made up of individuals from various external organisations. Some public servants were added to the project team to ensure the specification of requirements and to gain the necessary input. The project organisation is solely responsible for meeting the deadline, and interactions with the principals is limited to a monthly meeting with high-level representatives. Governance is often based on high-level agreements (meeting deadlines and staying within budget), and there is limited opportunity to know what is really going on and what the crucial decisions are that should be taken. In several cases the board was involved in crucial decision-making, but sometimes this was at too late a stage to maintain stakeholder commitment or to meet time and budget constraints. If the board was involved in the decision-making there were no feedback mechanisms to understand and evaluate the impact of the decisions. Bluntly stated, the governance from the business side missed early warning indicators and other small signals. Hence they were not able to take relevant actions.

This governance issue actually implies the classic dilemma between centralisation and decentralisation. While centralisation makes a project much more predictable, the centralised manager will have a hard time keeping everything together. The information pipeline to the centralised managers will become blocked, and he or she may not manage to keep control over the entire project. A decentralised approach better respects the knowledge of the various actors in both management and operation, but decentralised projects may quickly become unstructured and unmanageable.

6.6 Principle 6: Create incentives

Business that are obliged to report their financial situation to the government are the actual end-users who need to provide their information to the government to comply with the law. These business constitute organisations covering all kind of industries and sectors and having different sizes. Small and Medium Enterprises (SMEs) are often not aware of XBRL and are not interested, as they are primarily users of software. They rely on their accountants and do not have the time, money or knowledge about how the information is transferred to the government. Large organisations often have different reporting obligations and are aware of the need to adopt. They have the capability and expertise and often see a number of advantages. In order to take advantage of this development they have to adopt their systems and processes. As such, both type of users have different incentives to adopt. Whereas large organisations can gain considerable advantages and are prepared to adopt, most SMEs can gain only limited advantages and rely on their software providers and accountants.

The software companies developing (financial) software for businesses and intermediaries supporting XBRL data have to invest in the technology and integrate it in their software to ensure easy adoption by businesses. As all software vendors can do this, they hardly see it as a means for gaining competitive advantage and therefore have limited incentive to adopt. They are interested in minimising their adoption costs.

Several interviewees indicated that they would be reluctant to adopt new technology without a clear obligation determined by law. In the case study it was chosen to develop a gateway and other facilities first. Only after the infrastructure was in place was it decided to make a change in the law, which stated that in 2013 the use of XBRL would be obliged. This approach resulted in a project delay, as the development and legal change were done sequentially and only afterwards was a sense of urgency created. The lack of legal change resulted in uncertainty as to whether or not XBRL would be adopted. This in turn resulted in a wait-and-see attitude among many stakeholders.

So a principle as simple as creating incentives can be hard to implement. It seems difficult to determine what incentives seem to be in place beforehand. An alternative approach is to develop incentives while the project is running, in co-operation with those involved. The drawback of this alternative is naturally that the project is not attractive at its inception to those actors whose co-operation is vital.

6.7 Principle 7: Acquire the necessary capabilities

The parties in the case study had limited knowledge of the overall project, and therefore the impact and consequences of many decisions could not be foreseen. Several of Nelson’s (2007) classic project management mistakes seem to have been made. There must be a broadening and deepening of the government’s expertise and professionalism in terms of the project management in order to support business process transformation and change.

The government had defined the problem from a macro perspective, and essential details and issues were initially not taken into account. In government projects a high level of involvement and participation of stakeholders is a common approach. This case has had a high level of participation of organisations defending their own stakes and hardly any involvement of the users for whom the benefit of the reduction of the administrative burden is intended. There has been limited knowledge about the users and their processes and systems, and consequently their needs have not been focused on. An understanding of the users’ needs and organisations was missing.

The ability to deal with publicity is also necessary. These large-scale projects are subject to scrutiny and a certain degree of public accountability. Critics are often in the open, publishing in journals, magazines and newspapers. The press knows that bad news sells. It is read widely, and hence the criticisms are well-known to all stakeholders and influence the adoption by users. Each of the criticisers has a vested interest in his or her commentary and critique and promotes his or her own view on the project and opinions about what should be done. This problem is further complicated by the fact that critique is often one-sided and nuanced. Instead of clarifying the problem, criticism manifests in resistance and other motivations, and a detailed analysis of the underlying causes of the issue is only made afterwards. Publicity should therefore be monitored and dealt with as much as possible, and it should be avoided that publicity leads to a constant need for incident management.

The lack of capabilities is worsened by the turnover of key personnel. Staff turnover in projects is statistically associated with reduced scope, increased costs and schedule delays (Sauer and Willcocks 2007). Yet the turnover of some key personnel is always to be expected, and as such it would be advisable to have redundant capabilities.

Of course expertise and capabilities for large and innovative transformation project are scarce. One cannot expect public organisations to have these capabilities beforehand. An alternative to hiring expertise is contracting it to an agent, for example an external project bureau. Initially, this is much cheaper. However, severe accountability issues between the principal and the agent may emerge due to the lack of substantial interplay between the ministry and the bureau (i.e. Jensen and Meckling 1976).

6.8 Mindfulness in the use of management principles

Responses from individual actors determine the overall system behaviour. All principles can be used by the individuals but can also have adverse effects if applied blindly. Managing large transformation projects is subject to dilemmas. Simple management principles seem to be applicable but are subject to competing strategies. We have illustrated this idea in our seven management principles, as summarised in Table 2 below.

Table 2 Management principles, strategies and counter strategies
Full size table

How can strategies and counterstrategies best be matched? Weick and Sutcliffe (2001) provide the concept of ‘mindfulness’, this being the ongoing scrutiny and adaptation of the way in which organisations and managers work (see also Koppenjan, Veeneman, Van der Voort, Ten Heuvelhof, and Leijten 2011). Weick and Sutcliffe apply their concept to organisation in which reliability is the dominant concern. However, they emphasise the same dynamic of contradicting principles being applicable at the same time. The dynamic idea of mindfulness helps to move away from static dichotomies like ‘centralisation’ and ‘decentralisation’. It suggests that the project management itself, just like CASs, is dynamic. Project management is part of the CAS, and the project and the project management adapt to each other. The response of actors to a certain management strategy might be different than anticipated and might result in undesired effects. This ongoing scrutiny and adaptation would then imply an ongoing awareness of the promises and pitfalls of a management strategy and the need to mitigate it.

The dynamics of managing transformation projects requires finding creative combinations of the management strategies. If one management strategy is dominant, its counterstrategy may be helpful as a supplement to mitigate the drawback of the dominant strategy. It may compensate for the weaknesses of the prevailing approach. This can be done at every level of the project. We suggest that these combinations result from conscious attempts of actors involved in the project, being aware of the drawbacks of prevailing management approaches. Organising ‘mindfulness’ secures intelligence on the drawbacks of single management strategies and provides them ample discretionary freedoms to use a counterstrategy for compensation. The development of these counter arrangements – as a result of ‘mindfulness’ – may happen at any level of the project, and goes on during the whole process of the project realisation.

7 Conclusions and suggestions for further research

Large transformation projects have a large chance of failure, because of dynamics that make it difficult to manage such a project. Project failure has been extensively studied in ICT projects. In our research we adopted a Complex Adaptive Systems (CAS) lens to look at the project dynamics of our case study. A multitude of factors resulted in the dynamics and were associated with project failures. Six patterns characterising the project dynamics were identified, including 1) piecemeal and organic growth, 2) scope creep: changing ambition levels, 3) continual changes, 4) stalemates through catch-22 s, 5) changing business case, and 6) unexpected resistance because of unanticipated impacts. These factors contribute to complex dynamics in all such large transformation projects, resulting in uncertainty about the outcomes, further scope creep, negative publicity, the need for incident management, blurred vision and a change of impact. They have a devastating effect on progress and the adoption by users throughout the entire project. Due to the non-linear behaviour factors might reinforce each other and they are often interrelated.

The analysis of the case study over time also showed that a number of these factors were tackled by following certain relatively simple principles. The emergence of adaptive behaviour resulting in project failure can only be influenced indirectly by altering the behaviour of the individual agents or by altering their relationships in a network. As such CAS theory suggests that complex systems can be guided with relatively simple principles guiding the behaviour of individual agents. Responses from individual actors might change the situation considerably. In the a successful project the individual continually adapt to changes in their environment, but obey the seven principles: 1) manage growth, 2) create robustness and slack, 3) offer prospects, 4) separate innovation from implementation, 5) provide unity of command, 6) create incentives to adopt, and 7) acquire the necessary capabilities. Each principle is guided by management strategies and their counter-strategies to emphasise the possible negative consequences of the strategy and create awareness of possible counter-intervention. The interventions are part of the CAS and result in the undesired behaviour of actors. Unlike in traditional CAS in which the principles are followed, the behaviour of the self-interested actors in reaction to the dynamics might be unpredictable. As such there is no single way to deal with the project dynamics, and management strategies are dependent on the situation at hand and the possible reactions of actors.

IS projects remain problematic despite the fact that many of the issues are by now quite well known. Project failure literature is often based on a categorization of failure, but does not seek to articulate more comprehensive conceptualizations of how the projects unfolds and results into failure. The complexity, multilevel nature, non-linear and emergent behaviour makes it difficult to conceptualize and often a simplistic view is taken on project failure. By taking the CAS view we moved way from taking a reductionist view. The CAS lens provides a deeper analyses of the project dynamics in which individual behaviour influence project success. Emergence is captured by analysing the patterns arising out of a multiplicity of interactions among the interacting agents which resulted in failure. In projects individuals continually adapt to changes in their environment, and non-linear effects can be created. Behaviour patterns might reinforce each other resulting in failure. By obeying the principles presented in this paper the individual behaviour of actors resulting in self-organizing in complex projects and direct the project into success. We suggest to use a CAS lens to conceptualize these kind of processes to understand how non-linear behaviour results in success or failure. A CAS lens allows analysing emergent phenomena without abstracting away interdependencies and interactions. In this way the understanding of how individual agents influence system level will become clearer and interventions can be developed to deal with it as was done in this research.