vol. 15 no. 3, September, 2010
vol. 15 no. 3, September, 2010 | ||||
Most major organizations have performed or are in the process of performing a transformation from a Web environment built on HTML to that of XML. The most advanced way of proceeding is to implement portal server technology (hereafter: portal technology). This enables a platform for a series of sophisticated applications not possible with the old structure. It is reasonable to assume that the introduction of portal technology will initiate a series of organizational shifts (e.g., Gulliksen et al. 2003). It is therefore important for members of the organization to be fully briefed about the purpose of the new technology as well as expected complications following implementation (e.g., Ravichandran 2005 ; Gulliksen et al. 2003 ). However, the specific impact may be difficult to anticipate beforehand since this technology carries a wealth of possible applications and accompanying difficulties in implementing these. As previous research has shown, implementing complex information systems to an organization is cumbersome process, involving many actors and often failing in one way or another, causing large costs in money, time and effort for both an individual user and the organization as whole (e.g., Venkatesh and Bala 2008).
We identify multifunctionality as a crucial dimension of a portal technology. It is characterised by a high degree of flexibility and extensive potential. Ideally, it is implemented to a well structured Web environment based on XML. The outcome would then be more predictable than when it is to replace a poorly organized HTML-based structure. In the latter case, more relevant to most real life settings, the multifunctionality becomes not only an asset, but also a complication. It is easier to communicate, negotiate, allocate resources and implement a simple technological artefact. Even though, any reasonably complex technological implementation carries with it a number of "unknowns", we argue that some cases, such as the one we studied, adds an additional dimension: we lack knowledge on how complex it is. This statement is valid also for the specialists set to implement the technology. For portal technology to function, it must be transferred from an idealised research and development context into complex localised settings that already host a messy Web environment together with a number of individual and/or in-house developed information systems for specific purposes. As a result, not even the specialists of different features of portal technology can precisely predict the kind of challenges that will appear nor the extent of work required to deal with these.
Great expectations can be invested in this kind of platform. For ordinary users expectations related to perceived ease of use and especially to perceived usefulness are most compelling and related to both individual and social aspects of understanding the new technology (e.g., Venkatesh and Bala 2008; Venkatesh and Goyal forthcoming). However, the existing Web environment and the organizational needs and resources will always constrain what is possible or prioritized to implement. Furthermore, the specific complications and constraints in implementing cannot, we argue, be known beforehand. Therefore, the issue of what functionality will become available to the organization is more difficult to be agreed on than in projects with more clear-cut functionality. Given enough technological and institutional complexity, the involved professionals might find fundamental difficulties in communicating about the matching of available resources and needs both before and during implementation.
More specifically, based on our case study, we will argue that the traditional goal oriented model of technological implementation (i.e., goals, resources and incentives are initially stipulated by contract) is ill suited for the complexities of moving from HTML to XML with portal technology. By necessity, the process needs to be adaptive as the fundamental goals of implementation continuously need to be renegotiated. We will be analysing a particular case in which a very messy transmuting process was fitted into a goal oriented model with certain adaptive feedback loops. We actually see this as a rather sophisticated attempt at handling the complexity of the process. Still, the project failed regarding many objectives, some in technical level, and some in social. Our basic research question is: what were the main complications involved that caused a sophisticated and competent project organization to fail in implementation?
This article is one in a series that, based on a longitudinal qualitative interview study, investigate the complexities of one particular implementation of portal technology. It is a case where the degree of deviation from expectations is beyond the zone of tolerance (Brown, et al. forthcoming). In this paper, we are concerned with the interaction between the project group that worked with implementation and the internal steering group that served to settle goals and working principles for the project. As it was recognised that implementation was complex, the steering group were to intervene when the project needed to be steered in a new direction. Furthermore, the steering group made decisions of an overreaching character and followed the economical situation.
Multifunctional Web-based digital tools are complex and expert driven. It can be difficult to attain an overview on what happens when certain features and functionalities are connected to each other within the context of specific organizational needs. A number of features turn out to be unnecessary; others are in conflict with well established routines and professional standards. Some features will take too much time or are too expensive to maintain for the organization. During a lengthy implementation process, priorities and economical frameworks are likely to shift in varying degree.
An important dimension of such type of complexity is that the different actors find it problematic to engage in a generic way of talking about portal technology. The difficulty in communication between different actors in relation to system development is an old, known problem (e.g., Juristo, Moreno and Sanchez-Segura 2007; Gulliksen and Lantz 2003; Chen et al. 1987). Already in the middle of the 1960s, the importance of communication between developers and users was acknowledged (Attewell 1992). In the middle of the 1980s, researchers focused on the complexity of the dialogue between different organizational levels (as they needed to be addressed simultaneously) as well as flawed communication due to different perspectives of users and developers on key areas (Chen et al. 1987). Despite these efforts, the complexity of communication has remained as one of the main troubles in information technology development projects.
In this article, we are concerned with the way the people with the technical expertise and those with the organizational experience talk to each other about:
The integration of a new and complex multifunctional technology with a messy, older technology within an organization with vaguely articulated needs, is a huge and difficult task. As pointed out by for example Gulliksen et al. (2003), such projects tend to alter as they progress, causing changes in priorities and perspectives. Our case is one of these unusual projects where it has been difficult to stipulate fixed resources, procedures and goals. Instead, at least in our case, more resources were repeatedly demanded and given, deadlines were constantly revised and goals concerning sophisticated applications were not met in time for the launching of the platform.
After a brief methodological reflection, we will present the basic components of portal server technology. Thereafter, we discuss how the well-known notion of "language games", first suggested by Wittgenstein (1953) can be relevant for understanding the problems of talking about portal technology. In applying the ideas of Wittgenstein to this area of research, we identify several of the difficulties in talking about both the project and the technology. We will then discuss the specific concepts and challenges involved in talking about the implementation and functionality based on the empirical material. We will show that it is possible to view the discussions on the project as involved in interlinked language games. We maintain that it is the complexity of these language games that constitutes the major difficulty in obtaining successful implementation. We will focus on the perspectives of the project leader working with the implementation and that of the steering group, and provide as a wider context some examples of how the ”ordinary users” perceive the development. We will close this article by arguing for the necessity of linking introduction of portal technology with a well-designed collaboration strategy in order to minimize the triggering of various implementation effects. various various implementation effects.
This article is based on a longitudinal case study in which the same informants are revisited at different times. Altogether fifteen persons were interviewed before implementation, six months after and are planned to be interviewed again eighteen months after. In the selection of respondents, we aimed for a mixture between three different groups: system developers and technical users, organizational leaders and ordinary users. In a few cases, a respondent had left the organization as we moved into the next round of interviews. In those cases, we introduced a new respondent as a new representative of the relevant group. We have anonymized the organization and therefore also some of the material that is closely related to the case. We have concerned ourselves with perspectives rather than individuals. As a consequence, our treatment of interview material is based on perspective, what group different statements belong to. In this article, we will focus on interviews with system developers/technical users (names starting with D) and members of the steering group (names starting with S) as well as used some expressions from ordinary, end users (names starting with E). All interviews have been treated confidentialy and we have strived to make all statements or quotations difficult to attach to the individual respondent.
Because of the growing complexity of Web-based services, large organizations often need to integrate various types of contents, applications and services into a single platform. Portal technologies are therefore multifunctional technologies constructed to create an integrated environment for various types of data and resources in order to create customization, content aggregation, content syndication, multi-device support, single sign-on services, portal administration and portal user management (Wege 2002).
The portal is built for flexibility and is therefore an exceptionally neutral and bland product without the various portlets that supply functionality. Each portlet reside in a portlet container and serves as an interface between the portal and other internal and external Web resources. The portlet can, for instance, access an external as well as an internal financial service. Portals can also publish remote portlets as Web services that allow easy access and integration.
The portal server technology that was implemented in the organization we studied was IBM WebSphere. IBM is together with Microsoft considered to be leaders in development of portal server technology. In the development of this kind of technology, big is beautiful. IBM freqently publishes remote portlets as generic services to the customer portals.
There is a kind of paradox involved in the work of revising old systems that also applies for portal technology: it is blamed for doing good. The main idea may be to create a tool for structuring Web-based resources. The formals benefit would be to avoid future Web development becoming marred by various types of incompatibilities and a lack of basic structure. However, as it is implemented, it will be forced to confront and deal with all the incompatibilities and messiness of the old structure. Observers might therefore interpret it as introducing problems, while it is actually waking the sleeping dogs and troubleshooting.
However, in another sense, portal technology actually does introduce problems into the receiving organization. New ideas of structuring and utilising information are introduced and these build on specialised knowledge traditions that will be difficult for the layman to grasp. Furthermore, portal technology is so rich in potential that members of a receiving organization will have a difficult time finding out what specific knowledge traditions are worth reading up on.
Even the most basic of all ideas, the move from HTML to XML, can be interpreted in a wide variety of ways. We will presently develop this argument, but first we must introduce Wittgenstein's idea of language games.
A dominant theme in Wittgenstein's book Philosophical Investigations, is the idea that concepts are bound to particular practices (Wittgenstein 1953). The concept of language games is an analytical device introduced in order to characterize concepts as meanings that blend into other concepts that have a family resemblance in a specific practice. In other words, individual concepts do not have a general meaning regardless of practice. Instead, they are bound to specific practices where they play distinct roles that are relative to other concepts with a family resemblance in that context.
The contextual processing of concepts has been systematically refined in academic disciplines. Phillips (1977) and Gergen (1982) have both suggested that the paradigm concept of Kuhn (1970) builds on similar ideas as that of language games. Kuhn developed the concept of incommensurability, suggesting that there is no neutral point at which the language of different research disciplines can meet. Astley and Zammuto (1992) explicitly sees the assignment of meaning in research as rooted in specialized forms of discourse (language games) in their analysis of the research field Organization Science. Similarly, Collins (1981) argues that researchers strive to achieve clarity through well sharpened concepts. Despite this, any attempt at exactly pinpointing the meaning of the concept is done through increased wordiness. This, in turn, leads to a kind of regress as complex concepts are defined by other terms that are in need of precision. Collins introduced the concept of " interpretative flexibility" in order to describe the openness and ambiguity of research based concepts. Only members of a strictly specialized research community are able to understand the language games of specialized science.
It is easy to draw parallels between the practice of research and other domains of knowledge that build on a specialized tradition. In other words, we suggest that the production of multifunctional information technology, such as portal technology, is steeped in traditions that have developed over a long period of time. Concepts will not be readily understandable by outsiders, since they reflect complex ideas that receive their meaning in their relation to other concepts with a family resemblance within those specific traditions.
As specialized technology is transferred from a context of research and development into practical implementation, a series of ideas and concepts are brought along. It is the argument of this article that successful implementation requires not only achieving the desired functionality of the technology, but also that the accompanying ideas and concepts are popularized systematically into the new organization. If only "the hardware" is transferred, there is an obvious risk that the members of the receiving organization that are supposed to guide the implementation, are not allowed the necessary tools to understand the turns in the course of action.
The implementation of multifunctional portal technology adds an additional layer of complexity. There is a wide range of possible features and each of them is involved in a series of different language games. Furthermore, since it is not possible to predict ahead of time what features will become materialized, information strategies directed toward the members of the organization run the risk of emphasizing the wrong language games.
Our case study analyses the transformation of a traditional organizational Web environment, built with HTML, to portal technology. In order to understand the meaning of a portal, the user is required to take in a number of related, but equally complex, concepts, such as XML, platform, portlet, servlet, Java, JSP, etc. In addition, some of these concepts are still vague in their application. The number of concepts used, in combination with their complex relationship to neighboring terms, creates fundamental challenges in communication as the project proceeds.
Let us examplify with the specific language games surrounding the markup language XML (Extensible Markup Language). This connects to the most fundamental task of the project, a move from HTML to XML. But what does that mean? Members of the receiving organization working closely or at distance from the process will receive this basic information. It is taken for granted that this is something that everyone understands. While many may have a working knowledge of what HTML stands for, understanding XML is more difficult.
XML actually signifies a number of diverse meanings, all of them bound into complex and specialised language games. In addition, the portal technology can be the foundation for a series of different applications which, in turn, rely on specialised usages of XML. As the ranges of possible applications are unknown, it becomes difficult for members of the organization to understand what features of XML that are relevant to understand. We will below discuss some of the possible language games involved.
On the one hand, it can be seen as a markup language, on the other, it can just as easily be taken to be a standard for developing markup languages (such as XHTML). Quite often, the concept "XML" is extended to include specifications that use XML as a standard. Therefore, when two specialists discuss "XML" they might actually refer to XML together with the whole family of related specifications such as XSLT, XPath, XML Base, XML Signature - to name but a few. However, it is also possible that they might refer to a broader range of XML related technologies that may or may not be based on XML such as WAP, RSS, SOAP, SVG etc. Finally, it may very well be the case that the specialists were referring to the discrete domain of XML work that they were devoted to, perhaps XML JavaScript or XML Basic.
Already, we can see that the simple statement move from HTML to XML can be interpreted in several ways. Still, all these interpretations build on an object-oriented programming tradition. However, XML is also the product of humanistic tradition of discussing publication, books, texts, document layout, typographic structures, reading and language. This is an ancient tradition which has merged with the object-oriented programming tradition as printing became digitalised.
In order to understand XML and its function, we need to be aware of how it was created as response to problems with the earlier standard of Standardized General Markup Language (SGML) and HTML. The latter was created as a simple markup language that treated information as documents. As it was so easy to learn, the practice of creating Web pages spread widely in the early 1990s. However, the simplicity increasingly became a problem as the need for a number of sophisticated functions increased. XML was created to treat information as separate data, allowing flexible use of merked up data that was not possible with the earlier standards.
XML is built on the flexible content-based strategy (Renear 1997) of producing digital documents. This strategy leads to considerably increased flexibility compared to the earlier standards. Simultaneously, XML is structured according to a hierarchical principle often described as Ordered Hierarchy of Content Objects (OHCO) that serves to constrict flexibility. In addition, the hierarchical principle is quite often difficult to implement in practice as various concepts tend to appear in different documents with different meanings. This adds on the phenomenon of which has often been described as the problem of overlapping hierarchies (Barnard et al. 1988). Thus now flexibility is not only a strength, but also a problem.
There are more contradictions to be found in XML. Goldman et al. (2000) noted that the functionality of XML would require it to be defined as a data model, instead of traditional view of it as a textual language. So far we have focused on XML as a tool for organizing textual data. However, the creation of XML can also be seen in the context of the larger project of maintaining a coherent World Wide Web (Robie et al. 2001). As such, it can be conceptualised as the glue that holds together a series of key technologies and make communication between them possible. As a result, XML is used as a foundation for a number of different applications, such as portal technology.
Sometimes the integration of XML with other technologies is actually a way to resolve some of the fundamental problems that have been discussed above. For instance, XML is more often than not integrated with Resource Description Framework (RDF). This can be seen as a strategy for bypassing the problem with overlapping hierarchies as RDF serves to supply global identities that are unique for each hierarchy. RDF can be perceived as a tool for Web-based XML applications. At the same time, RDF could be interpreted as a part of the XML family as it actually is an XML-based language. However, as it also is a data model, it constitutes at the same time a break with some of the ideas underpinning XML.
A key feature of XML as an instrument for facilitating digital publication, is the idea of "one input many outputs", which signifies the possibility of utilizing the same information in different hierarchies (Hillesund 2002).
In this section, we have been unpacking some of the language games (specialized discussions and ambiguities) connected to one of the many technologies (XML) associated with the portal technology. Once again, this is just one example of many. The way that people in this project talk about XML is linked to the available features of the multifunctional portal technology. Many representatives of the organization will discuss features and priorities of features in a way that presupposes an understanding of a certain interpretation of XML. When such insights are lacking, discussions tend to be vague. We have earlier argued that in the case we studied, it turned difficult to predict when desired functions would be implemented. This is an issue we will address in the next section.
As has been argued earlier, portal technology is complex multifunctional information technology. It can be seen as a platform on which a wide range of different functions can be developed and it can therefore be described and implemented for the members of the organization in many different ways.
Based on the (anonymized) documentation produced in connection with the project as well as our interviews with organization and IT leadership, we found that the major motive behind the procurement of the portal technology was that the current Web environment was hopelessly fragmented. A series of functions had been built on each other at different times without any strategic idea for the whole system. Lines of responsibility were also vague and not distributed in any logical fashion. There were a number of different resources for which IT management could not identify usage and purpose. In some cases, they did not even know who were responsible and if it was possible to remove the resource. There were also practical problems in that different Web pages could supply similar information, but include variations concerning details such as opening hours. In addition, the traditional HTML structure was seen as too limited as content and layout elements were integrated. This made attempts at consistent layout restructuring the major obstacle.
The major goal was to establish a platform that used XML to separate information from layout and was built more on a database principle (one input, many outputs). One concern was that the available Web resources should have flexible layouts so that a Web page could be read with various technologies, such as a mobile phone.
A major organizational shift was anticipated in that the Web editors (i.e. technical users) within the organization would work more with structure and less with content. The new platform should enable sophisticated vehicles for user generated content. The vision for the new technology built on seeing everybody as users (no more visitors).
In acquiring technology for a new Web environment, it was eventually decided to make a major acquisition of advanced portal technology. It was expected that this would create a sustainable platform that could handle the technological demands and changes several years forward.
To the ordinary users of the organization, the fundamental flaws of the Web environment were not easily observable, or they were inherently used to them. In the information packages that were to follow, the users were only slightly briefed on the fundamental motive for system change. Instead, they were given idealized images of being able to work with the most advanced Web tools currently available. Only little information was given on any potential implementation problems. The bridging between the old and the new system was expected to require an effort, but be unproblematic. However, the actual launching of the portal technology was repeatedly delayed. The developers therefore came under increasing pressure to finalize the implementation. At the launching, none of the sophisticated new technologies, that the users expected, had been implemented. In fact, the users were presented a relatively large sample of new Web pages oriented mainly towards external users. However, a lot of information, earlier available, was completely missing due to delays in migration process.
The sophisticated function of portal technology that was easiest to explain and to generate enthusiasm toward was the potential of creating a so-called "adaptive Website", even though this concept was not used in information packages. Perkowitz and Etzioni (2000) characterize adaptive Websites as sites that automatically improve on organization and presentation by learning from individual visitor Web usage. The standard example of a successful adaptive Website is Amazon.com.
A second selling point was the envisioned new publishing system in which Web editors would be less active in producing texts, but rather create spaces for user-generated content. A third highlighted feature was the possibility to create group-based working spaces build on the Lotus application Quickr. Thus,both technical and “ordinary” users were treated as customers of a complete product, instead of persons whose effort and knowledge was necessary to create a functional, new Web environment together with the developers.
Although the users came to expect advanced functions both for the external Web service and for the intranet, these were released to the local context for the launching of the new Web environment (Quickr was eventually implemented about a year after the launching of the portal technology). The delay in the implementation created a fundamental gap between that which actually was implemented and actual user expectations. In this case, change was less dramatic than expectations created.
Instead, the main Web page was structured according to a number of static openings where the user could choose to enter either based on role, unit, types of service sought or through the Website search engine. Ideally, it would be possible to find the same kind of information through different openings (according to the XML ideal of one input, many outputs), but this function turned out to be difficult to establish. As also the search engine lacked fundamental indexing capabilities, users found that they were forced to relearn the organizational structure of information access. As there were three hierarchies (role, unit and service) rather than one (different units), the search for information became more difficult both for internal and external users. The implementation of this new system created waves of organizational turmoil. Users wondered why access had become more difficult when they had expected greater ease. On the positive side, new patterns of interaction between units were established in order to resolve and standardize urgent problems.
An organizational effect that was triggered by the new technology was that professionals working with Web related tasks became distanced from units which they otherwise were integrated into. Web managers and Web editors from various units had at an early stage been drawn into the final stages of implementation. These technical users served as troubleshooters, but were often also seen as partly responsible for the problems by the ordinary users causing distress and tension among these technical users.
A specific problem that created major irritation was that the process of migration of data had been underrated. Therefore, large amounts of information became impossible to access, including personal Websites of all employees. One consequence was that members of the organization were not searchable through external search engines such as Google. As the problem was not promptly resolved, individual members started to establish external instruments to regain visibility. Such, so called workaround actions were, however, counter to one of the basic ideas of the new technology (e.g., Attewell 1992).
A main organizational effect of the new technology was centralized control over the whole information structure. While earlier, individual units had, within certain limits, been able to fashion individual Web-based solutions according to local needs, this was no longer possible. All Web resources were expected to be produced inside the framework of the new system. As specific tailor-made Web resources now had to be redesigned or abandoned, this restricted the flexibility of individual units.
Technical users, such as Web editors who handled the maintenance of the new Web environment also perceived, at least initially with little tacit knowledge of the new environment, that updating and producing documents was considerably more awkward process than earlier. Even the head of the information unit, with a responsibility for the whole structure, found updating a major obstacle.
The basic problems with the unstructured Web environment were resolved more satisfactory as hierarchical ideas were implemented. In addition, modern requirements dealing with user authentication, identity management, protection of data and content aggregation were also dealt with. However, the ”ordinary users” had had little information about these problems and were scarcely aware of this being a successful part of the new system.
The ordinary users we interviewed before the implementation lacked the necessary language to talk about the new technology. We have already, in this article, discussed the difficulties in understanding the meaning of a move from HTML to XML. Most users lacked an understanding of XML and could therefore not even start to articulate the meaning of this new technology. Also, we found little insights into what a portal really was, or indeed, that the new Web environment was built on portal technology.
We identified three strategies in talking about the new Web environment. First, a focus on vaguely articulated sophisticated technologies for making their work easier. These were envisioned as "intuitive" not necessarily requiring new skills in order to operate.
I hope that it will be accessible and it will be easy to look for information, reliable information (Eric1). He also hopes for more quality instead of quantity: “it is better if there are a smaller amount of functions that actually work; instead of a large number of functions that only give you trouble” (Eric1)
The second strategy for talking about the new environment was to create preparedness for a certain extent of learning. As long as there were obvious advantages in shifting work procedures, this was seen as acceptable.
Interviewer: What is your general view on the development concerning the digital milieu? Emma: As long as it is for the better, it’s good… I can think though that 'oh, damn, I had just learned how this works…' But most often the changes are actually for the better, and it becomes easier and easier [to work]. (Emma1)
A third strategy of talking about the new technology was steeped in hostility from the start. The critical views on the Web environment gravitated toward the fear that the environment would not be helpful in the daily work duties, and that the functionality would not be easy enough to adapt to the daily duties. There was also a sense of the new technology being used as a tool for control. As one user put it:
The problem lies in, I think, the routines that the system is build upon and that they are regulating - and then it doesn’t make any difference what system one has… You can change as many times as you want, but it will make no difference… It is a system to control us, even though its purpose is also to ease the work, naturally…” (Edith1).
Since the users that we interviewed lacked both the necessary knowledge and motivation for understanding the move from HTML and XML, their understanding were fundamentally removed from the basic goal of the project. This created a lack of intellectual and conceptual resources for talking about the new technology and its impact on the organization and individual work procedures.
We can now begin to understand why this new technology was implemented in a way that created confusion. Members of the organization lacked both the necessary knowledge and guidance in order to understand what was going on. This created a disconnection between expectations and outcomes:
We found that the ordinary users were given a positive image of a new technology that would yield a number of vaguely described advantages. We call these the sophisticated applications. However, the technology primarily served to solve problems relating to structuring of data which had been invisible for the ordinary users. We call this the basic transformation. The new and exciting tools, the sophisticated applications, were either slow in implementation or not forthcoming at all. Instead, the ordinary users found themselves confronting a series of new difficulties for which they were unprepared. These concerned the basic transformation, something which most members of the organization had not understood as the focus of the project.
During the process, members of the organization became increasingly uncertain about the five key language games of the project:
In the following two sections, we will focus on differences in understanding these language games between developers and members of the steering group.
David was a developer employed by the receiving organization with an overall responsibility for the whole process. He worked closely with external consultants who in turn had a contractor relationship with IBM. In the interview, he clarified that the focus of the work entailed the necessary shift from a messy HTML environment into a well structured XML environment. While he had a clear vision on what needed to be done for this basic transformation, he was also irritated about uncertainties concerning what other functions should be included and at what cost. In our terminology, the language game on features was troubling. David was interviewed during a late stage of the implementation and he could therefore reflect on how the task had changed during a lengthy and troublesome process:
... the process becomes very complex, from a project leading perspective... If I go far back in time, it becomes possible to see the initial resources for implementing the whole project and then - and then, at the time people in administration expects you to estimate perhaps a year in advance everything, all the costs and everything that is supposed to happen for the whole implementation. It is extremely difficult to go into all the details...
The general frame of the project was traditional as the goals and resources were stipulated at the outset. David found that the requirement of estimating the actual tasks and their costs far ahead in time had become unreasonable since there were so many unknowns that appeared during the project. Officials administering the resources for the project had a way of articulating project timelines that did not fit those of David. The main problem for him was that he consistently had been unable to establish "normal" rules and procedures for the project. David described the implementation process as a series of movements in which the technical artefact was transported from one environment to another, at each stage slowly increasing functionality. Each step added new complexities and the extent of these were not possible to fully predict. This meant that at any time there could be an unexpected focus on the technical issues rather than those of organizational or user oriented that were initially emphasised.
... this is how it is with complex IT projects. There's always... a technical environment that we are dependent on in some sense and then suddenly it becomes the aim of the whole purpose of the project, what it is really there for, so that it sometimes takes over. And then it becomes a balance how much they [the portal technologies] really should be adapted and what kind of service they should deliver to the project? … we are not those that should decide the purpose of the project, but it becomes impossible to avoid really and that depends on the organization.
When the technical difficulties increased, the trade-off between user oriented and technical oriented solutions became one of resources. David and his colleagues had regular meetings with the steering group that supplied guidance during the whole process.
We would really like to process this as a regular project… but what is then the role of the steering group? What does it mean to make a decision? You are not only sitting there and taking counsel. This is our forum and we must turn to it and present the situation. And if that is what they want, then they must take their responsibility. Otherwise, we can only guess and that becomes a bit difficult. At the same time, their responsibility is toward the organization and upwards. So there are many pieces.
Despite having supplied the steering group with a half day's education, David found fundamental difficulties in having the steering group understand what was really going on.
… there's probably a need for more education, I think, maybe. And I think that everyone working in the project should have more knowledge, what it means to work in a project as a coworker… what is your responsibility and how does the project work and what does it mean to have a steering group?
In practice, David found the organization lacking in knowledge on the technological issues involved. As key persons within the organization were unable to understand the range of basic and sophisticated functions of portal technology, they were unable to articulate suitable needs. This made it difficult to discuss features, priorities and motives. David felt that this shifted certain responsibilities to him that he could not handle since it was not his role to articulate the needs of the organization.
… what is it we are supposed to do? What are the goals? What is it that we are, so to speak, to deliver? These variables should be able to be checked in one sentence. You can't just say a bit vaguely that something is to be done, this is very important in this project… that you put up a certain amount of goals and they must be clear when you reach the end, to be able to say that this is done and this is done and this is not done… Otherwise it can be that the project never reaches its goal, then it is a project that has no clear goal and you do not know when it is finished. And then you don't know what to say when you need to extend the project since you haven't been able to deliver those two things… then it is also the case that many, for some of them they feel that a project, it's like "here comes Santa Claus, now we just have to wish what we are going to get."
What David sees as a lack of competence in the organization in establishing decisive goals, can also be understood as a fundamental problem of different professionals involved in different language games. They try to understand each other, but the representatives of the organization obviously have difficulties establishing clear goals as they grapple with all the various language games. David interprets this as leading members of the organization having a poor grasp of the conventions of project work and project leadership. However, the more likely explanation is the breakdown of the key language games going on between the steering group and the project group. These are like dominoes falling on each other.
As there is a problem in articulating motives, emphasis on features and making priorities become difficult. The parties then have difficulty negotiating what the implementation is about. As a consequence, the timeline becomes uncertain.
In the following, the developer perspective is contrasted with that of a member of the steering group.
Steve was a leading member of the steering group with clear visions of what he wanted the new technology to provide. He characterized himself as an advanced user with, however, limited technology-based competence.
You see, I have grand visions and expectations... this is a modern platform. This thing about how to fix the technology that is not really my thing.
We interviewed him the first time shortly before the launch of the portal and he was at the time very enthusiastic about the project. He saw the motive of the project as one of modernisation. While David, who was interviewed during this same stage in the process, had emphasized the basic transformation to an XML based environment, Steve talked, instead, about the sophisticated applications.
... it was not only about getting a Web platform, but we should also receive something that could rationalize the individual work... with the latest in digital support... and also to lead us into new ways of communicating with each other.
Steve envisaged features for facilitating handling of documents and contacts. He made reference to Web 2.0 and user-generated content and expected changes in the way that members of the organization expressed themselves.
... the current Web platform is so top-down oriented [the new platform] will create bottom-up possibilities in a totally different way. At the end of the day, this is an issue of power. Currently, it is actually the information unit that has all the power... But now the power is distributed in another way...
According to Steve, the project would also lead to changes in the organizational structure. He expected a transformation of the organization as tools for social networking were introduced with new technology.
... I myself do not use social networks excessively. And that is probably a generation issue. I have no one to be social with and I do not want to be social with people unknown to me. And the new platform supplies major possibilities for social networking and it will be interesting to see if it works better for me.
Steve saw the basic transformation as necessary and the most fundamental part of the project, but far from the most interesting.
... that this will work is something that I take for granted, so I don't care about that... Rather, what is important is the related services - they must be busy implementing them now. But I can feel that that is important because it teaches us some technology.
As we have seen, the related services, what we called sophisticated functions, turned out to be difficult to implement. When we next interviewed Steve, it had been six months since the inauguration and he was disappointed. He was frustrated over both the slow progress and unfolding direction of the project. He felt that the steering group had a common perspective and vision, but that it had become difficult to communicate this to the project group. As he saw it, not even the basic transformation had been successful.
I see no advantages at all now. I don't think I will be fully as negative as I may sound further on, but so far it has been an inferior Web without any advantages more than that we cleared away a lot of rubbish... We had both broadness and depth earlier and a lot of rubbish, now we have only broadness and no depth and not the least bit rubbish.
As stated earlier, one of the most important selling points had been a new publishing system. Steve had earlier been optimistic about implementing this function as part of the portal technology. However, when he now could get a firm grip of the technology available, he could see that this was not something that fit the needs of the organization.
... the publication tool that we received was far too complex, that is to say unnecessary complicated in order to solve even the most simple tasks. We have several publication tools within the old Web and we had developed our own publication tools, so this was not something new to us. But the way it is now, it is much too catastrophically complicated and then they have a solution that we should develop our own simplified publication system within the framework of the new and that tends to take far too long time which means that... people can't publish themselves and must go through others...
Looking back at the project, Steve felt that they should have collected more information before committing themselves to this solution. There was also a sense that he did not have the competence to understand the product that they were buying and could therefore not give the relevant feedback.
I don't think that the procurement was well done. The various systems’ advantages and disadvantages were not made clear, including the alternative to develop the old... I have no competence as a purchaser, I wanted to have, but I didn't know anything about the road to it and I didn't know anything of the various products. It was there somewhere where things went wrong. I think that we in our purchase were more intent on this going in the right direction. We wanted a portal with everything and we thought that drawbacks can be fixed...
In our analysis, the idea of pursuing a portal with everything resulted in considerable confusion about the limits of the project. Therefore, it also became difficult to focus on prioritized functions.
We have discussed a specific case of a basic transformation from HTML to XML through the introduction of portal technology. As the portal technology could do much more than simply revise existing document structures, great expectations were invested in a number of sophisticated applications, none of which were available at the time of the launch. Instead, various unforeseen problems connected to the basic transformation appeared.
What were then the main complications that have troubled the competent project organization? The project turned out to be unpredictable as it was not possible to stipulate ahead of time, or even at a late stage of the project, what types of functionality would be possible to implement given the poor structure of the earlier Web environment and the available resources for the project. At the same time, it became difficult for the involved parties to talk about the implementation process. We have attempted to understand the problematic process with the help of the analytical instrument of language games. The move from HTML to XML, the basic transformation, turned out to be the main goal of the project. However, much was implied by this simple statement and both ”ordinary users” and members of the steering group had difficulties in articulating specific aspects of the basic transformation as well as withstanding priorities concerning the much anticipated sophisticated applications. The project leaders were pressured by an increasing attention to technical detail and problems with the basic transformation. They found it progressively more difficult to clearly define the boundaries of the project in their dialogue with the steering group. This caused a sense of disappointment and confusion for all involved actors. We have identified difficulties in creating stable, shared language games concerning motive of the project, priorities, features, what the implementation was about and how to interpret the timeline of the project.
There are some similarities with the case study by Gulliksen et al. (2003) in which differences in the short time goals of the developers and long-term goals of the users, were clearly evident. In both cases, the project becomes so pressured that extraordinary priorities need to be made. This may entail a shift away from user oriented ideals as the minimum goals of a basic transformation are to be finalized.
There is much to be won by the involved actors to identify projects that tend to transmute as they progress (Gulliksen et al. 2003). Such projects havebeen studied before, although rarely. An important contribution in this paper has been a discussion of the way different professionals become engrossed in a shifting context in which they become unable to successfully communicate problems, needs and resources.
The second contribution of this paper lies in the explicit focus on the move from HTML to XML with the help of portal technology. In a sense, this is based on a vision of being in the technological forefront and taking several steps forward instead of only one. Our study shows that it is easy to underestimate the problems involved in implementation as it becomes difficult for users to articulate the needs and for developers to understand and give them what they want as well as the difficulties to in beforehand determine how users’ information practices are affected.
This paper has been supported by the Faculty R&D Board of the University of Borås.
Jan Nolin is a Professor at the Swedish School of Library and Information Science, University of Borås, Sweden. He received his PhD in Theory of Science from the University of Gothenburg, Sweden. He can be contacted at Jan.Nolin@hb.se. Katriina Byström is an Associate Professor at the Swedish School of Library and Information Science, University of Borås, Sweden. She received her PhD in Information Studies from the University of Tampere, Finland. She can be contacted at Katrina.Bystrom@hb.se
| Find other papers on this subject | ||
© the authors, 2010. Last updated: 9 September, 2010 |
|
