Når det gjelder IT -prosjekter, er ordtaket " søppel inn søppel ut (GIGO) uttrykker det faktum at feil inngangsdata konsekvent vil gi feil resultater. I prosjektledelse er det det samme: det er liten sjanse for at et opprinnelig dårlig utformet prosjekt vil føre til resultater som lever opp til forventningene.
Sammendrag
- Hva er funksjonelle spesifikasjoner?
- En CCF, hva for?
- Hvordan skrive en funksjonell spesifikasjon?
Hva er funksjonelle spesifikasjoner?
En funksjonell spesifikasjon (CCF) er et dokument som på en detaljert og strukturert måte presenterer forventningene til et prosjekt (tjenester, produkter) og dets begrensninger (teknisk, ledelsesmessig, kontekstuell). I prinsippet er det leveransen som sanksjonerer slutten på lanseringsfasen av et prosjekt.
CCF er sentrum for utvekslinger mellom prosjekteier (MOA) og leverandøren eller tjenesteleverandøren. Når den er validert, utgjør den referansen som gjør det mulig å garantere hele prosjektets samsvar med prosjektets innhold med de første forventningene.
En CCF, hva for?
-
Formaliser behovene i samråd med prosjekteieren
Utviklingen av den bærbare datamaskinen utgjør kulminasjonen av den vesentlige prosjektdefinisjonsfasen.
Det er resultatet av en strukturert dialog mellom prosjekteier og leverandør (er) eller prosjektledelse (AMOA), som gjør det mulig å etablere en felles forståelse av behovet i vilkår som deles av alle. CCF kan derfor skyldes ytterligere prosesser som skal settes i gang oppstrøms:
- Studie av mulighet : eksisterer behovet?
- Mulighetsstudie : er prosjektet mitt økonomisk / teknisk levedyktig?
- Funksjonell analyse av behovet : det er avgjørende for utformingen av en CCF, fordi det vil gi det nøkkelelementene: synspunktene til de forskjellige partene som er berørt av prosjektet (sluttbrukere, relaterte aktører, etc.), varigheten av produktet og dets livssyklus og de forventede resultatene (uten å nevne midler for å oppnå det)
- Verdianalyse : det legger til funksjonell analyse en evaluering a priori løsninger og deres kostnader for å bedre prioritere de første behovene.
-
Sett rammeverk for leverandøren
Overfor et gitt problem vil enhver leverandør bli fristet til å tilby en "nøkkelferdig" løsning, som ikke vil ta opp de spesifikke aspektene ved prosjektet ditt.
Derfor bør CCF tydelig angi funksjonelle spesifikasjoner, forventet kvalitet, tidsfrister og budsjett. Leverandører bør likevel få tilstrekkelig pusterom for å dra nytte av deres evne til å innovere og originale ideer.
-
Sammenlign forslagene
Denne dimensjonen er avgjørende i forbindelse med en utlysning hvis CCF er en del av markedet. Det vil da være mulig å foreslå evalueringskriterier som leverandører må ta i betraktning for å foreslå den mest konkurransedyktige løsningen; disse kriteriene kan bringes sammen i et poengnett som vil bli brukt for den samlede evalueringen av respondentene.
-
Tilrettelegge for den endelige evalueringen
Formalisering av de funksjonelle behovene via en CCF gjør det mulig på slutten av prosjektet å sammenligne de første forventningene med resultatene oppnådd på et objektivt grunnlag, og ikke på de enkle "følelsene" til ansatte eller økonomiske indikatorer. Spesielt letter det utøvelsen av prosjektavslutning.
Hvordan skrive en funksjonell spesifikasjon?
På skjema
For å være i drift må de funksjonelle spesifikasjonene være:
- Konsis : favoriserer korte setninger og enkle svinger. Å angi et antall tegn eller ord kan være en nyttig metode for å gjøre dette.
- Enkel : Bruk kun fagtermer når det er nødvendig, bruk ord uten tvetydighet eller dømmekraft. Prosjektets interesse (teknisk, organisatorisk, økonomisk) må tydelig demonstreres.
- Organisert : dokumentet må være strukturert av en plan (se nedenfor), med balanserte deler.
På bakgrunnen
Prosjektramme
Dette er den delen som er felles for alle prosjekter, som skal gjøre det mulig for enhver leverandør å finne de essensielle elementene for en overordnet visjon om det uttrykte behovet. Denne delen inkluderer:
- Sammenhengen : prosess for å identifisere behovet, produkt- / tjenestemiljøet (mennesker, utstyr, regulering, etc.);
- Målet : hvilket servicenivå som forventes, for hvilke økonomiske resultater og hvilke kvalitetskriterier (for eksempel målrettet kundetilfredshet);
- Omkretsen : Berørte aktører (internt, eksternt, hvilke brukere osv.), geografisk omfang hvis det er aktuelt.
Funksjonelle kriterier og evaluering
Rekkefølgen på de følgende delene kan avhenge både av strukturen i prosjektet ditt (antall hovedfunksjoner og underfunksjoner, lenker mellom dem), men også av markedet der det passer hvis det er en anbudsinnkallelse med komponenter som ringer flere handler - i så fall kan en tildeling være nødvendig.
Strukturering av CCF viser seg da å være en verdifull øvelse for å sikre at de forskjellige tilbudene vil være sammenlignbare med hverandre, og at sluttproduktet kan evalueres på en relevant måte ved prosjektets slutt sammenlignet med uttrykket for det første behovet . Uansett må CCF inneholde følgende tre deler:
- Beskriv behovene: funksjonelle spesifikasjoner
Det er mange metoder for å gjøre denne øvelsen: horndyr, blekksprutdiagram … Uansett hvilken du velger, er det bare å skrive ned hva det endelige produktet må "gjøre" for å dekke de angitte behovene.
Dette er formålet med funksjonelle spesifikasjoner: de er delt inn i hovedfunksjoner (som oppfyller et behov), selv brutt ned i underfunksjoner (handlinger som dekker en del av behovet). For eksempel, for en reisekomparator, vil en hovedfunksjon være " foreta en sammenligning mellom flere tilbud fra flyselskaper ", Og underfunksjonene" angi en destinasjon », « skriv inn en tidsplan », « sette en prisgrense "Etc.
- Budsjettkonvolutt og ressurser
For hver hovedfunksjon vil det være et spørsmål om å definere den forventede mobilisering av ressurser (antall virkedager, budsjett).
- Frister og leveranser
Dette er for å indikere forventet sluttdato for prosjektet, og spesifisere:
- mellomleveranser hvis aktuelt,
- valideringsfristene fra MOA, og straffene hvis det er aktuelt.
CCF kan ledsages av en veiledende tidsplan, hvis den allerede er formalisert.
En viss formalitet kreves for at den skal forstås av alle interessenter. Målene er klart definert.
