Programvareutvikling :: Hvis du ikke kontrollerer endringen, kontrollerer du ikke budsjettet

Budsjett handler ikke om å begrense endring

Hvor de fleste programvareprosjekter begynner

De fleste henvendelser om programvare starter på samme sted. En organisasjon har en eksisterende prosess, ofte noe som har vokst frem over tid, og ønsker å gjøre den om til en brukbar applikasjon som forbedrer effektivitet, synlighet og kontroll.

Ved første øyekast høres det greit ut. Prosessen eksisterer allerede, så antagelsen er at den rett og slett kan oversettes til programvare. I mange tilfeller stemmer det. Hvis virksomheten forstår prosessen og kan dokumentere den tydelig, er du allerede på startlinjen.

Fra et ledelsesperspektiv bør det føles som en posisjon av kontroll. Organisasjonen vet hva den gjør, hvordan den opererer og hva den trenger at systemet støtter.

Når prosessen blir synlig

Utfordringen begynner når prosessen begynner å ta form inne i et system.

Så snart den blir synlig, begynner folk å se den annerledes. De engasjerer seg, ser hvordan den kan utvikle seg og begynner å gjenkjenne nye muligheter. Nye ideer oppstår, kanttilfeller identifiseres, og ulike interessenter tolker hvordan det bør fungere på litt forskjellige måter. Dette er ikke en feil, det er en naturlig del av å gjøre en prosess eksplisitt.

På dette punktet må selv tilsynelatende enkle endringer gjennomgås fra alle perspektiver og i alle stadier av prosessen. Det som virker lite isolert sett kan ha videre implikasjoner, særlig der flere roller, beslutninger og avhengigheter er involvert.

Hva interessenter fokuserer på kontra hva organisasjonen trenger

I velstrukturert programvarelevering er fokus på det som betyr mest for organisasjonen, ikke bare på hva som etterspørres av interessenter. I mange tilfeller inkluderer det revisjonssporbarhet, som er kritisk for organisasjonen, men som ofte overses til fordel for ekstra funksjoner.

Interessenter fokuserer naturlig på hva de ønsker at systemet skal gjøre. De fokuserer sjelden på hvordan disse endringene må implementeres, registreres og styres når systemet er i drift.

Hvorfor små endringer ikke er små

Dette endrer karakteren til selv den enkleste forespørselen. En liten justering er ikke lenger bare en teknisk endring, den blir en del av en kontrollert og sporbar prosess. Som et resultat kan det som virker lite ha en mye større innvirkning når samsvar, ansvarlighet og operasjonell synlighet vurderes.

Kontroll definerer utfallet

Hvis endringen ikke kontrolleres, er heller ikke utfallet det.

Det som begynner som et veldefinert initiativ kan raskt bli noe helt annet, ikke gjennom dårlige hensikter, men gjennom manglende struktur rundt hvordan beslutninger tas etter hvert som systemet utvikler seg. Kostnaden er ikke bare finansiell. Den måles i tid, kompleksitet, driftsforstyrrelser og tap av klarhet.

Det er her mange organisasjoner mister kontrollen uten å innse det.

De tror de styrer leveringen, mens systemets retning i virkeligheten formes trinnvis av umålt endring.

Dette er nøyaktig der Libertas Software Research opererer.

Ikke bare i å bygge systemer, men i å sikre at disse systemene forblir i tråd med organisasjonen etter hvert som de utvikler seg. Det betyr å skape struktur rundt endring, gjøre dens innvirkning synlig og sikre at hver beslutning forstås i sammenheng med kostnad, tid og langsiktig drift.

Spørsmålet er ikke om endring vil skje.

Det vil den.

Spørsmålet er hvem som kontrollerer den.

PrimeCRM