Hva kan læres fra Indiana's $ 1,4 milliarder mislyktes outsourcing kontrakt
Saksstudien om en feilbrudd kan hjelpe oss med å svare på spørsmål om metallmasse, dårlig produserte deler, inspeksjonsovervåkninger, ledetråder som kan ha blitt oversett eller avvist, vindkraft og uprøvde materialer som brukes til å bygge broen. Suksessen kan bare fortelle oss at vi ikke svikte. Feil, når vi studerer nøye, forteller oss hva som gikk galt.
En titt på den største outsourcingfeilen
I lys av det økende antall outsourcingavgjørelser som organisasjoner av varierende størrelser gjør, er casestudier om outsourcingfeil også nyttige når man lærer hva de skal gjøre og hva de ikke skal gjøre. Dataene fra mislykkede outsourcingeksperimenter finnes i vårt rettssystem, hvor tidligere forretningspartnere argumenterer over hvem som var skyld i feilen. Et utmerket eksempel på dette er kontrakten på 1,4 milliarder dollar mellom staten Indiana og IBM.
Indiana ønsket å outsource sine velferdsbehandlingssystemer, og domstolsrekordet er i hovedsak casestudien som skal lære om Indianas missteg.
I dette tilfellet kjenner vi detaljene fordi klienten og selgeren valgte å saksøke hverandre, og detaljene i deres uenighet er nå i offentlig rekord. I ordene til presiderende dommer David Dreyer, "Ingen av partiene fortjener å vinne denne saken. Denne historien representerer en" perfekt storm "av misguided regjeringens politikk og overdreven bedriftens ambisjon.
Samlet sett er begge parter skyldige, og Indianas skattebetalere er igjen som tilsynelatende tapere. "
8 leksjoner for å unngå outsourcingfeil
Det er mange leksjoner å lære, men her er de øverste åtte leksjonene om outsourcing som skal læres fra delstaten Indiana og IBMs kontrakt.
Endring krever engasjement
Denne kontrakten var å forvandle "nasjonens verste velferdssystem, (tilsynelatende rife med kriminalsvikt, voldsom inkompetanse, favoritisme, etc.)." Også, Indiana, forsøkte å introdusere en ny tjenesteleveringsmodell som ville redusere kostnadene og fikse tiår med føderale regelbrudd. Å oppnå noen av disse målene ville ha vært bemerkelsesverdig. Å oppnå dem alle ville være uten sidestykke. Men for å oppnå alle målene krever klienten (delstaten Indiana) å gi selgeren (IBM) sin absolutte og ubetingede støtte. I stedet viser retten at statsrepresentanter med vilje undergravd programmet (og brutt kontrakten) ved å forstyrre IBMs ledelse av (politisk tilknyttede) underleverandører. Endringsledelse er vellykket bare hvis organisasjonen støtter endring, og i dette tilfellet gjorde ikke Indiana det.
Lær av andre eksempler
Som en del av forberedelsene til Indiana-IBM-kontrakten ble lignende programmer i Texas og Florida undersøkt.
Disse programmene mislyktes (eller mislyktes), på samme måte som Indianas slutt ville. Problemene i Texas var så alvorlige at "utrullingen av prosjektet ble stoppet." IBM bestemte seg for at disse problemene ikke gjaldt dem, eller at de kunne klare problemene. IBM er utvilsomt et flott selskap, men hva denne kontrakten trengte var mer enn IBM kunne tilby. Mega-kontrakter blinde leverandører til feil og grenser; Klienten må se fysisk bevis på at risikoen er tilstrekkelig redusert.
Mega Kontrakter = Mega Risk
En enkelt stor kontrakt er mer risikofylt enn flere mindre kontrakter. Du kan velge å ta risikoen fordi en enkelt stor kontrakt kan koste mindre for å håndtere om den lykkes. Hvis ikke, er en mislykket stor kontrakt imidlertid svært kostbar. De mulige fordelene med lavere administrasjonskostnader kan sammenlignes med økte risikoer for svikt, og kostnaden for risikoreduksjon kan også innregnes i.
Domstolsopptegnelser viser partenes bekreftelse på enkelte risikoer, men det er ingen bevis på at klienten eller leverandøren noen gang har gjort matematikken og beregnet kostnadene. Størrelse alene er en faktor for feil, men størrelsen har en tendens til å ha medfaktorer (som denne kontrakten gjorde) som førte til svikt. Kontrakter med potensielt høy risiko krever en grundig risikoanalyse og begrensning.
Endre skjer
Mange outsourcingkontrakter er utformet for å drive endring. Men outsourcing kontrakter som skal kjøre endring - men ikke la selgeren gjøre endringer - har en tendens til å mislykkes. I dette tilfellet kontrollerte kunden tett styringsmekanismen og godkjente ikke de fleste leverandør-forespurte endringer. Betingelsene for programmet endret, for eksempel tillegg av nye programmer og utvidet arbeidsmengde. Selv for klientinitiative endringer og utvidelser tillot de ikke selgeren å legge til ansatte (og kostnader) eller gjøre andre endringer.
Dette var en 10-årig kontrakt. I løpet av et tiår vil ting endres på uventede måter. For eksempel doblet den økonomiske nedgangen i omfanget av forespørsler om velferdsstøtte. Bare si, "vi ønsker ikke endringer" er ikke en forandringsstyringsplan; Hvis du vil ha et vellykket program, trenger du en rimelig mekanisme for å godkjenne og implementere endring.
Tvister fører til søksmål
Søksmål er tidkrevende og kostbart, men hvis ingen av partene i en tvist er villig til å utarbeide problemene, blir du ledet til retten. En mindre leverandør kan nøl med å saksøke regjeringen, eller kanskje gi inn når truet med et søksmål, men store leverandører som IBM har like store juridiske avdelinger (en annen risiko for megakontrakter). Alle har tvister, men når kommunikasjonen stopper, er andre veier for oppløsning avsluttet, og begge parter begynner å tenke på søksmål. En gammel prosjekthåndteringsregel er: "Å avgjøre en tvist i retten er den mest kostbare og minst effektive løsningen." Når kommunikasjonen begynner å lukke, gjør alt for å holde kommunikasjonskanaler åpne. Gjør kompromisser og være oppfinnsom nå fordi en rettsbestemt løsning vil bli dyrere.
Være konsekvent
I de tre første årene bestemte Indiana-tjenestemenn gjentatte ganger om at programmet hadde lykkes, og (ifølge kontrakten) fortalte IBM å gå videre til neste fase i programmet. Når staten Indiana saksøkte IBM, sa de at programmet hadde mislyktes og hadde vært i feil i årevis. Denne typen inkonsekvens undergraver troverdigheten alvorlig - inne i rettssalen og i næringslivet. Du har rett (og plikt) til å endre posisjonen din når nye bevis blir tilgjengelige, men hvis du legger til ikke-støttede embellishments, vil du gjøre mer for å undergrave troverdigheten din for å støtte argumentet ditt.
" Perfekt utførelse" finnes ikke
Klienter bygger ofte massive kontrakter som forsikring om at leverandører vil forstå hva de vil og utføre kontrakten feilfritt. I virkeligheten er forutsetninger feil, forholdene endres, og målpostene beveger seg. Likevel vil både kunden og selgeren velge de individuelle klausulene som støtter sin posisjon. Domene tar en annen posisjon. En dommer er ikke interessert i å definere perfektion; dommere er interessert i å definere hva som er rimelig. Med mindre en part eller den andre var helt inkompetent eller ondsinnet, vil en dommer søke et kompromissspørsmål som ikke vil gjøre hver av partiene helt fornøyd. Å gå til domstol øker ikke kontrollen din, men det reduserer kontrollen til begge parter kraftig.
Begge sidene kan miste
Det er kulminasjonen av alle de andre outsourcing leksjonene og kanskje det viktigste. Som dommeren satte det, tapte alle tre partiene: staten Indiana, IBM og statens skattebetalere. Hvert av problemene var unødvendig, men hvert problem førte til neste til hendelsekjeden var for sterk til å bryte. Hver person som noen gang endte opp i retten spør seg selv: "Når gikk dette galt?" Og svaret er alltid, "lenge før søksmålet begynte." Vanskelige problemer kan løses, men ikke uten innsats og planlegging. Problemer må identifiseres og løses når klienten og leverandøren begynner å forfølge en annen agenda; hvis du venter for lenge, vil momentet i hendelsene nå et punkt der saken er tidligere oppløsning.
Bunnlinjen
Til slutt kunne det ha vært unngått feil av Indiana og IBMs outsourcing-kontrakt med litt sunn fornuft. Begge parter syntes å være intelligente og ressursrike og var mer enn tilstrekkelig kompetente til å vite viktige problemer som måtte overvinnes. Retten fant at de virkelige problemene - selvinteresse, motstridende dagsordener, manglende kompetanse og ukjent risiko - ble stort sett ignorert til det var for sent. Mens de ikke lærte av tidligere feil, kan vi. Enten du planlegger en mega-avtale eller noe mer beskjeden, må du sørge for at du ikke gjentar de samme feilene!