Projektarbete

Det är ju faktiskt....

eller är det...

Ett tag sedan och utan glasögon men... joo det är det

Klicka på henne så...

Sammandrag ur A Comedi of Errors: London Ambulance Service (LAS): (HansM)

LAS larm system svarar för : mottagning av samtal, larmning av ambulanser beroende på typ av larm och tillgängliga resurser, och övervakning av hur åtgärderna framskrider efter larmet. Ett databaserat larmsystem, skulle utvecklas och där skulle det ingå ett automatiskt fordons lokaliseringssystem (AVLS) och en mobil dataterminal (MDTs), för att underlätta automatisk kommunikation med ambulanserna. Det här systemet skulle ersätta det nuvarande manuella systemet.

Direkt som systemet togs i bruk, ökade samtalstrafiken (inte till någon extrem nivå). AVLS systemet klarade inte att hålla reda på fordonen läge och status. Det här ledde till att databaserna blev felaktiga så att a) enheterna användes inte optimalt, b) flera enheter än det behövdes skickades på en del uppdrag. Som en konsekvens av detta, genererades ett stort antal felmeddelanden så att systemet belastades och blev trögt. Oåtgärdade felmeddelanden genererade i sin tur nya meddelanden, som lade sig högst upp på bildskärmarna. Denna mängden av meddelanden gjorde att väntande felmeddelanden och larm som just fanns på skärmen scrollades ut från skärmen och blev "osynliga". Ambulanspersonalen blev frustrerade, och under deras pressade arbetssituation, var de dåliga på att inrapportera statusen på sina enheter. De kunde inte (ville inte) använda sina MDTs, och gjorde inmatningsfel då de lade in statusinformation. Allmänheten ringde upp igen eftersom svarstiderna var så långa. AVLS systemet visste inte längre vilka enheter som var tillgängliga och resursfördelnings mjukvaran tog lång tid på sig för att genomföra sina sökningar.

Hela systemet brakade i hop(En ambulans for ut för att finna att patienten hade dött och att begravningsentreprenören hade hämtat liket. En annan ambulans besvarade ett larm om hjärnblödning efter 11 timmar - 5 timmar efter att patienten själv tagit sig till sjukhuset.). Det datorbaserade systemet togs delvis bort, och funktionerna (anmärkningsvärt nog åtgärdsbesluten efter larm) gjordes manuellt. Det här delvis manuella systemet övertog helt 8 dagar senare. Backup servern fungerade inte, eftersom den inte hade utprovats färdigt. Larmoperatörerna använde bandspelare vid larm och övergick helt till manuell behandling. Verkställande direktören för LAS avgick.

Utredningar efteråt har visat på en mängd problem, vilka inte alla tas upp här.
Slutsatserna man drog var:
· Mjukvaran var ofullständig och funktions otestad.
· Genomförande (införande) sättet var riskabelt.
· Olämpliga och obefogade antaganden hade gjorts under kravspec processen.
· Det brast i samråden med användare och kunder under utvecklingsprocessen, som direkt berörde deras synpunkter på slutresultatet .
· Den dåliga anpassningen av systemet till den organisatoriska strukturen för ambulans tjänsten.
· Slutligen, men för den skull viktigt, var det dåligt gjorda användargränssnittet, bristen på robusthet, dålig prestanda, och rena buggar och fel.

Uppgiften:

- Senast 23/1,inlämna typ tekniskt PM om 6-8 sidor
- Rekonstruera och beskriv projektförloppet.
- Redogör bl.a. för alla viktigare händelser med relevans för misslyckandet.
- Analysera svagheter i projektarbetet, samt relatera dessa till innehållet i läroboken.
- Föreslå åtgärder som (med rimlig hög sannolikhet) hade kunnat förbättra utfallet. Även förslagen bör relateras till innehållet i läroboken.

Hämta rapporten
Tanken bakom att använda rapporten i digital form är:
· Det blir enklare att använda WordFinder. Dvs du markerar ordet du vill översätta i rapporten, och klickar på Alt + H-Shift, så letar WordFinder automatiskt reda på ordet. (Förutsatt att WordFinder är öppnad i bakgrunden)
· Du kan också lätt skicka tillbaka ordet från WordFinder till ditt dokument, genom att dubbel klicka på det översättningsalternativ som passar bäst. Ordet ersätter det markerade ordet eller hamnar där cursern är.

