Begreber om Forundersøgelse og MUST metodens Principper

Forundersøgelse Formulere problem, afklare mål, skitsere løsninger Skabe et bæredygtigt grundlag for realisering af IT Skabe en samlet vision

Forundersøgelsens resultat Forundersøgelsesrapport analyse af behov og muligheder visioner om den samlede forandring konsekvenser økonomi strategi og plan for realisering + prototyper/mock-ups

Hvorfor Forundersøgelse? IT-projekter er præget af høj usikkerhed: Høj kompleksitet: ikke alle "variable" er kendte - og de er ikke uafhængige Høj foranderlighed: nye krav og løsninger under vejs Høj situationsafhængighed: planlægning og styring en del af arbejdet Høj risiko for værdikonflikter: forsk. aktører har forsk. interesser

Eksempel: P3 Sammenhæng med andre projekter ikke kendt på forhånd Dybdeanalysen afdækkede behov for koordinering Uddannelsesprojekt for IT-konsulenterne og journalisterne kunne ikke deltage så meget som planlagt Opblødning i faggrænser

MUST er designet til at håndtere usikkerhed Kompleksitet og foranderlighed: t/v til løbende indsamling og bearbejd- ning af information Situationsafhængighed: t/v til aktiv projektledelse Værdikonflikter: princip om reel brugerdeltagelse; dialog og høringer; styregruppe

MUST tilbyder 4 typer af ressourcer

Fællestræk ved FU-projekter Udgangspunkt: en problematisk situation Uklar/uenighed om problem eller løsning Understøtter trinvis beslutning definér problem konstruér løsning(er) vurdér "omfang" af realisering

Eksempler P3: ny IT til produktion af radioprogrammer men hvad var problemet? SFC Inf.- og ordremodtagelse: outsource ordremodtagelsen til bibliotekerne, men det var ikke hovedproblemet og bib. ikke klar til opgaven

Konflikter er uundgåelige Virksomheder er ramme om fælles og modsatrettede interesser Mennesker har forskellige placeringer og relationer til virksomheden IT-projekter påvirker interesser, placeringer og relationer

Eksempler: DR Traditionelt: teknikafd. og IT-afd. stor indflydelse på valg af prod.udstyr og IT-syst. Nu: brugerafd. vil selv styre P3 ledelsen ønsker styring af programindhold og de ansatte ønsker synlig ledelse Men de ansatte vil selv bestemme programindhold

Designerens rolle Dæk ikke over og løs ikke konflikter Udvikel forsk. visioner og vurder deres konsekv. Overlad til parterne at forhandle Argumenter fagligt; nedton egne dagsordner Modex: McKinsey på DR: brugerdeltagelse og skjulte dagsorden om rationaliseringer Hvordan vil I forholde jer til evt. konflikter?

Perspektivbegrebet Forskellige syn >< konflikter Ståsted: ex: fugl eller frø Selektion: ex: individuelt arbejde eller koordinering, journalisternes arbejde eller ledelsens Fortolkning: ex: holdninger, værdier, antagelser

OBS på mange sammenhænge Sikre at relevante aspekter indgår Ikke givne på forhånd Skabes dynamisk i social interaktion Reducere kompleksitet v.hj.a. skiftende fokus Perspektivbegrebet igen: Selektion

Projektsammenhæng Fokus: Projekter er tidsafgrænset og deltagerne har multiple ansvar 2 aspekter: Forundersøgelsesprojekt: andre relaterede projekter? Realiseringsprojekt: vurdér vision ift. rammer for realisering Dette er primært et projektledelsesproblem

Brugssammenhæng Fokus: Organisatoriske forhold 2 aspekter: Forretningsstrategi: relation til de overordnede mål Arbejdspraksis: relation til brugernes hverdag

Teknisk sammenhæng Fokus: relationer til IT-strategi 2 aspekter: IT-systemer: eksisterende/nye IT-systemer samt den forretningsbaserede IT-strategi IT-platform: teknisk IT-strategi

