PortiBlog

SharePoint changes standaardiseren

1 augustus 2016

Al enige tijd liepen we binnen ons team bij de klant te brainstormen hoe we onze workload goed in kaart konden brengen. Naast de vragen die de business stelt en de trainingen die we geven zijn we verder veel bezig om bestaande SharePoint sites te herbouwen of aan te vullen of hele nieuwe sites op te bouwen. Hier was nog geen proces voor uitgewerkt.

Geen proces voor alle consultancy taken die we uitvoerden zorgde ervoor dat we niet in kaart hadden waar we mee bezig waren, hoeveel tijd er nog beschikbaar was9c1bea73591deb1b0c3c6e9eb02855b8 en er dus geen reële planning de business in kon voor het werk dat er nog lag. Voor een service verlenende afdeling is dat geen visitekaartje. Gelukkig spreek ik ondertussen in de verleden tijd.

De IT afdeling maakt gebruikt van changemanagement zoals we dat vanuit ITIL kennen, maar daar deed onze afdeling deels in mee. Waarom niet helemaal? Is een algemeen changeproces wel toereikend voor een SharePoint afdeling? Zijn er standaard doorlooptijden te definiëren? Een hoop vragen die bij mij opborrelden. Omdat we druk bezig waren om meer efficiency uit ons team te halen, heb ik het vormgeving van een changeproces, op mij genomen.

We kenden het changeproces al wel voor het intranet. Na het indienen van de change wordt een een risico en impact analyse gemaakt en daarna uitgewerkt via het ontwikkel/test/acceptatie/productie proces. Omdat het intranet de gehele organisatie betreft en de impact dus groot is, wordt het changeproces hier strak bij opgevolgd. Maar ik had zelf het idee dat een small change ook mogelijk zou moeten zijn binnen ons team.

Hierin ben ik begonnen met een gesprek met de changecoördinatoren. Om goed in kaart te brengen hoe het changeproces hier exact voor de IT afdeling verloopt en dan specifiek gericht op de kleine changes. Een vraag vanuit de coördinatoren was: 'Kun je de consultancy vragen gieten in een standaard change?' Je hebt dan te maken met een standaard doorlooptijd. Maar die ligt natuurlijk voor elk verzoek anders en hangt van de beschikbare resources af. Zou toch fijn zijn als we overal evenveel tijd voor nodig hebben!

Uiteindelijk hebben we een constructie opgezet waarbij we vanuit IT wel gebruik kunnen maken van een standaard SharePoint change waarbij de einddatum niet vast gesteld wordt op bijvoorbeeld vier weken. Bij het indienen van een change wordt wel een einddatum ingevuld maar deze wordt op een later moment bijgesteld naar de daadwerkelijke einddatum. Deze einddatum komt tot stand via requirementsessies.

Zodra de business nu een change indient wordt er een eerste afspraak gemaakt waarin het ingevulde formulier kort wordt doorgenomen om na te gaan of de vraag binnen de team duidelijk is. De business krijgt te horen hoe het changeproces binnen ons team verloopt en een grove schatting wanneer de geplande startdatum zal zijn. Na dit gesprek wordt intern in het team bekeken hoeveel resources we verwachten nodig te hebben en met welke expertise. Vaak zijn dat er twee, maar soms kan het ook alleen of hebben we meer mensen nodig.
Met de business word vervolgens een requirementsessie ingepland om met stakeholders de exacte vraag verder uit te werken. Na deze sessie wordt het functioneel ontwerp gemaakt en geven de uitvoerende collega's aan hoe lang ze voor deze change nodig achten en geven de einddatum aan. Na akkoord vanuit de business op het functioneel ontwerp, vult changemanagement ondertussen de change aan met de juiste einddatum. Omdat we naast changes ook de dagelijkse gang van zaken moeten blijven monitoren hebben we de afspraak dat we twee dagen per week aan een change kunnen werken over een tijd van ongeveer twee maanden, afhankelijk van de grootte.

Proces schematisch weergegeven

We gebruiken dit proces nu ongeveer een half jaar en we zijn als team erg te spreken over deze aanpak. We hebben beter in het vizier wat we aan het doen zijn en wat er nog moet gebeuren. Maar het meest positief is de business. Waarin ze voorheen direct na het indienen van de change werden 'geholpen', kregen ze vaak geen einddatum mee. Dit resulteerde in verzoeken die tot een jaar liepen en geen resultaat opleverden. Nu moet de business soms iets langer wachten voordat de eerste requirementsessie wordt ingepland, echter daarna hebben ze wel een beeld wat ze van ons kunnen verwachten. Deze duidelijkheid wordt als zeer positief ontvangen en bij navraag of de 'wachttijd' vervelend is, wordt dit niet zo ervaren.

Submit a comment