Exempel på struktur

1.0 Bakgrund
1.1 Presentation av systemet
1.2 Val av leverantör
1.3 Projektledning
1.4 Testning
1.5 Utbildning och personalfrågor
1.6 Igångsättandet av systemet

2.0 Svagheter i projektet och förslag till åtgärder
2.1 Personal
2.2 Teknik
2.3 Upphandling
2.4 Testning
2.5 Projektledning

3.0 Slutsatser

4.0 Referenser

Inledning

Denna rapport beskriver projektet att datorisera Londons ambulansservice i början av 1990 talet. Projektet havererade fullständigt och kan nästan ses som en parodi över programvaruutveckling.

Rapporten behandlar de centrala delarna av händelseförloppet, där nästan varje steg är ett steg mot det totala haveriet av projektet. Dessutom beskrivs förslag på vad som skulle ha gjorts istället för att undvika det faktiska utfallet.

Rapporten är skriven med målsättningen att kunna läsas med behållning av person med kunskaper motsvarande en normal D teknolog, men som inte nödvändigtvis har gått kursen programvaruteknik (2I1250).

Den teoretiska grunden för rapporten bygger på boken ''Software Engineering'' av Ian Sommerville, Addison-Wesley 1996. Det empiriska materialet kommer från rapporterna ''A Comedy of Errors: the London Ambulance Service case study'' av Finkelstein A. och Dowell J. samt ''Report on the Inquiry Into The London Ambulance Service''.

Presentation av systemet

LAS och CAD

LAS (London Ambulance Service) grundades 1930. Organisationen är uppdelad i en akut enhet (Accident and Emergency, A&E) och en icke-akut transportenhet. LAS täcker en geografisk area motsvarande drygt 1 550 km. I området bor 6,8 miljoner människor, men dagtid vistas betydligt flera människor i området. Dagligen fraktar LAS över 5 000 patienter och tar emot 2 000 till 2 500 telefonsamtal, varav mellan 1 300 och 1 600 är akutsamtal. Antalet anställda är 2 700, varav drygt 2 000 tillhör den operativa verksamheten. LAS har 305 akutbilar och 445 transportfordon.

Första gången LAS övervägde att datorisera sitt ledningssystem var i början på 1980-talet, men idéerna utvecklades inte till något konkret projekt förrän hösten 1990. Datorstödet kallas för Computer Aided Despatch, vilket i fortsättningen förkortas CAD. Ett CAD-system kan tänkas stödja fyra olika funktioner:

Utvecklingsmodeller

Sommerville [1996] beskriver två olika sätt att utveckla datorsystem: vattenfallsmodellen och Boehms spiralmodell. Vattenfallsmodellen består av följande steg:

* Specifikation
* System- och mjukvarudesign
* Implementation och modultest
* Integration och systemtest
* Drift och underhåll

Utveckling enligt vattenfallsmodellen är huvudsakligen linjär, även om det förekommer att man backar och återvänder till ett tidigare steg i modellen. Boehms spiralmodell skiljer sig genom att inte ha några klara faser. Utvecklingen sker istället cykliskt efter mönstret riskanalys, prototyp, test, utvärdering, varefter processen startar om på med en ny riskanalys, prototyp etc.

LAS använde sig av en utvecklingsprocess som i stort sett följer vattenfallsmodellen. Notabelt är att någon riskanalys aldrig förekom. Vi kommer i det följande att beskriva hur LAS arbetade med de olika stegen i vattenfallsmodellen.

Kravspecifikation och upphandling

Händelseförlopp, specifikation

Arbetet med kravspecifikationen startade hösten 1990. En projektgrupp sattes samman. Gruppens medlemmar hade olika bakgrund, men de flesta hade någon form av chefsposition. Ingen ambulanspersonal deltog i projektgruppen.

Målet var att skapa ett system som, så långt det är möjligt, helt automatiskt kan välja vilken ambulans som skall skickas till en olycka. Endast i mycket komplexa situationer skulle det vara nödvändigt att dirigera ambulanserna manuellt. Det stod snabbt klart att det sökta systemet skulle bli mycket avancerat, ett så heltäckande system saknade motsvarighet. Några existerande system utvärderades, men de bedömdes alla som otillräckliga.

