Gebruiksstatistieken... weet wat je meet!

Ik heb deze week een flink deel van de dag met mijn hoofd in Excel gezeten. Niet dat ik plotseling een management functie ambieer, maar omdat ik een goed (beter) beeld wilde hebben van het gebruik van een bepaalde SharePoint omgeving. Dit om een goede inschatting te krijgen van de hoeveelheid verkeer die ik kan verwachten op een applicatie die vanuit een SharePoint webpagina wordt aangesproken.

Ook een mooie gelegenheid om eens wat gedachten over web statistieken op een rijtje te zetten.

Allereerst antwoord op de vragen:
- Wat meten we?
- Waarom meten we?

Wat meten we?
Als een gebruiker (bezoeker) een web adres in zijn browser intypt dan legt de browser contact met de webserver waar de betreffende website is ondergebracht. Tijdens dit contact (request) worden gegevens over het verzoek door webserver vastgelegd in een logbestand. Dit is onder anderen wie het verzoek doet, welke bestanden hij opvraagt en wanneer de aanvraag is binnengekomen, maar ook zaken als het gebruikte besturingssysteem, de browserversie, etc.). Omdat een web pagina vaak bestaat uit een tekstbestand (HTML) waarin ook zaken als plaatjes voorkomen, zal de browser meerdere verzoeken doen aan de webserver: voor ieder bestand 1 request. Een webpagina waarin 3 plaatjes zijn opgenomen zal bijvoorbeeld 4 requests vergen: 1 voor de web pagina en 3 voor de plaatjes. Interactieve web pagina's, bijvoorbeeld waarin de eindgebruiker formulieren kan invullen en waarin ingevulde veldwaarden worden gecontroleerd, of web pagina's waarin illustraties elkaar afwisselen, zullen na het laden van de web pagina nog steeds requests aan de web server versturen voor additionele bestanden (plaatjes, controle resultaten, etc.).

Hier ontstaat een mogelijke verwarring: het verschil tussen hits en bezoekers.
Lang geleden, toen webpagina's, JavaScript en Perl-scripts nog met teksteditors werden geschreven, had ik een discussie met een business manager van een internet bedrijf over bezoek statistieken van een bepaalde web site. De sponsor van de web site werd maandelijks een rapport voorgeschoteld met daarin een uitspraak over de populariteit van deze web site en de de directeur was erop gebrand de getallen zo hoog mogelijk te laten uitvallen. In de logbestanden die ik moest analyseren maakte ik duidelijk verschil tussen het aantal hits (webpagina's, plaatjes, ander bestanden die door de browser werden opgevraagd) en bezoekers (toendertijd het aantal web pagina's dat werd opgevraagd). Het aantal bezoekers was natuurlijk aanmerkelijk lager en had niet de voorkeur van de betreffende directeur. Na uitleg van mij over wat precies werd gemeten werd de voorkeur enigszins aangepast door te sturen op het voorzien van de web pagina's van zoveel mogelijk plaatjes. Rest mij te zeggen dat ik hier niet aan heb meegewerkt :).

Ik wil met het bovenstaande voorbeeld overigens niet zeggen dat het meten van hits geen doel dient, want dat is geenszins het geval. Je moet alleen weten waarvoor je het kunt gebruiken, wat me brengt op het doel van het meten.

Web site of web applicatie?
Maar allereerst het volgende. In de onderstaande tekst heb ik het over web applicaties. Hieronder versta ik de verzamelnaam voor web sites (html, rss, etc.) en applicaties (b.v. apps) die gebruik maken van een web server.

Waarom meten we?
Grofweg kunnen de volgende doelen met meten worden nagestreefd:
- Meten van de populariteit van een produkt of dienst
- Meten van het gebruiksgemak van een web applicatie
- Meten van beschikbaarheid, prestaties en werklast van een web applicatie

