Product Development, Innovation and Organizational Change in a Technologically-Oriented Organization - Essay Example

Running Head: Organizational Case Study Product Development, Innovation and Organizational Change in a Technologically-Oriented Organization A Case Study Name Course Title Name of Professor Date of Submission Abstract Earlier research has put emphasis on product development organizations in determining organizational limitations on the task of system developers. This case study concentrates on the working processes of in-house system developers as they devised an innovative IT system for their organization and dealt with the related mechanism of organizational change. In this study, the organizational culture, in terms of common values, beliefs and politics, is viewed as enlightening the way in which the project was carried out and, in some way, the development of the product. The function of in-house system developers as mediators of organizational change is emphasized, with focus on their political and management techniques in implementing change. Introduction Conventional human-computer interaction (HCI) has focused on looking for means in which to devise a more functional and serviceable interfaces. This pursuit has been inclined to concentrate on the advancement of cognitive models of end user conduct in interaction with computers so as to identify design guidelines (Nadler, 1997). With the observations of Suchman (1987 as cited in Tidd, Bessant & Pavitt, 2001) of established action, collaborative design programs, and sociological descriptions of contextual computer use, this pursuit has departed from the laboratory and aimed to assume a more wide-ranging perspective of the users’ world as a means of updating design. It is thus far fairly known that organizations should be aware of the working activities of users exhaustively and contextually to devise technology that can be successfully integrated in work processes, a point of view now developed by the concern in building up groupware (Tidd et al., 2001). This case study focuses on a custom and internal development application in which common products are altered by an in-house information technology (IT) development group to appropriate the needs of the organization. Grudin (1991 as cited in Kamoche, 2002) argued that, provided with the complexity of direct user session, they could be a more suitable user group with whom developers of products can communicate. Moreover, Suchman (1994 as cited in Tidd et al., 2001) maintained that merely through the effort of internal implementers is it plausible to successfully implant innovative organizational systems into the frameworks of the organization. The in-house development group could be described rather generally as those staff members who have quite a few duties for devising prerequisites for the system, selecting well-suited software packages, amending those packages, and examining the procedure. This endeavor entails continuing communication and cooperation among an array of different interest groups in the organization including top management, users, and in-house IT experts, in addition to communication among various subgroups of interest groups (Nadler, 1997). The Unit of Technological Information (UTI), which is a fictional name, is a private organization in the United States that is accountable for monitoring and assessing in depth technical recommendations presented by a diverse array of client organizations. This assessment is afterwards returned to the client in a report form. The key staff members of the UTI are 150 examiners and 100 managerial support personnel. Examiners carry out their tasks independently, even though they are arranged in semi-product teams, performing their assessments with reference to their personal expert opinion and available material, a great deal of which is stocked up in internal records. The UTI has been quite a new organization but there is a well-built sense of tradition among the examiners who have a profoundly ingrained pride in their position as professionals with an inimitable source of knowledge. Currently, UTI is going though some large-scale restructuring that had troubling consequences. Numerous staff protested to the relocation to a new office and some view it as the start of more critical changes, capably endangering their entire way of work. Problem Statement This case study aims to contribute to the knowledge of the task of these in-house system developers in the context of their organization. In this study development mechanism is viewed as both influencing and influenced by the politics and culture of the organizational context. This study will concentrate on the working activities of the development group as they aim to introduce the recommended new system in this particular organizational context. The IT development group in this study is identifying prerequisites for a core system of workspaces to support an array of office activities in a U.S. private organization. Thus, this is not a radical endeavor; though, it reveals an ever more widespread development in organizations. This study will not support how this mechanism must be performed, but it will attempt to explain comprehensively how it was performed in this specific framework, clarifying why it developed in this manner given the politics, culture and working activities of this particular organization. This study would attempt to understand, specifically, the growth of group’s task as change mediator in directing this process. Data Collection and Methods of Analysis In-depth interviews were conducted with present staff members of the development group. A total of 10 people were interviewed. Confidentiality and anonymity was assured and all interviews were recorded. Even though the interviews were reasonably unstructured, facilitating investigation of interesting issues as they surfaced, several domains were included with all interviewees: their definite task in the assignment, their view of the organizational context, their preparations for the development procedure, and their evaluation of user communication practices. Another method used in the study is observation. The two development group members whose primary duty are to design and operate the system displays, Alex and Tom, were guided by the project director Vincent and user project director Roy. At the outset, roughly 5 presentations were performed by the developers, with approximately two or three examiners being present in each one. Department leaders were asked to recommend capable attendees and to consider several employees who were well-informed and some who were inexperienced with computer technology. It was assumed that these appointed attendees would afterwards provide comments and ideas to others in their department. The system demonstrations consistently implemented the same layout. Roy would give an opening remark about the significance of the venture and the underlying principle for the project. Vincent would afterwards present a general idea of the system, mentioning all the purposes and packages they expect would sooner or later be available through the workspaces, such as access to word-processing applications and updated databases. Alex and Tom would then present one specific component of the system comprehensively. Alex would demonstrate a simulation of a designed database of internal records as well as how these would come out on the monitor and how they may be inspected electronically. Tom would then show their new contact to outside, commercially accessible computerized databases. An open forum will follow. The researcher attended two of the presentations as an observer, writing down the remarks of the demonstrators, specific occurrences, and the open forum. Particular occurrences were noted down as they took place. Common issues regarding the general interfaces of the developers with the attendees were also noted. Findings Making Decisions on Organizational Design An essential feature of the history and culture of UTI was the skill of users to wield decisive control over the development mechanisms of IT. Even though the development group normally employed the language of user-driven blueprint, it was evident that this was considered frequently more as a model than a functional possibility. According to one of the interviewees, Marlon, in principle the user is the one who decides, but in actual practice they should occasionally have to decide as to which of the different options is the most favorable way to go. Alex’s recommended solution to this problem were enhanced communication and interface with the development group and an official endorsement of all important decisions by the IT Development Officers. Nevertheless, this solution was founded on a perspective of preferred situations emerging ‘spontaneously’ and choices being made based on alternatives provided, while the development group was more optimistic in building a thrust for their favored direction. According to Vincent it would be less exasperating to create a system you think has a prospect. Hence he is trying to obtain that decision concerning a graphics interface from the blueprint. The appropriateness of this choice was further shaped during the presentations; for instance, the presenters talked about the positive feedback and recommendations of other examiners; hence these others assumed that the system render in-house paper records unnecessary and earlier participants wanted it immediately, as revealed by Vincent. Certainly no other alternatives were actually provided at these presentations. Decision and Obligation In this alternative-making process, it was the alternative maker who was utterly accountable for that decision. As Vincent stated, the manner he elected to discuss the topic of functionality of the interface in order that they will have an unambiguous argument is for the users in fact to own all the choices instead of the IT individuals. Moreover, the users were offered with alternatives that were not actually alternatives at all. Roy, the user director said that if they want to complete the assignment in the soonest possible time they have to begin operating a number of these phases similarly; if they do not operate similarly, they will be late, and if they do, it could go wrong. Deliberation of the design procedure facilitated this distribution of task: Individuals begin posing questions—“what if my secretary has to encode that?” “That is actually physical and it should not concern you, we will discuss that later, we are discussing logic now.” Finally, they state “I cannot comprehend how it stands so I will just approve it; it should be accurate since they claim that it is logical.” Thus you proceed to the next phase, physical, “What is the reason it does not perform that?” “Actually you cannot perform that because we do not have information for it.” “Why is that the case?” “Because you move out from the logical, and now we are already too far that it will cost you big time.” These responses were from Roy, the user director. Deliberation in the sense of keeping records and official discussion processes also had negative consequences on the ability of the user to sustain a vital ability. At this point, making the right choices and the most useful decision was not the sole issue. The members of the organization were also concerned in who will be held accountable for the success or failure of the decision. Moreover, organizational issues such as concerns on time and effort forced the development group to prefer specific alternatives and hence, to safeguard that choice, the group had to downplay other alternatives. Conflict between the Development Group and Users Vincent’s apparent desire to try innovative technical solutions was sensed by several examiners to require controlling. As Roy has claimed, Vincent is more knowledgeable about introducing IT than any of the staff members but he likes thinking independently so he needs a degree of controlling. Vincent is utterly full of eagerness but has a tendency to be quite ambitious. For the other members of the design group, an organized framework was observed as facilitating control over work procedures. According to Roy, they have to ascertain that the technical personnel do not damage it thus they have to enforce a degree of control and Roy thinks that this is the reason for their use of ‘structured systems analysis and design method’ (SSADM) in the organization. The inconsistency here is that while users thought SSADM gave them power over the development procedures, this form of formal process was also claimed as a functional image administration strategy for the development group. In addition, time limits implied that Alex and Tom could not tag along with SSADM in the given way but had to downplay and operate phases similarly. Conflict within the Organization Nevertheless, it was not merely the users who expressed anxiety about the function of the technical specialists in the project. Rudy mentioned in an interview about a definite presence of disagreement within the organization, specifically between the IT division and with the Design team formerly accountable for IT improvements in the organization. Vincent referred to this disagreement in the interview: “Actually we are receiving more criticisms from the technical department than from the users.” Like Roy, Rudy was anxious that Vincent may have been operating further with his eagerness for innovative applications. Rudy said, “I am aware that there are members of the IT division who have in fact had a glimpse of several of the previous records and sensed possibly that the development group was rather too ambitious.” Nevertheless, Vincent had a dissimilar point of view on this matter and a special political faction from which to obtain valuable resources. Vincent forcefully argued: The IT division has a tendency to oppose change. I believe that there is a resistance to the operating environment. It is very unfortunate that the users have to cling with the archetype.” Of particular concern here is the way in which Vincent could challenge the IT division’s issues against his detailing of the user’s perception. However, another significant role of the demonstration surfaces, that is, as a political instrument to exploit within the IT division. Intensifying the concern of the IT division was possibly a further political intention. As Vincent claimed, “The IT division is concerned about the reinforcement of Phase 1 after improvement. I remarked that the development group would afterwards be knowledgeable enough to reinforce the improved product… making use of the project group as support personnel, technological department view as a threat.” Rudy evidently had loyalty to the broader IT division in this disagreement and to a certain extent this could elucidate his interruption at the system presentation. Nevertheless, it would be very crude to view this as a clear-cut manifestation of unprejudiced concern. The Design group was liable for in-house documentation and consequently those features of the development task that included these records were also their responsibility. Rudy had an obvious personal regard for the director of the Design group, such that he could observe that deep-seated conflict is being produced by the present organizational design. “Design team has an obligation for monitoring developments… and possibly there is a touch of political motive at the current period where a number of that function appears to be being mislaid,” claimed Rudy. Permeating these discussions is the sense of changing loyalties underlining the significance of taking a diverse point of view on both the technical groups and the user. Certainly it is plausible that the form of group identity developed in the development group implied that more uniformity of perspectives was observed among the development group members than among the technical personnel or users. In collaborating for the completion of the project, the development group was creating a common understanding of the purposes of the projects that could have been at conflict with those intentions embraced by the groups they were embodying. Summary and Conclusions It has been demonstrated in the study that the different expertise of end users, managers and designers compels them to have different points of view on design difficulties. These differences in expertise force them to have different objectives for organizational structures. Also, in-house development groups may be composed of an array of employees. Formal organizational systems may to a certain extent influence this group formation and the issues of people within it, several members having a more powerful position and some members positioned in formal tasks such as project director or user representative that necessitate definite prescribed activities and directions. Therefore, even though the group may hold a common objective of putting into effect a functional system, individuals could also embrace other objectives to fulfill. Particularly, representatives could have separate allegiances between the group and those they suppose to be representing. This could result in a more flexible situation, with changing loyalties, where occasionally a development team member is lined up with one group and occasionally with another, hinging on the situation. It must also be noted that, even though there could be various organizational subcultures, there is as well a shared understanding that provides design members a common language by which to communicate. It is this common perception and knowledge that enables in-house developers to implant organizational systems. On the other hand, consideration of cooperation in perspective also permits us to look at the symbolic and political roles of specific cooperative practices. In this study, user discussion was as much a political mechanism as a direct transmission of information or a type of organizational democracy. However, in this study, it is not basically a concern of the development group failing to endeavor in appropriate user participation; they were devising a strategic response to the current condition and recognizing the private medium of change. I would as well conclude from this study that it is not fundamentally that user involvement facilitates the formulation of precise requirements. It could be that the procedures, as it is in line with the organizational culture, bestow reliability on the formulated prerequisites and the product. Effectiveness of a system could count on how successfully it has been sold to the end users and their views of what has occurred throughout the design procedure as much as the concrete product designs: “The machine will work when all the relevant people are convinced” (Clark & Fincham, 2001, 77). A number of cooperative practices could be more functional than others in persuading users in various forms of cultural contexts. Studies concentrating on various techniques in various contexts would assist in the clarification of this concern. Within the organization of UTI, in-house developers are viewed as local analysts of the common product and the organizational culture. They are accountable for implanting the product in internal working processes; rendering it relevant to the organizational work context. Within the organization, in-house developers are indeed viewed as organizational change mediators, dealing with the procedure and consequences of technical change for the organizational culture, with particular focus on the cultural and political features of that work processes as organizational change is implemented. The organizational forces that affected the actions of the developers should also be noted; for instance, limitations in time and resources, the commitment already guaranteed by the development group in searching for a solution, and their individual political professions in the organization. Nevertheless, another potential explanation is that the members of the development group were making use of the disputes at their disposal to advance what they thought to be an effective and efficient system, to surpass what they evaluated to be critical concerns, and to resolve possible conflicts so as to deal with the process successfully for the users. These are the defining characteristics of a specific form of change mediator, attempting to produce a change that seemed threatening to several members of staff as effortlessly as necessary while being receptive to and operating the political features of change. Enhancing designer competencies in terms of technological knowledge and experience, or even their understanding of the psychological restrictions or working behavior of the users, would seem to be merely a fragment of the story. The in-house development procedure is not merely a technological practice but a political, social and cultural venture. As a result, further change management capabilities are evidently needed for system developers. Specifically, developers must be prepared to the symbolism widespread in the organizational culture of computerization venture, facilitating a more receptive framework to organizational change. References Kamoche, K. (Ed.). (2002). Organizational Improvisation. New York: Routledge. Miner, J. B. (2002). Organizational Behavior: Foundations, Theories and Analyses. New York: Oxford University Press. Nadler, D. A. (1997). Competing by Design: The Power of Organizational Architecture. New York: Oxford University Press. Poole, M. S. & Van De Ven, A.H. (eds.). (2004). Handbook of Organizational Change and Innovation. New York: Oxford University Press. Sims, R. (2002). Managing Organizational Behavior. Westport, CT: Quorum Books. Tidd, J., Bessant, J. & Pavitt, K. (2001). Managing Innovation: Integrating Technological, Market and Organizational Change. New York: John Wiley & Sons. Read More