Det råder inget tvivel om att systemspecifikationen var mycket detaljerad. Specifikationen lämnade ringa eller inget utrymme för systemleverantören att själv utforma lösningar eller komma med förslag. Några år tidigare hade LAS gjort ett misslyckat försök att införa ett mindre avancerat system. Försöket avbröts eftersom leverantörerna hade för stora problem att uppfylla kraven. Den nya specifikationen var långt mer krävande, vilket projektgruppen var medveten om.

En av förutsättningarna för att systemet skulle fungera var att samtliga berörda kände fullt förtroende för dess funktion. Försök att manuellt korrigera datorns förslag om t ex val av ambulans skulle bara försämra systemets prestanda. Systemet förutsatte också att den användes på ett korrekt sätt. Om fel knappar trycktes in eller om ambulansförarna angav fel status, så skulle det kunna leda till fullständigt kaos.

Kvalitet och tillförlitlighet hos kommunikationen mellan sambandscentralen och bilarna var grundläggande för systemets funktion. Det gällde såväl röst- som datorkommunikation. Förseningar eller avbrott i kommunikationen skulle leda till oreda.

Givet att ovanstående förutsättningar uppfylldes, så skulle systemet fungera utmärkt och bli en succé. Tyvärr insåg emellertid inte projektgruppen vidden av de problem som skulle uppstå om någon av förutsättningarna inte kunde uppfyllas.

Händelseförlopp, upphandling

En särskild grupp bildades för att ta hand om upphandlingen av det nu specificerade systemet. De existerande riktlinjerna (RHA Standing Financial Instructions) för upphandling gav litet stöd för ett sådant mjukvaruprojekt som var aktuellt. Framför allt fokuserade riktlinjerna på att erhålla lägsta pris. Kvalitet kom i andra rummet.

Från början visade 35 leverantörer intresse av den offertförfrågan som LAS skickade ut. Av dessa gick 17 vidare och lämnade in fullständiga offerter. Dessa offerter utvärderas efter en modell där tidsaspekten hade stor betydelse. Flera leverantörer menade att det var orimligt att utveckla ett så avancerat system inom den snäva tidsram som LAS hade angivit. Det visade sig att endast en enda av offerterna uppfyllde LAS krav på utvecklingstid och kostnad. Denna offert kom från ett konsortium bestående av de tre företagen Apricot, SO (System Options) och Datatrak.

Ytterligare några leverantörer sade sig kunna uppfylla tidsmålet, men till en avsevärt högre kostnad. Apricot-gruppens bud var 40 procent lägre än närmaste konkurrent. Inte vid något tillfälle under upphandlingen tycks LAS ha funderat över hur Apricot-gruppen kunde vara så mycket billigare. Inte heller granskade LAS rimligheten i gruppens tidsuppskattning.

Svagheter i specifikation och upphandling, samt åtgärder som skulle kunna förbättrat utfallet

Sommerville [1996] ägnar drygt 140 sidor åt att beskriva hur ett system ska specificeras. Inledningsvis kan konstateras att denna beskrivning är ganska annorlunda mot vad som tillämpades av LAS.

Till att börja med skiljer Sommerville på kravdefinition och kravspecifikation. Definitionen är ett mera översiktligt dokument, som senare kompletteras med en specifikation. Inte bara beställaren, utan även leverantören, behöver medverka för att kunna skriva en bra specifikation.

I det ovan beskrivna händelseförloppet framgår att endast en typ av kravdokument användes. Leverantören medverkade inte alls i utformningen av detta dokument. En åtgärd som borde ha vidtagits var att skriva specifikationen tillsammans med leverantören.

Sommerville påtalar vidare att representanter för alla delar av organisationen måste medverka vid kravspecifikationen. Så skedde inte vid LAS, där exempelvis ambulansförarna inte var involverade. Sommerville nämner att olika perspektiv (viewpoints) kan användas i kravdokumentationen för att hjälpa olika läsare att förstå beskrivningen. Förutom av rent tekniska skäl är det viktigt med en bred medverkan av sociala skäl. När arbetssättet inom en organisation ska förändras, krävs att alla medarbetare ställer upp bakom förändringen. Vårt åtgärdsförslag är att involvera personer med olika bakgrund i kravarbetet.

För att bättre förstå hur verksamheten fungerar och vilka informationsbehov som finns, rekommenderar Sommerville att systemmodeller används. Det är lite oklart huruvida detta utförts av LAS. Oavsett vilket, tror vi inte att detta är en kritisk faktor för misslyckandet eftersom LAS trots allt verkade ha god insikt om vilka informationsbehoven var. Samma sak gäller metoderna prototyping och formell specifikation som också nämns av Sommerville.

