Lecture 1: Introduction

Lecture 1:Introduction Jarmo Sarkkinen

ICWPT:Aims & description To provide an understandable, both theoretical and practical, introduction to the emerging field of implementing meaningful changes in work practices (WP) and technologies (T) on IT development projects. More specific aims include the following ones. To demonstrate which social (situational, institutional and societal) issues may have a central role in the course of implementing changes in WP&T. To emphasize that change is more than providing IT; it is also a matter of dealing with IT in work, as part of work systems and practices. To emphasize issues such as diversity of viewpoints, voices and representations of design. To emphasize what developer skills, qualifications and orientations are needed. To stress the importance of understanding the role of human interaction, intersubjectivity and understanding as factors of successful change processes. Finally, the aim is to introduce a set of methods grounding changes in IT upon stakeholder viewpoints, and work, work systems and practices.

ICWPT:Lectures & discussions 28h => 3 cu/5 cp Lectures (11.1.-23.2.06) will be held on Wednesdays at 10-12 am (Place: Auditorio) and on Thursdays at 10-12 am (Place: Etäluokka) No exercises, but approx. 5 articles will be read and they are discussed in a couple of get-togethers both in groups and in public These get-togethers are basically mandatory (at least 4 of these will be arranged later)

ICWPT:Exams Exam #1 2.3.2006 Exam #2 on April Exam #3 on May Exam #4 on June? Material for exams include: Lecture slides, your own lecture notes (be active!) and some book chapters and articles (those to be discussed plus some additional but easily digestible texts to be announced later)

ICWPT:Staff Responsible lecturer: Jarmo Sarkkinen /Dept. of IT jarmo.sarkkinen@utu.fi Tel. 02-333 8644 Room: 2158

ICWPT:Material Literature and any other relevant reading material will be announced as part of lectures, and information together with links (if possible) will be added on the course home page http://staff.cs.utu.fi/kurssit/ICWPT/ after each lecture. Lecture slides as ppt files will be accessible through web on the course home page after lectures as well. Distribution of articles not available on web?

ICWPT:”Rules of the game & numerical evaluation” Final exam: 0-5 Participation in (basically mandatory) group discussions with the active group participation in public discussions may increase group members’ final score up to the higher score in borderline cases

ICWPT:Content Four thematic parts of the course: • Conceptual basis • The developer view • The interaction view • Methods of change

Implement • To implement is to: ”put into practical effect” “carry out” ”supply with implements” • An implement is ”a tool or instrument used in doing work” “a means of achieving an end” • To implement ”changes” ???

IS implementation: four views • as technology acceptance • as organizational change • as organizational problem-solving involving mutual adaptation • as meaning construction seen through a critical framework; as totality of meanings; as part of social reality; with (un)intended results (Myers 1994)

ICWPT • NOT a matter of requirements elicitation, requirements analysis or requirements planning • During ’pre-implementation’ (NOT ’actual implementation’) • During early stages of ISD • Is a matter of changes (NOT of systems and technologies as such) • Implemented ’on paper’ or ’on computer’ (NOT as systems or technologies) • Representations of changes (NOT actual changes within organizations)

ICWPT • To plan a change in work practices and technologies is already to implement it to some extent • Carried out during interaction in development teams • Is a matter of constrained construction of objects of change • ”Process matters” (Keil 1991) (NOT factors)

IS success • The common belief in the development of IS has been that user participation is a condition for success, for a high-quality process of development and the system itself • Positive consequences such as system usage and user information satisfaction may follow • The relationship between user participation and system success is, after all, an issue of dispute

Factors of success RESPONSIBILITY IS success (e.g., system use; user satisfaction) USER PARTICIPATION USER INVOLVEMENT CONTROL OVER DECISION OUTCOME But what is (user) participation?

IS/IT failure • Failure rates are high • How to define failure? • Absolute system failure (termination failure) • Correspondence failure • Process failure • Interaction failure • Expectation failure

Failing to learn--learning to fail • E.g., American companies spent $59 billion in 1995 in cost overruns on runaway IS projects • Failing to learn from organizational experiences • Failing to learn effective means for solving problems and even learning to fail • The Taurus project (Drummond 1996)

Model of ”learning failure”(Lyytinen & Robey 1999) Failure to learn Persistence of Invalid ”Myths-in-Use” Learned Failure in ISD Barriers to learning -Limits on intelligence -Disincentives to learning -Organizational design -Educational barriers

Temptations behind IS/IT mess(Alter 2005) • Technology = system • Technology is a magic bullet • No responsibility for systems • No performance measurements • Superficial analysis • One-dimensional thinking • The assumption that desired changes will implement themselves

Participation processes and interaction, and IS/IT success To study participation itself, instead of measuring the significance of factors such as user involvement for the success of participation, the user participation process needs to be concerned (Cavaye 1995). As part of this process, the dynamics of the user-analyst relationship, the interaction itself, is seen to affect the “extent and effectiveness of the process” significantly (ibid., p.314). It is, however, insufficient in heterogeneous design teams if the focus is merely on shop-floor users. The participation view thus needs to extend to include many types of professionals, managerial personnel, for example (Markus & Mao 2004).

Change:three facets of IS • System • Group collaboration • Organization

Change:the system facet • IT as a key element of change (i.e., object of change) • Heterogeneity and incompatibility among systems • The seamless IS infrastructure • Data sharing and functionality across systems independently of the platform

Change:the group collaboration facet • People working on a common process • Activities coordinated, contingencies dealt with, and practices changed through discussion and learning • Unpredictability

Change:the organizational facet • Managing work • Global organizational concerns, organizational objectives and business goals, policies, regulations, work flow and project plans • Initial requirements for large systems typically originate in this facet

Interrelationships between facets • How do changes in one facet entail changes to another facet?

The work system framework(Alter 2005) • Focusing on work, not just IT • A work system is a system in which human participants and/or machines perform work using information, technology, and other resources to produce products and/or services for internal or external customers • Key elements include work practices, participants, information and technologies

Work practice (WP) • Rarely defined Practice = ”habitual or customary performance”, ”the act or process of doing something; performance or action”, a habitual or customary action or way of doing something”, ”a habit or custom”, or ”exercise of an occupation or profession” • WP = a customary way of doing work

Work practice (WP) Work practice accounts for ”the concrete and mundane activities of practitioners as they are encountered by the members of work communities in the everyday settings” with the interest ”in the processes of interaction between practitioners and their use of the material media and tools as well as technological environment” (Karasti 2001, p.26) • The book ”Inside the IMF” by R.H.R. Harper (1998)

The work system framework(Alter 2005) What is wrong with this figure?

Final notes • Whichever the period of ISD, current and future work practices and technologies are not necessarily separated in discussions • There is no predetermined contents for discussions carried out in different periods of ISD • It is normal that during requirements determination, people ’test’ ideas, and during system testing determine requirements

Lecture 1: Introduction