Deze week kwam ik op het internet een artikel over projecten tegen. In dit artikel werd geponeerd dat een project wordt gerealiseerd door drie simpele stappen uit te voeren, namelijk
- Beschrijven van de AS-IS situatie
- Bedenken van het nieuwe proces
- Implementeren van het nieuwe proces
Makkie… , maar als dat zo is… waarom zijn er dan nog steeds zo veel projecten waarbij de doelstelling niet wordt behaald? En waarom heb ik hier ruim 5 jaar voor moeten studeren?
Helaas blijken projecten, zeker als de te veranderen processen worden ondersteund door software, niet altijd even eenvoudig te realiseren. Ook niet voor mensen die hiervan hun vak hebben gemaakt en vaak dit soort veranderingen hebben gefaciliteerd.
Maar wat gaat er dan verkeerd?
John Hansen geeft een verhelderende lijst bij “All about Requirements”.
Deze top 10 gaat eigenlijk hoofdzakelijk over 3 aspecten:
- Het (niet) kennen van de AS-IS situatie en het goed weten te identificeren daarvan.
- (On)Gestructureerde analyse en documentatie.
- (On)Duidelijk doel voor de optimalisatie.
Er gaat dus heel veel fout in de, op het eerste gezicht, duidelijke en eenvoudige stappen.
Daarom ben ik eens gaan zoeken naar de theorieën vanuit mijn studie. Los van de vondst, viel mij op dat ik erg lang moest graven naar een stukje in de boeken over het aanpakken van veranderingen in processen, ondersteund door IT. Blijkbaar is dit een onderwerp dat niet makkelijk te adresseren is vanuit de theorie. Uiteindelijk kwam ik een stuk tegen over het gebruik van de “Business Case” in het boek: “Information Technology for Management”. Hun definitie luid als volgt:
“A Business case is a written document that is used by managers to garner funding for one or more specific applications or projects”(…) .It also provides the bridge between initial plan and its execution”(..), but it also provide the foundation for tactical decision making and technology risk management.
Daarnaast is de Business Case (BC) het eerste “principe” van de Prince2 methodologie.
Wat doet een Business Case?
Dus een BC doet:
- Het bewijzen van het nut van de investering.
- Zorgen voor de brug of connectie tussen het plan en de uitvoering.
- Zorgen voor gefundeerde tactische beslissingen.
- Risico management.
Met andere woorden, als je het nut beschrijft van de investering, moet er al een goede analyse uitgevoerd zijn van de AS-IS situatie en het uiteindelijke doel. Als dat gebeurt, zijn de eerste twee gebieden waar het meeste fout gaat al verzorgd. Dat zou betekenen dat ieder project een BC zou moeten hebben…
De redding van het project
Toen viel bij mij ineens een kwartje. Ik heb in de ruim 6 jaar dat ik als adviseur werk, nog nooit een echte “Business Case” langs zien komen… en toch heel wat verschillende opdrachten gezien van implementaties van AX, het optimaliseren van processen tot het ontwikkelen van maatwerk. Ja, natuurlijk zijn er wel onderdelen uit de BC de revue gepasseerd, zoals GAP Analyses en Scope bepalingen. Maar de BC, zoals hij in een project bedoeld is, zie ik zelden of nooit. Zeker niet als een document dat niet alleen in het project aan het begin staat, maar ook door het project heen gebruikt wordt als leidraad. Waarmee dus een hoop issues voorkomen kunnen worden.
Mijn stelling is: Het schrijven van een goede Business Case redt het project. Ik ben benieuwd naar je reactie!
Foto is afkomstig van www.freedigitalphotos.net door jannoon028