Ett påtagligt misstag har LAS gjort inom vad som kallas icke-funktionella krav. Till dessa krav hör bl a kvalitet, robusthet, prestanda och användarvänlighet. Det specificerade systemet var raka motsatsen till robust det betraktas som acceptabelt att systemet inte skulle fungera utan korrekta och heltäckande indata. När systemet senare togs i drift visade sig detta bli ett av huvudproblemen, liksom att systemet hade otillräcklig prestanda för att fungera under arbetstoppar. Vårt förslag på åtgärd är att bättre undersöka de icke-funktionella kraven, gärna i samarbete med en teknisk specialist.

Programmering

Programmering utgör en del av systemutvecklingen. Själva programmeringen är av olika stor betydelse i olika system. Om ett standardprogram köps in kan programmeringen vara helt obefintlig och istället blir valet av hårdvara avgörande. I det aktuella fallet med LAS handlar det om nyutveckling av ett tidskritiskt system, varför programmeringen var av särskilt stor vikt. Det var företaget SO som ansvarade för större delen av programmeringen.

Val av språk

SO har skrivit hela programmet i Visual Basic, som vid den aktuella tiden var ett ganska nytt och obeprövat språk. Det är avsett för snabb programutveckling, snarare än utveckling av snabba program. SO har i efterhand själva medgivit att programmet antagligen skulle kunna effektiviseras, t ex genom att skriva om vissa moduler i C++.

Sommerville ägnar ett kapitel åt att beskriver design av realtidssystem. Viktiga punkter är arkitekturen hos systemet, tillståndsmodellering och att identifiera stimuli med tillhörande respons. LAS hade inget inflytande över hur SO valde att skriva systemet. En åtgärd som vi föreslår är att LAS hade ställt högre krav på att SO använde en beprövad och dokumenterad metod under utvecklingen. Åtgärden är rimlig, i synnerhet med tanke på de uppgifter som systemet var tänkt att stödja.

Kvalitet

SO hade endast en deltidstjänst för kvalitetssäkring. Denna person var inte oberoende och hade heller inte några nämnvärda befogenheter. I kvalitetssystemet ingick PIR (Project Issue Reports) för att kontrollera och administrera hanteringen av uppkomna fel. SO ignorerade i många fall detta och gjorde ändringar av mjukvaran ''on the fly'' vilket gjorde att redan genomförda tester inte längre var sanningsenliga och att nya buggar introducerades.

ISL, en konsultfirma som inte var engagerad i projektet, förslog för LAS att de kunde ta på sig ansvaret för kvalitetssäkring. LAS ansåg inte att det fanns fog för den utgiften. ISL fick faktiskt inte ens ett svar från LAS på sitt förslag.

Kvalitetstyrning syftar, enligt Sommerville, till att ha ett lågt antal fel, god dokumentation och ''best practice'', d v s arbeta på ett sätt som branschens bästa företag gör. Vad beträffar kvalitet, uppvisar SO klara brister på gränsen till direkt dumhet. Vi menar dock att ansvaret inte ligger enbart hos SO, utan även LAS skulle i kraft av att vara beställare ha ställt avsevärt högre krav. Som nu var fallet, ställdes egentligen inga kvalitetskrav alls.

Systemtest och Införande

Genomförande av tester

Händelseförlopp

Tester av projektet genomfördes kontinuerligt och i januari 1992 genomfördes de första testerna för att undersöka såväl funktionalitet som kapacitet. Dessa tester var dock ofullständiga, dels på grund av att alla komponenter i systemet inte var färdiga, dels så simulerades aldrig ett realistiskt indataflöde. Med realistiskt indataflöde avser vi brist på fullständig information och även motstridig information, till exempel för ambulansernas positioner.

Ur rapporten framgår det inte exakt vad som testades och hur det i så fall testades, men det förefaller sannolikt att de enda tester som genomfördes var, med Sommervilles terminologi, unit-testing, module testing och sub-system testing. Att systems testing aldrig blev genomförd innan införandet beror till stor del på att systemet installerades ''bit för bit'' under 1992. Det gavs helt enkelt aldrig utrymme för att testa hur (om!) de olika delsystemen fungerade tillsammans.