MUST og sammenhænge - et eks. Forundersøgelsesprojektet: Netværk af forskellige aktører der også er ansvarlige ift. deres permanente kontekster Ex: T/V brugt i P3-projektet: Projektetablering Review Referencelinjeplanlæging

MUST og sammenhænge - et eks. Forretningsstrategi: Relationer til de overordnede mål Ex: Brugt i P3-projektet: Projektgrundlag Strategianalysen

MUST - 4 principper P1: En samlet vision P2: Reel brugerdeltagelse P3: Arbejdspraksis skal opleves P4: Forankring

P1: En samlet vision Hvorfor? sikre samtænkning af IT + orgudv. + kvalifik.udv sikre bæredygtighed: balancen mellem udvikling, udnyttelse og beskyttelse af ressourcer sikre mod utilsigtede negative konsekvenser sikre det bedst mulige beslutningsgrundlag

Ex: P3-projektet (1) Dybdeanalysen afdækkede ønsker til arborg. Besøg på andre radiostationer: IT +arborg. Visionsudviklingen: Forståelse af arbejdsorganisering => krav til IT Scenarier: sammenhængende arbejdsfunktioner +IT FU-rapport: IT + arb.org. + uddannelsens indhold og omfang

Ex: P3-projektet (2) Bæredygtig? Trinvis beslutningsgrundlag Projektgrundlag Behov og mulighedsrapport FU-rapport Vi introducerede høringer + involverede 1/3 af P3 Anbefaling: eksperimentér med arbejdsorganinseringen under realiseringen

P2: Reel brugerdeltagelse Hvorfor? sikre at visioner modsvarer oplevede behov sikre brugernes ret til indflydelse sikre gensidig læring

Ex: P3-projektet (1) Brugere i PG; ledere i SG 1/3 af P3 interviewes/observeres + høringer Ledelsen indstillet på at lytte til brugerne 1 bruger og 1 designer interviewer/observerer sammen og bearbejder Besøg på andre radiostationer Visionsudvikling på en bar i Tyskland

Ex: P3-projektet (2) PG samler og systematiserer ideer til en samlet vision Designerne orienterer om teknologiske muligheder og introducerer ideen om horisontal/vertikal koord. Designerne: forslag til forløb og teknikker Designerne arbejder også alene!

P3: Arbejdspraksis skal opleves Hvorfor? sikre førstehåndskendskab sikre relevante og forståelige beskrivelser sikre at der ikke kun foreskrives sikre at de interv./observeredes synspunkter indgår sikre adgang til det der kun viser sig, når man forsøger at forandre

Ex: P3-projektet: PG observerer PG beskriver i "P3 sprog" + børnetegninger interventioner: kun i virtuelle verdner: ideer=>konsekvenser=>nye ideer + scenarier; Mock-ups

P4: Forankring Hvorfor? sikre at de foreslåede forandringer bliver realiteter SG + anden ledelse: skal beslutte ansatte + interessenter: skal benytte eller påvirkes ansvarlige for tekn. + org. realisering

Ex: P3-projektet 6 SG-møder + løbende kontakt til SG-formand 3 brugere i PG + 1/3 interviewes/observeres + høringer interne IT-konsulenter i PG: leverencestyring externe programmører: læste FU-rapp + fik prototyper + observation af arbejdsgange P3 stod selv for org. realisering

Teori og Metode Teori: Beskrivelse og forklaring af et fænomen En teori sætter os i stand til at forstå væsentlige lovmæssigheder og mekanismer, der bestemmer udformning og forløb af IT-projekter Metode: En fremgangsmåde til løsning af en opgave, eller hvordan vi kan interagere med fænomenet, når vi vil regulere det En metode er handlingsanvisende. Den giver retningslinjer for hvordan en opgave kan håndteres