Problemen opvolgen met een issues database

Waarvan krijgt u als IT-projectleider de meeste grijze haren? Niet van een dik analysedossier en ook niet van complexe technologie. Wel van de problemen die opduiken zodra het project is gestart. De gebruiker die een wijziging vraagt, de analist die iets over het hoofd zag, de programmeur die een nieuw probleem opwerpt. Technische vragen die een antwoord moeten krijgen, zakelijke opties waaruit een keuze moet worden gemaakt. Soms zijn het er zoveel dat u dreigt te verdrinken. Hoe behoudt u het overzicht? Hoe volgt u dit alles op?

Problemen zijn er in soorten. Soms worden ze ingedeeld in problems, issues en changes.

Changes zijn wijzigingen. Uw interne of externe klant is van mening veranderd. Hij heeft te laat begrepen wat er in de analyse stond. Daar kan hij niet mee leven, en hij dient een change request in. De analist beschrijft de gewenste werking van de toepassing, de veranderingen die dat meebrengt aan de database en de programma’s, en maakt een schatting van de kosten. In dat geval gaat het om een functionele change, maar er bestaan ook technische changes. Soms beseft men te laat dat de voorziene technische oplossing niet geschikt is voor de betroffen omgeving, en moet men een andere aanpak zoeken.

Issues zijn punten die een beslissing vergen. Er zijn meerdere mogelijke werkwijzen; welke gaan we kiezen? Gaat het om een beslissing over het verloop van een bedrijfsproces, dan hebt u misschien een hooggeplaatste manager nodig. Dat kan vervelend zijn, want die heeft andere prioriteiten.

Sommige klanten beseffen niet dat elke ‘ja’ of ‘nee’ grote implicaties heeft, qua programmeertijd en kosten. Ze delen u hun beslissing mee, en komen er later op terug. In dit geval kan het soms helpen om de issue samen met de genomen beslissing af te drukken, en om een handtekening te vragen. De meeste mensen beseffen wel dat een handtekening bindend is.

Problems zijn alle andere openstaande punten.

Vanaf nu hebben we het gewoon over issues.

EEN TABEL OF EEN DATA BASE MET ISSUES
Hoe behoudt u het overzicht van de issues? Door ze in een tabel te plaatsen. Elk issue krijgt een volgnummer, en u noteert de datum, een (korte) titel, een (lange) omschrijving, en nog enkele gegevens.

Is de lijst enigszins overzichtelijk, dan kunt u werken met een tekstverwerker of met een rekenblad. Hebt u te maken met een groot aantal issues, die dan ook nog eens lang blijven openstaan, dan hebt u misschien meer aan een database. Dan kunt u namelijk selecteren en sorteren op bepaalde attributen van de issues.

DE BETROKKENEN BIJ EEN ISSUE
In de tabel noteert u ook de betrokken personen, om te beginnen degene die het probleem gemeld heeft, iemand van de businesskant of van de IT-kant. U bestudeert de vraag en wijst ze toe aan iemand van uw team. Een functionele change wordt toegewezen aan een analist, een business issue aan een user – die dan de betrokken manager aan de mouw moet trekken, tot die een beslissing neemt. Bent u van plan om met een betrokkene een onderhoud te hebben, dan maakt u vooraf een lijst van alle openstaande issues die hij gemeld heeft, of waar hij voor verantwoordelijk is.

DE STATUS VAN EEN ISSUE
Een nieuwe issue is natuurlijk open, en een afgehandelde issue is afgesloten, maar u kunt nog meer statuscodes gebruiken, als u dat wenst. Een mogelijkheid is: nieuw (en nog niet aan iemand toegekend), open, bezig, verworpen, goedgekeurd, uitgesteld.

HET TYPE
Waarschijnlijk wil u de issues klasseren in verschillende groepen. Dat kunt u, door aan elke issue een type toe te kennen. Desgewenst kunt u verder specifiëren met sub-types.

DE PRIORITEIT
Uw mensen zitten niet met hun duimen te draaien tot u met een issue aankomt. Integendeel, dit is onverwacht werk, dat niet op de planning stond, en de leverdatum van het project in gevaar brengt. Dus kent u prioriteiten toe aan issues. De eenvoudigste indeling is 1: hoog, 2: normaal, 3: laag.

EEN OVERZICHT VAN DE ISSUES
U overloopt regelmatig de openstaande issues, en spreekt met de betrokkenen. Daarvoor hebt u lijsten nodig, op het scherm of op papier, en dan is het handig als u met een database ge werkt hebt in plaats van met een gewone tabel. Dan kunt u de issues namelijk selecteren en sorteren op status, type, prioriteit.

Veelgebruikte lijsten zijn: Openstaande issues, Issues per type, Issues per status, Issues per verantwoordelijke, Issues met omschrijving en alle gegevens, Afgesloten issues.

DE OPLOSSING / DE BESLISSING
Misschien wilt u ook de oplossing van het probleem of de beslissing voor de issue registreren.

Mogelijke velden zijn dan
– beschrijving van de oplossing of de beslissing
– getest door (voor het geval van een programma-wijziging)
– getest op (datum)
– goedgekeurd door
– goedgekeurd op (datum)

DE BESTEDE TIJD
Misschien wil u ook de bestede tijd registreren.

Mogelijke velden zijn dan
– nodige tijd – schatting vooraf
– deadline (datum)
– nodige tijd – reële waarde
– datum waarop oplossing afgewerkt werd

Christiane Vandepitte (Christiane.Vandepitte@skynet.be) is zelfstandig consultant.