Hur testningen borde ha skett

Det är naturligtvis självklart att ett realtidssystem måste testas innan det införs. Att inte ens genomföra tester av det sammansatta systemet på simulerad data är minst sagt märkligt. Genom att genomföra systems testing upptäcks fel som uppkommer på grund av oförutsedda effekter av interaktionen mellan de olika systemkomponenterna. Efter systems testing är genomförd skall även acceptance testing genomföras. Acceptanstester skall genomföras på verklig indata, dels för att verkligheten inte alltid är som beräknats och dels för att avgöra huruvida systemet verkligen lever upp till prestandakraven.

Hela testprocessen verkar ha fallerat i projektet. Ett rimligt krav är att samtliga olika teststeg skall genomföras. Om dessa teststeg hade genomförts hade förvisso installationen fördröjts, på grund av att systemet helt klart inte levde upp till varken de funktionella eller icke-funktionella kraven. Vi menar emellertid att denna fördröjning inte vore något allvarligare problem än vad som faktiskt uppstod: att systemet installerades för att efter installationen visa sig inte leva upp till de specificerade / faktiska kraven.

Införandet av systemet

Händelseförlopp

Införandet av CAD var beslutat att ske i ett enda steg 1992-02-08. Detta kunde dock inte genomföras, på grund av att systemet helt enkelt inte var färdigt. Istället så infördes systemet bit för bit i tre faser under 1992:

Under införandefasen så framkom det hela tiden problem med systemet. Ambulanspersonalen rapporterade inte in sin status korrekt, dels beroende på bristande utbildning, dels på att kommunikationssystemet inte fungerade helt och fullt. Det automatiska lokaliseringssystemet Datatrak var inte exakt, dels beroende på handhavandefel, men även på grund av kommunikationsproblem och direkta fel i mjukvaran. Systemet var svårt att anpassa till verkligheten och hade inget stöd för manuella korrigeringar av systemets förslag, istället gavs ett flertal felmeddelanden som blev omständliga att hantera. Kommunikationskanalerna var överbelastade, vilket resulterade i försämrad prestanda i systemet och inaktuella uppdateringar etc. Hårdvaran ''låste sig'' och kändes ''seg''. Mjukvaran för tilldelning av resurser fungerade inte alltid som avsett, vilket innebar att det inte alltid var den närmaste ambulansen som pekades ut av systemet.

Dessa problem åtgärdades aldrig utan införandet fortskred trots detta. Värt att notera är att av de tester som genomfördes så framkom det att det fanns kvar två stycken kategori 2 PIR:er 1992-10-26. PIR kategori 2 innebär en ''allvarlig systemförsämring, systemet fungerar ej korrekt förrän problemet är åtgärdat''.

Hur införandet av systemet borde ha skett

När det stod klart att ''deadlinen'' 1992-02-08 aldrig skulle vara möjlig att hålla skulle en mer realistisk tidsplan ha gjorts upp direkt. Som det blev så var det stegvisa införandet av systemet en ''panikhandling'' för att rädda det som räddas kunde. Uppdelningen i de tre olika faserna var i och för sig rimlig, men under perioden som systemet var delvis infört så var det aldrig helt stabilt. Alla delar genomgick konstanta förändringar. En förutsättning för att gå vidare till den efterföljande fasen är att de redan införda delarna är fullständigt testade och har visat sig tillförlitliga. Detsamma gäller delarna som skall införas i det kommande steget: testa innan installation. Att trots kvarstående kategori 2 PIR:er driftsätta systemet är oförsvarligt.

Vid införsel av ett nytt system är det av vikt att personalen som handhar systemet både kan hantera det och har förtroende för det. Den improviserade installationen av systemet omöjliggjorde att utbildning av personal genomfördes i tillräcklig omfattning. Dessutom så bedrevs utbildningen långt innan systemet driftsattes, vilket åstadkom att mycket av utbildningen glömdes bort innan personalen fick möjlighet att använda systemet.

Bristande information om systemet som helhet gjorde att personalen på sambandscentralen inte förstod ambulansförarnas situation och vice versa. I samband med införandet av systemet borde omfattande utbildning ha genomförts, dels för att personalen skulle kunna handha sin egen utrustning korrekt, men även för att de skulle få en modell av systemet som helhet och på så sätt kunde förstå andras situation och hur de är beroende av att det egna arbetet för att verksamheten skall fungera. Sommerville påtalar vikten av sociala faktorer i sin beskrivning av systemutveckling.