Meten van de populariteit van een produkt of dienst
Dit is een breed doel, maar komt is essentie neer op het bepalen in hoeverre het produkt of de dienst die door de betreffende web applicatie ondersteunt interesse geniet van de internet gebruiker. Van belang hierbij zijn bijvoorbeeld hoeveel echte bezoekers de web applicaties krijgt, of deze bezoekers regelmatig terugkomen en welke handelingen de bezoekers uitvoeren. Dit laatste is natuurlijk het allerbelangrijkst: een bezoeker kan slechts de begin pagina bekijken, maar ook geinteresseerd rondkijken, en in het beste geval een of meerdere transacties afsluiten (lees: iets via de web applicatie aanschaffen).

Indirect is de populariteit trouwens het meten van de doeltreffendheid van de verwijzingen naar de betreffende web applicaties, bijvoorbeeld vanuit zoekresultaten en banners/advertenties. In het algemeen: wanneer een bezoeker direct vanuit een externe bron (b.v. een favorite, externe link, zoekmachine) naar een lokatie (web pagina) in de betreffende web applicatie "springt", kan dat iets zeggen over de populariteit van de web applicatie en/of het ondersteunde produkt of de ondersteunde dienst. Wellicht is het gelinkte onderdeel zoveel gebruikt dat het een gemakkelijker te bereiken plaats in het menu verdient?

Aanvullende, belangrijke metingen kunnen natuurlijk gedaan worden door het houden van enquetes of het laten beoordelen van de web applicatie door de bezoeker (tagging/rating).

Meten van het gebruiksgemak van een web applicatie
Hierbij gaat het om meetgegevens waaruit kan worden afgeleid hoe gebruiksvriendelijk de bezoeker de betreffende web applicatie vindt, ofwel: antwoord vinden op de vraag of de bezoeker zijn doel op een voor hem voldoende gemakkelijke manier kan bereiken. Wat hierbij belangrijk is te meten welke weg (klik- of zoekpad) de bezoeker aflegt voordat hij zijn doel bereikt, en dit te vergelijken met de optimale navigatie zoals die in het ontwerp van de web applicatie is bedacht.
Interessant hierin is ook het gebruik van de zoek faciliteiten de betreffende web applicatie. Ingevulde zoektermen, zoekresultaten verfijnen (b.v. door faceted search) en navigatie vanuit de zoekresultaten zeggen veel over de onderwerpen waarnaar de bezoeker naar op zoek is en de doelmatigheid van zijn zoektocht. Wellicht betekent veelvuldig gebruik van de zoekmachine naar een bepaalde term dat het onderwerp in kwestie slecht vindbaar is?

Ook wanneer een bezoeker direct vanuit een externe bron (b.v. een favorite, externe link, zoekmachine) naar een lokatie (web pagina) in de betreffende web applicatie "springt", kan dat ook iets over het gebruiksgemak van de web applicatie. Wellicht is het gelinkte onderdeel dan ook lastig te vinden?

Gerelateerd aan het meten van het gebruiksgemak van een web applicatie is het meten van het gebruiksgemak van de wijze waarop de web applicatie wordt gevonden, bijvoorbeeld vanuit zoekresultaten en banners/advertenties.

Ook hierbij kunnen aanvullende, belangrijke, metingen natuurlijk worden gedaan door het houden van enquetes of het laten beoordelen van de web applicatie door de bezoeker (tagging/rating).

Tenslotte zeggen foutmeldingen veel over het gebruiksgemak dat een bezoeker ervaart. Fouten als een "404" of "Not Found" (zie ook: HTTP 404) worden wel vastgelegd maar regelmatig niet meegenomen in bezoekstatistieken.

