Hårt styrda projekt
I gårdagens ComputerSweden fanns en insändare skriven av en Kurt Fredriksson, med titeln “Hårt styrda projekt lyckas”. Den kommenterar en artikel från CS 17/12 om ett stort Cobolprojekt som avslutats på tid.
Här har vi ett projekt som hållit både tids- och kostnadsramarna. Vad ligger bakom succen?
Det är inget hackande i något “modernt” modespråk utan skrivet i Cobol. De har inte använt någon modern systemutvecklingsmetod. De har använt den ingenjörsmässiga metoden att först bestämma vad som ska göras och sedan hållt sig till detta. De har inte tillåtit att nya funktioner, “bra-att-ha”, lagts till.
Kort sagt, de har fryst en kravspecifikation och sedan hållt sig till den. De har hållit stenhård kontroll på tidplan och kostnader.
Det finns inga genvägar till ett bra resultat.
Projektet i fråga var enligt artikeln ett som pågått sedan januari 2002 för Värdepapperscentralens räkning och engagerat cirka 50 personer i projektgruppen och drygt tusen personer i det 50-tal banker och finansföretag som varit inblandade.
CS intervjuar IT-projektledaren som säger att de lyckats “genom att detaljstyra ekonomi och tidsplaner veckovis”. Därför har avvikelser snabbt upptäckts och kunnat hanteras. Som Fredriksson skriver i sin insändare har de varit restriktiva till tillägg. Förslag på sådana har ifrågasatts om huruvida de verkligen hör till projektet.
Som jag misstänkte så har arbetet med att ta fram kravspecifikationen krävt lång tid. Hela första året gick åt till detta. Deras uppskattningar verkar ha stämt ganska bra: de slutförde arbetet i november 2003 som beräknat och att budgeten överskreds med hela 25 procent ser de inte som att de spräckt ramarna.
Detta kanske har varit ett projekt som lämpar sig för “den ingenjörsmässiga metoden”, där man kan ta fram en kravspecifikation för att sedan frysa den. Jag skulle vilja veta mer precist hur arbetet med specifikationen gått till: har de behövt göra prototyper av något slag? Har de behövt få återkoppling från slutanvändare?
Artikeln säger inget mer om vad systemet gör än att det “hanterar avvecklingsrutiner på den svenska aktie- och penningmarknaden”. Det är säkert så att det är ett snårigt område, men det borde ha varit förhållandevis väl kartlagt av t.ex. Finansinspektionen. Jag tror inte det är ett vågat antagande att gissa att förarbetet varit i huvudsak mekaniskt; säkerligen ett imponerande utredningsarbete, men ett som bestått i att läsa och rådfråga experter snarare än att formulera hypoteser om slutanvändarna och deras behov eller uppfinna nya lösningar.
En stor del av den utveckling som bedrivs idag är just detta. Det liknar mer produktutveckling och uppfinnande än omformulerande av redan kända regler i programkod. Det handlar om upptäckande och inte bara inlärning. Då blir genvägen antingen en senväg, om man inte håller hårt på sig utan villigt accepterar tillägg eller förändringar som grundar sig på nya upptäckter. Då har man under projektets gång fått erfara att det tar längre tid att frysa vad som bara är spekulationer. Eller så leder “genvägen”, förvisso i tid och utan att spräcka budgetramarna, till något som slutanvändarna inte vill ha. Då är den enda trösten att man i alla fall varit ingenjörsmässig.