Drift och underhåll

Systemet driftsattes i sin helhet (fas 3) kl 07.00 1992-10-26. Under låg belastning fungerade systemet hyfsat, personalen hade möjlighet att ta hand om de felmeddelanden som generades på grund av felaktig information angående ambulansernas positioner och status. Under dagen, då belastningen var på en normal nivå hade personalen ingen möjlighet att ta hand om alla felmeddelanden. Detta resulterade i att systemet överbelastades av felmeddelanden, som personalen inte hann ta hand om vilket i sin tur generade nya felmeddelanden. Detta upprepades dagen därpå och därefter återgick men till det halvmanuella systemet (fas 2).

Denna halvmanuella metod fungerade fram till 1992-11-04, då systemet låste sig helt och hållet tidigt på morgonen. Försök gjordes att starta om systemet, men det hade ingen effekt. Systemet övergavs helt och hållet och man återgick till de helt manuella rutinerna med papper, penna och muntlig kommunikation via radio eller telefon.

Detta totala haveri berodde på att en programmerare av misstag glömt att frigöra minne som en procedur använde sig av. Detta slarvfel hade kunnat undvikas om ordentliga tester hade genomförts. Slarvfel uppstår när kvalitetsstyrningen är otillräcklig. Som vi tidigare skrivit föreslår vi att LAS skulle ha ställt betydligt högre kvalitetskrav på programmeringsarbetet.

Projektledning och ansvarsfördelning

Avsikten med att SO gjordes till huvudleverantör var att SO skulle ha det övergripande projektledningsansvaret. Det finns dock inget skriftligt avtal om detta. Från leverantörernas sida var uppfattningen att det var LAS som var projektledare.

Den projektmetodik som valdes kallas för PRINCE (Project In Controlled Environment). Det fanns dock ingen erfarenhet av PRINCE, varken från LAS:s sida eller från SO:s.

Under ett möte 1991-06-17 uppkom ett antal problem med projektstyrningen. Bland annat att LAS inte hade en enda person som arbetade på heltid med projektet och att ingen visste hur PRINCE skulle tillämpas i praktiken. Andra problem som framkom var att det inte fanns något schema för möten inom projektgruppen och att sex månader för införandet av systemet var ungefär en tredjedel så lång tid som andra projekt av den här storleksordningen tog i anspråk. Dessutom noterades att det inte fanns något som helst utrymme för utvärderingar och att revidera tidsplanerna. Trots att detta diskuterades så vidtogs aldrig några åtgärder.

Det råder inget tvivel om att en kompetent projektledare skulle ha kunnat råda bot på flera av projektets brister. Bara en sådan fundamental sak som att reda ut vem som var ansvarig för vad skulle ha hjälpt avsevärt. Som det nu blev så fick SO rollen som projektledare, vilket var felaktigt av flera orsaker. SO hade ingen erfarenhet av projekt av den här storleken och inte heller av PRINCE-metodiken. Dessutom var det en egendomlig sits för SO att både vara leverantör av ett delsystem samt att vara projektledare för de andra leverantörerna.

Deadlines

Fram till och med början av december 1991 trodde man att 1992-02-08 som ''deadline'' för införandet av hela systemet skulle vara möjlig att hålla. Det måste anses som egendomligt, att man två månader innan ''deadline'' fortfarande trodde att det skulle vara möjligt att införa systemet trots att CAD mjukvaran inte var färdig, all hård- och mjukvara inte var levererad och Datatrak-utrustningen var varken komplett eller tillräckligt exakt.

En ''deadline'' är viktig, saker och ting får inte tillåtas dra ut på tiden hur som helst. Det är dock ingen mening med att låtsas kunna leva upp till en ''deadline'' trots att det står klart att man inte kommer att vara färdig i tid. Som det utvecklades inom projektet så blev satta ''deadlines'' absoluta och inte föremål för ifrågasättande. Det fanns till och med rädsla för att om ''deadline'' ifrågasattes så kunde det innebära att man fick förflyttning eller även blev av med sitt jobb! Detta är naturligtvis helt oacceptabelt, en redan från början snävt tilltagen ''deadline'' måste kunna anpassas efter verkligheten, det diktatoriska följandet av den initiala tidsplanen ledde bara till att problemen lades på hög istället för att lösas.