Meten van beschikbaarheid, prestaties en werklast van een web applicatie
Deze categorie doelen heeft een duidelijk technische achtergrond.
Meten van beschikbaarheid van web applicaties (en de onderliggende diensten als servers, besturingssystemen, platforms etc.) is essentieel binnen web dienstverlening. Hierbij gaat het in essentie om het halen van gemaakte afspraken (SLA's) die over de web dienstverlening zijn gemaakt tussen de klant (business) en de IT-leverancier waarbij het meten van beschikbaarheid als onderbouwing kan worden gebruikt. Hierbij gaat het trouwens dus om hits in plaats van bezoekers, omdat de beschikbaarheid gemeten wordt van alle (technische) bronnen; HTML webpagina's, plaatjes, scripts, etc..
Een speciaal doel van het meten (zowel hits als bezoekers) is het bepalen van de werklast die een bepaalde web applicatie zal moeten kunnen verwerken of de werklast die een daaraan gerelateerde (gelinkte of geintegreerde) (web) applicatie zal moeten kunnen verwerken. Zie hiervoor ook mijn artikel over integratie: Platform integratie: functionaliteit onder handbereik.

Een paar voorbeelden ter illustratie...

Een web applicatie zal worden gemigreerd naar een nieuw platform
Hierbij zal bepaald moeten worden in hoeverre het nieuwe platform (en onderliggende soft- en hardware) voldoende geschaald is of schaalbaar is om de verwachtte werklast te kunnen verwerken. Een goede inschatting van het bezoek en het gebruik van bronnen (hits op bestanden) is hiervoor essentieel.

In een bestaande nieuws webpagina worden RSS feeds vanuit een andere bron weergegeven
In het algemeen: een web applicatie zal gebruik maken van een andere web applicatie, en hier dus web verkeer op genereren en daarmee de werklast van de andere web applicatie verhogen. Het is hierbij dus van belang om te weten om welke extra werklast het hier gaat. Bezoekersaantallen van de web applicatie (b.v. de nieuwspagina in het voorbeeld) zijn hierbij daarom van belang. Voor iedere bezoek wordt minimaal een request gedaan aan de andere web applicatie. Mocht de andere web applicatie de extra werklast niet kunnen verwerken, kan dat negatieve gevolgen hebben voor de web applicatie(s) die ervan gebruik ma(a)k(t)(en). Een web applicatie kan dan bijvoorbeeld trager functioneren of deels of geheel niet beschikbaar lijken te zijn.

Van belang bij het meten hiervan is onderscheid te maken tussen gemiddelde werklast en piekbelasting.

Valkuilen en praktische tips, een overzicht
Op basis van de bovenstaande doelen en praktische ervaringen, onderstaand een aantal belangrijke valkuilen en praktische tips.

- Houd het doel van de analyse goed in de gaten en gebruik de juiste metingen daarbij
Gaat het om populariteit, ga dan niet uit van hits. Gaat het om werklastbepaling, ga niet alleen uit van bezoekers, maar neem alle web verkeer mee in de analyse.

- In vakantieperioden is het aanmerkelijk rustiger dan in "normale" werkweken.
Daarnaast vieren we niet tegelijk onze vakanties; ons land is ingedeeld in regio's, dus als het in de ene regio een normale werkweek lijkt, kan een regio waar vakantie gevierd wordt, de hoeveelheid web verkeer omlaag brengen. Tenslotte zijn (dat is voornamelijk bij intranetten van belang) werkweken niet bij iedere organisatie dezelfde: soms wordt er bijvoorbeeld ook in het weekend gewoon doorgewerkt. Ga daarom uit van "normale" werk weken zoals die in de betreffende organisatie gelden.

- Bij het berekenen van gemiddelde - en piekbelasting moet je rekening houden met werkdagen, werktijden, pauzetijden, en andere bijzondere tijdsperioden.
In het algemeen zou rekening gehouden kunnen worden met een 8 urige werkdag waarin medewerkers eerder kunnen beginnen of later kunnen stoppen. Ik ga meestal uit van een 10 urige tijdsspanne. Gedurende pauzes en aan het begin en einde van de werkdag ontstaan vaak pieken of dalen in het webverkeer.

Pieken in web verkeer, vooral aan het begin van de dag, ontstaan doordat...

- ... bij het opstarten van de browser vaak meteen een standaard webpagina (b.v. de homepage van het intranet) wordt geladen.
Dit geeft een vertekend beeld van de populariteit van de homepage (en een piek in het webverkeer aan het begin van de dag). Dit webverkeer zal daarom buiten de populariteitsmetingen gehouden moeten worden, maar zal wel meegenomen moeten worden bij belastingmetingen. Let op: in de praktijk veelvuldig crashen van pc's en browsers zorgt eveneens voor een toename in webverkeer op de standaard ingestelde browser homepage.

- Spiders en monitors genereren ook webverkeer; filter dit verstandig uit. Een web server registreert alle requests vanuit alle bronnen. Naast browsers (die verzoeken namens gebruikers doen), worden requests ook automatisch gedaan door programmatuur. Voorbeelden hiervan zijn: monitors, spiders (bijvoorbeeld voor zoekmachines), maar ook: RSS newsreaders. Deze requests zijn herkenbaar aan de informatie die bij die requests aan de web server worden meegegeven zoals gebruikersnaam (zoals bijvoorbeeld service accounts in het geval van spiders op intranetten) en type client (b.v. browser / reader versie). Dergelijke requests zullen ook met de regelmaat van een klok plaatsvinden; op vaste dagen / tijdstippen.

Wat betreft web verkeer vanuit RSS readres: het opvragen van een (RSS) web pagina hoeft niet noodzakelijkerwijs te betekenen dat een nieuwsbron populair is. Een klik vanuit een RSS feed naar het achterliggende artikel zegt meer.

Wanneer een inschatting van belasting gemaakt moet worden, moet web verkeer van spiders, monitors, etc. meegenomen worden. Wordt de populariteit gemeten, dan kan dit verkeer er wellicht beter uit gefilterd worden of kan het web verkeer opgesplitst worden naar kanaal / device / type applicatie waarvan het afkomstig is.

- Meten van webverkeer op individuele pagina's zegt relatief weinig over de populariteit van een site of web pagina.
Wat meer zegt is het gedrag van de bezoeker; klikpaden, zoektermen, afsluiten van transacties, etc..

- Vergeet niet te meten wat er fout gaat.
Een bezoeker die regelmatig geconfronteerd wordt met fouten, haakt af. En dat kan nooit de bedoeling zijn.

Conclusie
Aanleiding voor het schrijven van dit artikel was dat ik deze week een flink deel van de dag met mijn hoofd in Excel heb gezeten. Waarom ik dat deed is dat ik twijfelde aan de bezoekstatistieken die ik in mooie diagrammen en overzichtjes vanuit een web statistiek software pakket kreeg voorgeschoteld en die normaliter voor waarheid werd aangenomen.

Mijn twijfel bleek terecht: een groot deel van de gemeten "populariteit" bleek veroorzaakt te worden door automatische bezoekjes van spiders en monitors.

Meten is weten, maar weet eerst wat je meet.

Platform integratie: functionaliteit onder handbereik

Vaak krijg ik de vraag of ik een applicatie kan ontsluiten binnen een platform, bijvoorbeeld SharePoint. Wat een gebruiker of ICT beheerorganisatie hieronder verstaat, verschilt van geval tot geval, en daarmee lopen de verwachtingen die ik moet scheppen of bijstellen ook nogal.


Daarom heb ik maar eens een overzicht van varianten gemaakt die in in de praktijk tegenkom, in volgorde van mogelijkheden en complexiteit.


1. Link (vanuit het bronplatform wordt gelinkt naar het doelplatform of de doelapplicatie):
a. Zonder authenticatie/autorisatie

b. Met handmatige authenticatie/autorisatie (onhandig)

c. Met automatische authenticatie/autorisatie (single sign on)

d. Directe link naar gewenst scherm / gewenste functionaliteit


2. Viewport (publicatie van (deel van) gebruikersinterface van het doelplatform in het bronplatform):
a. Zonder authenticatie/autorisatie

b. Met handmatige authenticatie/autorisatie (erg onhandig)

c. Met automatische authenticatie/autorisatie (single sign on)

d. Directe link naar gewenst scherm / gewenste functionaliteit


3. View (geïntegreerd gegevens overzicht , of rapportage, vanuit de doelapplicatie naar de bronapplicatie):
a. Niet geparameteriseerd: altijd hetzelfde overzicht

b. Geparameteriseerd : varianten van het overzicht, op basis van aan de doelapplicatie opgegeven parameters


4. Interact:
a. Submit: opsturen van formulieren (webform, via workflow of integration broker / bus, via e-mail, etc.) en Response hierop vanuit het doelsysteem (view, e-mail, etc.)

b. Interactive: de gebruikersinterface van het doelsysteem is geïntegreerd in de gebruikersinterface van het bronplatform.


5. Informatiewerkplek integratie: geintegreerde applicaties koppelen aan (een) andere (geintegreerde) applicatie(s)
Wat voorbeelden ter illustratie:

- Via Word (een extra knop in de "Ribbon") kan een lijst uit SharePoint worden gehaald en worden gebruikt voor een mailmerge naar klanten (gebruik van velden in Word-documenten).

- In een Excel sheet (.qry file) kan een SharePoint lijst worden geimporteerd, die vervolgens binnen MS-Word wordt gebruikt voor een mailmerge.

Kenmerk van dergelijke integratie is dat het gebruik van de geintegreerde functies niet in een vaste volgorde of samenstelling hoeft te gebeuren. In een informatiewerkplek bepaalt de gebruiker veelal zelf hoe hij zijn werk "doet".

Wat nu een interessante vraag is, is de volgende: waarmee moet ik "rekening houden" bij de verschillende vormen van integratie? Wat zijn de gevolgen van gemaakte keuzen?
Om deze vraag te beantwoorden, zullen we eerst moeten bekijken waar de gevolgen van keuzes plaats gaan vinden. Daarvoor gebruik ik vaak een architectuur raamwerk (in dit geval IAF), waarbij de verschillende aspecten (business, informatie, applicaties, infrastructuur) waarin gevolgen zichtbaar zijn, aan de orde komen.

Meer volgt...

Out-of -the-box of maatwerk, that's the question

Waar ik ook advies geef, altijd steekt de maatwerk-discussie weer de kop op. "We willen absoluut geen maatwerk, alles moet 'out-of-the-box'!", is daarbij een veelgesteld standpunt. In de praktijk, echter, werkt dit standpunt nogal eens averechts; angstvallig vermijden van maatwerk kan namelijk ook onnodig geld en tijd kosten. En afgezien daarvan is vaak ook niet echt duidelijk wat wordt verstaan onder "maatwerk" en "out-of-the-box". Tijd dus om een en ander eens uitgebreid te behandelen om licht op de zaak te werpen en zo beter beslissingen te kunnen nemen.

Definities
Laten we beginnen met wat definities te geven en beschrijvingen wat maatwerk, out-of-the-box en de "smaken" daartussen in zijn.

Maatwerk, oftewel custom software: is software die speciaal voor een bepaalde situatie is gemaakt. Dit is niet gebaseerd op een bestaand platform, maar is vanaf de grond af speciaal ontworpen en gebouwd, speciaal voor de situatie.

Out-of-the-box software is software die, als het ware, na installatie al kan worden gebruikt voor het doel waarvoor het is aangeschaft. Dat is nogal ambitieus, want iedere situatie is namelijk anders en een software fabrikant kan natuurlijk nooit helemaal voorspellen waarvoor zijn software(platform) zal worden ingezet.

Vandaar ook dat aanpassingen aan software(platforms) vaak noodzakelijk zijn om deze aan te passen aan de situatie waarin ze gebruikt worden. En deze aanpassingen kunnen de volgende vormen aannemen:
- Aanpassingen in de vorm van configuratie; via de gebruikersinterfaces van de software instellen en aanpassen van de werking en functionaliteit van de software
- Uitbreidingen van de software, in de vorm van modules, adapters, enz..

Naast goed te weten wat voor type aanpassingen er aan de software mogelijk zijn is het ook belangrijk te weten wanneer welk type aanpassing in welke situatie gewenst is. De keuze om bijvoorbeeld voor out-of-the-box te kiezen, bijvoorbeeld, hoort namelijk geen doel op zich te zijn, maar een valide doel te dienen. En om dit doel te daarvoor moeten we wat breder kijken dan de ICT projecten zelf en kijken hoe een organisatie alternatieven beoordeelt. Het beoordelen van alternatieven gaat vaak, en ook in dit geval, op basis van risico inschattingen.

Risico's
Een organisatie streeft doelen (kwaliteit) na en die doelen kunnen op verschillende manieren worden gerealiseerd, waarbij kosten worden gemaakt en tijd wordt verbruikt. Geld en tijd is meestal van tevoren gereserveerd en beschikbaar, waarbij men ernaar streeft dit uit te geven met zo min mogelijk risico voor overschrijding en het niet behalen van de gestelde doelen en kwaliteit. En dat is de kern van de maatwerk vs. out-of-the-box problematiek: bepalen van het alternatief waarbij de gestelde doelen met een minimum aan risico kunnen worden behaald.

Maar hoe schatten we dat risico nu in? Waar moeten we naar kijken? Waar heeft dat risico betrekking op?

Vaak wordt helaas alleen gekeken naar de bouw van de eerste versie van een software oplossing, en nog niet eens naar installatie ervan, laat staan onderhoud, uitbreidingen en andere werkzaamheden. En dat terwijl de keuze voor out-of-the-box, maatwerk of een tussenvorm verdergaande gevolgen kan hebben.

Een praktijkvoorbeeld:
In een SharePoint ontwikkelomgeving wordt, volgens het out-of-the-box principe een prototype gebouwd van een website die vervolgens moet worden geïnstalleerd in de productie omgeving. Hiervoor blijken scripts noodzakelijk te zijn die ervoor moeten zorgen dat de website automatisch wordt geïnstalleerd in deze omgeving. De scripts moeten als maatwerk worden ontwikkeld, terwijl het uitgangspunt out-of-the-box was.

Een ander voorbeeld:
Een software oplossing wordt uitgebreid met een interface waardoor het mogelijk wordt om content via de RSS standaard te delen met andere applicaties. Hier wordt uitgegaan van maatwerk, maar met als gevolg dat verwachtte uitbreidingen kunnen worden gebaseerd op een standaard, hetgeen koppelen met out-of-the-box software oplossingen mogelijk wordt.

Het verdient daarom aanbeveling om te kijken naar de gehele software life cycle, en ook te kijken naar de gevolgen (impact) van de introductie van de oplossing binnen de organisatie.

Software life cycle
Software wordt niet eenmalig gebouwd, om vervolgens onaangepast tot in de eeuwigheid te functioneren. Grofweg zijn de volgende levensfasen van een software(platform) te onderscheiden:
1. Bouw en installatie van de eerste versie
2. Onderhoud, aanpassingen, uitbreidingen
3. Migratie naar een nieuwe versie
4. Afbouw

In alle bovenstaande fasen kan sprake zijn van maatwerk, out-of-the-box of een tussenvorm. En wanneer een eerste versie van een software oplossing wordt gebouwd als out-of-the-box wil dat niet zeggen dat voor de rest van de levensfasen uitgegaan kan worden van datzelfde out-of-the-box principe.

Het verdient dus aanbeveling om de gevolgen (impact) van de keuze voor maatwerk, dan wel out-of-the-box of een tussenvorm te bepalen voor alle levensfasen van de software oplossing.

Impact breder bekeken
Nu we het toch hebben over gevolgen (impact), laten we deze impact ook eens bepalen voor de omgeving waarin de software wordt gebruikt. Hiertoe kan gebruik worden gemaakt van een architectuur raamwerk (als IAF) waarin helder gemaakt kan worden wat de gevolgen van oplossingskeuzen zijn voor business(processen, functies), informatiearchitectuur, technische infrastructuur, beheer en beveiliging. De keuze voor out-of-the-box kan bijvoorbeeld grote gevolgen hebben voor business processen.

Voorbeeld:
Introductie van een collaboratie platform waarbij eindgebruikers zelf hun omgeving kunnen inrichten (b.v. virtuele werkruimten aanmaken, collega's toegang geven, zelf content beheren) lijkt in eerste instantie de ontwikkelkosten voor een eerste versie te minimaliseren. Immers: in plaats van "dure" ICT specialisten, doen "gewone" eindgebruikers het (ontwikkel)werk. Echter, vanuit oogpunt van beheerbaarheid (governance) wordt een deel van de verantwoording bij niet-experts neergelegd, waardoor extra risico's worden gelopen op bijvoorbeeld wildgroei, waardoor beheerkosten en migratiekosten uiteindelijk hoger uitvallen.

Het nut van een bredere kijk op de gevolgen van keuze voor maatwerk, out-of-the-box of een tussenvorm is daarmee aangetoond.

Het lijkt allemaal logisch, maar toch denken we iedere keer weer van tevoren niet genoeg na over de keuze tussen maatwerk, out-of-the-box of een tussenvorm. De vraag is natuurlijk wat hiervan de oorzaak is.

De beperkte blik van projectmanagement
In de praktijk blijkt het hebben van een brede kijk op ICT projecten een uitdaging op zich te zijn. Reden hiervan is de manier waarop software ontwikkeling is georganiseerd; dit leent zich niet altijd voor een bredere (en daarmee kritische) kijk. Projecten worden namelijk beheerd door projectmanagers en projectmanagers worden beoordeeld kwaliteit, doorlooptijd en kosten van slechts een zeer beperkt deel van de software levensloop, vaak alleen de bouw van de eerste versie. Als de bouw van de eerste versie van een software oplossing naar tevredenheid verloopt, volgt een goede beoordeling. De gevolgen voor kosten, doorlooptijd en kwaliteit in volgende levensfasen, zal de projectmanager niet interesseren, hij is er immers niet verantwoordelijk voor. Zeker wanneer het project onder druk staat (lees: wanneer vooral doorlooptijd, en/of kosten dreigen te worden overschreden) zal een projectmanager kiezen voor oplossingen op de korte termijn, hetgeen gevolgen heeft in de latere levensfasen van de software oplossing.

De gevolgen
De gevolgen laten zich raden: implementatie - en onderhoudskosten voor ICT projecten rijzen de pan uit en lijken onbeheersbaar te zijn. Te hoge verwachtingen van mogelijkheden die platformen out-of-the-box aan functionaliteit bieden leiden tot teleurstellingen en moeten achteraf worden waargemaakt door (duur) maatwerk of sterk worden bijgesteld.

Dit kan natuurlijk beter.

Praktische tips om beter om te gaan met de keuze voor maatwerk, out-of-the-box of tussenvormen
In het algemeen: over de gevolgen van de verschillende strategieën zal van tevoren en projectoverstijgend nagedacht moeten worden.
Eerst zullen de verschillende mogelijke strategieën: van out-of-the-box tot en met maatwerk, goed gedefinieerd moeten worden. Wanneer wordt bij voorbeeld iets gerekend tot out-of-the-box? Aan welke eigenschappen moet het voldoen?
Daarna zal duidelijk moeten worden wat de gevolgen zijn van de mogelijke strategieën, in de verschillende levensstadia van de betreffende software oplossing.Hiertoe kan gebruik worden gemaakt van een architectuur raamwerk als IAF.
Op basis van de bovenstaande uitwerking kan een onderbouwde keuze worden gemaakt.

Tenslotte zullen de genomen beslissingen projectoverstijgend moeten worden bekrachtigd; de verantwoordelijkheid van de projectmanager, als hij niet voor de hele software lifecycle verantwoordelijk is, is hierbij onvoldoende.