Отсутствие единой методологии интеграции поставок ставит под угрозу успех IT-проектов

Den glemte metodologi der kunne have reddet dit projekt Tilbuddet er vundet. Kontrakten underskrevet. Scope, pris og tidsplan ligger fast. Så møder leveranceteamet ind: "Hvor er datamigrering, testmiljøer, security og business readiness estimeret?" Kort pause. "Det håndterer vi i projektet." Oversættelse: Det var ikke med i estimatet. Og projektet er bagud, før det reelt er begyndt. Det er ikke fordi folk er inkompetente. Det er fordi der mangler én ting: en fælles metode, der forbinder tilbud, levering og drift. Vi er blevet gode til projektstyring med PRINCE2. Gode til iterativ udvikling med Scrum. Gode til organisatorisk forandring med ADKAR. Men vi er blevet dårligere til at linke det hele sammen. Integrated Delivery Methods - kort version En Integrated Delivery Method (IDM) er en fælles end-to-end leverancemodel for hele transformationen - fra tilbud til go-live og drift. Ikke bare en projektplan. Og ikke en vandfaldsmodel forklædt som en mappe med 600 templates. En god IDM beskriver: - Hvad der skal leveres - hele vejen fra estimering til gevinstrealisering - Hvordan processer, konfiguration, data, test, change og drift hænger sammen - Hvilke afhængigheder der skal håndteres - Hvad der skal overdrages, når et nyt team overtager Det sidste punkt er det vigtigste. Og det mest oversete. Problemet ligger mellem faserne Tilbudsteamet er sjældent det samme som leveranceteamet. Og leveranceteamet er sjældent det samme som dem, der senere skal drive løsningen. Hver overgang er et sted, hvor viden, antagelser og leverancer falder mellem stolene. Tilbudsteamet estimerer det, de kan se: konfiguration, integrationer, projektledelse. Det ser fornuftigt ud. Prisen er konkurrencedygtig. Men datamigrering er kun delvist med. Testmiljøer er en forudsætning, ingen aktivitet. Security "forventes håndteret af kunden". Business readiness tager "organisationen selv". Så starter projektet - og arbejdet dukker op alligevel. For arbejdet forsvinder ikke, bare fordi det ikke stod i estimatet. Det kommer tilbage som forsinkelse, ekstra bemanding, rework eller change requests. Nogle gange alle fire. En IDM løser ikke alt. Men den tvinger tilbud og projekt til at se transformationen som én samlet leverance - på tværs af faserne. Hvor forsvandt metoderne hen? I 80'erne og 90'erne havde alle store konsulenthuse deres egen IDM: Accenture's METHOD/1, Oracle AIM, IBM Catalyst. Det var det, konsulenterne blev uddannet i. Så gik uddannelsen mod generisk projektledelse. Specialiserede frameworks voksede frem. Og projekterne begyndte at kombinere kundens governance, leverandørens templates og projektlederens personlige erfaring. Bring Your Own Method. BYOM. Det kan fungere fint - hvis de rigtige erfarne folk er til stede fra starten. Men det bliver personafhængigt. Og når erfaringen ikke er der, skal projektet opfinde sin leverancemodel efter kontrakten er underskrevet. Det er et dyrt tidspunkt at begynde. Henrik Rasmussen har udgivet en analyse, der undersøger netop denne udvikling. Hans survey peger samme vej: Systematisk brug og overførsel af IDM-kompetencer er svækket - og det har sænket leverancesikkerheden. Skal vi så tilbage til 1998? Nej. Vi skal ikke genoplive en gammel metodebog og følge den side for side. Cloud, agile, standardplatforme og AI har ændret hvordan vi leverer. Men de har ikke fjernet behovet for at forstå det fulde scope. Og de har ikke fjernet afhængighederne mellem faserne. En IDM fra 2001 virker faktisk stadig - fordi strukturen "analyse → design → build → test → go-live" er uændret. Det, der skifter, er omfanget: "Etabler infrastruktur" var 8 uger on-prem, nu er det en uge i cloud. Aktiviteten er den samme. Strukturen holder. En moderne IDM skal bare tilpasses den konkrete kunde og det konkrete scope. Og her kan AI faktisk hjælpe - med at samle aktiviteter, roller, afhængigheder og templates til en kundespecifik model. Men mennesker skal stadig validere den og sikre, at den bruges. Hvad betyder det for dig? Køber du en transformation? - Spørg ikke kun, hvilke frameworks leverandøren bruger - bed om den samlede end-to-end model - Bed dem vise afhængighederne, og hvordan metoden følger projektet fra tilbud til drift - Kan det ikke forklares før kontrakten, er det et warning sign Leverer du en transformation? - Du behøver ikke opfinde en ny IDM - du skal tilpasse en integreret model til kunden - Brug den allerede i tilbuddet, ikke først når projektet er i gang - Sørg for, at leveranceteamet overtager samme scope og antagelser som tilbudsteamet Det er ikke særligt moderne. Det er bare ret effektivt. DA Network er en gruppe af erfarne senior projektledere og konsulenter, der lever og ånder end-to-end delivery. Skal I sikre en ordentlig IDM - i tilbud eller levering - så er det værd at tage en snak. [Link til LinkedIn artikel] | [Link til Henriks fulde analyse] ...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2. Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv. Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger. Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.