Noll projektmisslyckanden sedan 2007 — de tekniska reglerna bakom det
Jag grundade Software Tailor 2006. Nitton år senare har företaget levererat genom fyra distinkta ekonomiska cykler, sex Fortune Global 500-kunder inom läkemedel, finans, offentlig sektor, juridik, försvar och energi, och noll projektmisslyckanden sedan 2007. Den sista siffran är den som investerare och inköpsgranskare frågar om oftast, och det är den enda som behöver förklaras. Här är de fyra tekniska reglerna som bär upp rekordet.
Regel 1: En leveransmodell, ingen oklarhet mellan tjänst och produkt
Varje Software Tailor-uppdrag körs på samma leveransmodell — en snävt avgränsad pilotfas som levererar fungerande programvara, följt av en utbyggnad som kunden väljer att finansiera (eller inte) på basis av vad som levererades. Vi driver inte en separat ”tjänste”-praktik som levererar mot kravdokument och en separat ”produkt”-praktik som levererar mot färdplaner. De två skulle krocka; den ena skulle alltid korssubventionera den andra.
Den enda modellen innebär att varje ingenjör vet hur ”klart” ser ut innan de börjar. Det är förutsättningen för att inte misslyckas.
Regel 2: Disciplin i kundkohorten — bara kunder vi kan leverera till
Vår kundkohort väljs ut — inte opportunistiskt. Sex Fortune Global 500-kunder på 19 år är ingen långsam säljpipeline; det är en medveten urvalsribba. Varje kund vi tar oss an måste passera tre test före kickoff: deras problem är ett vi har löst tidigare, deras interna sponsor är den person som kommer att använda programvaran (inte ett lager av mellanhänder), och deras hård- och datamiljö låter oss leverera utan en sex månader lång upphandlingsomväg.
En kund som faller på något av dessa test blir en hänvisning till någon annan, inte ett projekt. Det är regeln som kostar oss intäkter oftast. Det är också den som har noll undantag under 19 år.
Regel 3: Teknisk disciplin avbildad mot ett erkänt ramverk
Långt innan AI-riskhantering hade sitt eget ramverk mönstermatchade de tekniska regler jag kodifierade för Software Tailor samma form: styr arbetet, kartlägg riskerna, mät utfallen, hantera ändringarna. NIST AI RMF 1.0 [1] formaliserade det mönstret för AI 2023, och profilen för kritisk infrastruktur i april 2026 [1] utvidgade den till reglerade branscher. När jag läser dessa dokument avbildas vår interna disciplin rent mot de fyra funktionerna.
Det det ger oss: varje projekt är granskningsbart från början till slut mot ett externt ramverk, inte bara mot våra egna vanor. När ett inköpsteam frågar hur pilotfasens omfattning bestäms är svaret detsamma svar som NIST skulle ge för riskhantering — och kundens egen compliance-organisation har redan internaliserat den vokabulären.
Regel 4: Inspelningsbart, återställningsbart, återskapbart
Den fjärde regeln föregår granskningsspårsvokabulären vi nu använder för AI Suite. Varje Software Tailor-uppdrag körs i ett tillstånd där varje beslut, varje artefakt, varje version av koden kan återskapas från versionshanterade indata. Det är inte ovanligt för programvaruteknik generellt; det som är ovanligt är att vi tillämpar det på projektet, inte bara på kodbasen. Sprintbeslut, omfattningsändringar, kundgodkännanden — allt inspelat, allt återställningsbart.
Disciplinen är orsaken till att vår metod med innehållsfria granskningsloggar för AI Suite levererades så som den gjorde. Granskningsradsmönstret är samma mönster som vi redan tillämpade på projekt. Vokabulären är lånad från efterlevnadsramverk; praktiken är lånad från hur vi levererar.
Vad som följde med till AI Suite
Local AI Suite + AI Admin Console-linjen — se Varför vi levererar AI som installerbara binärer, inte moln-SaaS — är samma ingenjörsdisciplin tillämpad på en produktlinje i stället för ett skräddarsytt uppdrag. Samma enda leveransmodell (skrivbordsinstallerare som kunden kör i sin egen miljö), samma kundkohortdisciplin (reglerade branscher med tydliga dataresidenskrav), samma ramverksmappning (NIST AI RMF + skyldigheter för driftansvariga enligt EU AI Act), samma inspelningsbar-återställningsbar-återskapbar granskningshållning.
Noll projektmisslyckanden sedan 2007 är ingen slogan. Det är resultatet av ett litet antal regler som tillämpas utan undantag. Samma regler styr nu hur AI Suite byggs.
Referenser
- NIST. ”AI Risk Management Framework (AI RMF 1.0).” nist.gov/itl/ai-risk-management-framework. Hämtad 2026-07-15.
Relaterade artiklar
Testa samma disciplin på en verklig arbetsbelastning.
On-premises AI-plattformen är byggd på samma regler som skapade meritlistan — inspelningsbar, återställningsbar, återskapbar, tillämpad utan undantag. Distribuera den mot en verklig arbetsbelastning i din egen miljö och håll den till samma standard.