Projektet som så

• Et system må ikke rulles ud i organisationen uden at være gennemtestet og fejlrettet.
• Et system bør altid afprøves i et pilotprojekt.
• Ledelsen bør ikke igangsættes for mange forskellige systemer på samme tid – ambitionsniveauet bør være realistisk.
• Et system/projekt bør risikovurderes: hvor afgørende er det, at deadlines for projektet overholdes, hvilken indflydelse får det, hvis systemet ikke er fuldt færdigt til tiden etc.
• Sammenhængen mellem udviklingsopgaver (f.eks indførelse af et nyt system) og driftsopgaver i en afdeling bør klarlægges, så udviklingsopgaver ikke forsinkes af driftsopgaver – og så driftsopgaver ikke syltes pga. udviklingsopgaver.
• En nyvedtaget politik, der medfører indførelse af nye systemer, skal - inden man fører politikken ud i praksis - nå at trænge ned gennem organisationen, dvs. den lokale ledelse skal nå at tænke konsekvenser igennem og tage højde for det nye projekt i planlægningen.

Brugerinddragelse

• Slutbrugere bør inddrages i systemudviklingen fra starten.
• Ved brugerindddragelse/høring er det vigtigt, at der meldes tilbage til brugerne, i hvilket omfang ønsker og krav er taget med ind i projektet, og hvorfor ønsker og krav evt. ikke er taget med i projektet.
• Det skal fastlægges, hvor systemfejlmeldinger samles op, hvad der gøres ved dem, og der skal meldes tilbage til brugerne, hvad der er sket med systemfejlmeldinger. Dette kan ske på projektets webside.
• Der bør oprettes erfa-grupper blandt brugere med samme roller, erfagrupperne bør kobles sammen med de centralt ansvarlige personer.

Kommunikation

• Det afklares og udmeldes fra start i projektet, hvorledes kommunikationsvejene er: inddragelse af fakulteter, institutter og afdelinger, hvem har ansvar for hvad?
• Der skal kommunikeres så tidligt som muligt om beslutning, projektets omfang, tidsplan etc. Det er særligt vigtigt at kommunikere ud, hvorledes projektet/systemet forventes at have indflydelse på de decentrale enheders arbejde
• Kommunikationen bør samles på en webindgang, der er dedikeret til systemet og dets udbredelse.
• På websiden bør alle informationer samles blandt andet i kronologisk orden, så man kan danne sig et overblik over udviklingen i projektet. Alle mails og anden kommunikation samles også her, for at sikre videndeling f.eks. med personale, der ansættes eller involveres i projektet senere end ved starten.
• Tidsplaner, referater, annoncering af ændringer etc. lægges på websiden.

Uddannelse

• Uddannelse i brugen af et system bør altid anvende eksempler, skærmbilleder, opgaver etc. fra AU-virkeligheden. Uddannelsen skal afspejle brugernes virkelighed.
• Såfremt uddannelse varetages af personer uden for AU, der kender systemet, men ikke forholdene på AU i detaljer, skal uddannelsen følges op af interne workshops/erfaringsudvekslinger med AU-ansatte
• Tidspunktet for uddannelse bør afpasses til, hvornår systemet kan tages i brug. Man bør straks efter endt uddannelse kunne gå tilbage til sin arbejdsplads og afprøve det, man har lært – enten i et system i drift eller i et testsystem, der er identisk med det endelige system.

Vejledninger, hotline, hjælpefunktioner, dokumentation

• Der bør etableres en hotline til bruger-eksperter, der let kan hjælpe brugere af systemet. I startfasen bør man altid kunne få fat på hot-linen inden for almindelig arbejdstid. Hotline bør altid findes.
• Det bør være klart fra start, hvem man kan og skal spørge om hvad, når man er bruger af systemet. Dette bør formidles via system-websiden.
• Der bør udarbejdes en fyldestgørende dokumentation af systemet, der er tilgængelig for alle.
• Dokumentationen skal beskrive instrukser, retningslinjer og vejledninger.
• Dokumentationen skal skabe overblik over systemet, forklare funktion, skærmbilleder, felter, genveje, opsætningsmuligheder, udskriftsmuligheder etc.