IT Management Blog: my thoughts about putting the "i" in IT

Resource planning

Resource planning is an essential aspect to doing projects. You need to do this however for a large part outside de project context or outside the control of the project management office. It will need to be done by the (operational) IT managers. I thought to write this down as I see too often that organisations still struggle with this. Though it will never be a stroll in the prak.

Projects come and go and are generally resourced partly through people from the existing operational teams and partly through temporary hiring. Projects are these days less about completely building something new and more about adding or changing something that already exists. Therefore it is important to use existing skills and knowledge.

Certain resources will work almost fully dedicated for the project for a longer period of time. Other resources will need to perform tasks intermittently and for shorter durations. Planning the latter group is the most difficult. Those people will work probably for many projects and will also have to perform operational support tasks.

Because the IT manager will know which person has the right skills to perform the required project tasks, it is the IT manager who will need to do the resource assignment. In fact, the IT manager has the responsibility to maintain the full resource planning for everyone within his team. Additionally, it is advised that project resources are also recruited and managed by the IT manager. In that case, he can assign some support staff to work on the project so existing knowledge can be leveraged for the project and some of the temporary staff can do support work.

With respect to resource planning, the IT manager will first of all need to make an estimate of the total amount of operational support work he has that needs to be performed. These tasks can be work related to:
  • Operational support tasks such as incident and problem management, fulfilling user requests, responding to system events, systems monitoring, service desk tasks, applying software patches, replacing faulty, etc.
  • Proactive support tasks such as upgrading software to a new versions, structural hardware replacement or implementing changes as requested by the users (all these activities could potentially be executed as projects).
  • Overhead tasks such as team meetings, training, holidays, sick days, etc.
This gives a baseline of the amount of resources that is minimally required. Certain tasks will require to be performed by people with specific skills. In those cases you will need to plan on an individual basis.

It is not always required to plan on the individual basis and you could maintain the information on the summary level.

The “ total available” gives insight in how much time is available for projects. If projects require more, you will need to insource additional people. If these resources work only for projects, then you could leave those people out of your operational resource planning and leave the management up the project manager or the project management office.

As you will perform multiple projects and will have multiple project managers, you will also have some project coordination through a project management office or something similar. 

When planning all your projects, you will need to ask yourself the question whether you will be able to perform all those projects. It happens unfortunately too often that certain resources are over-allocated by different projects because there was not overarching planning. Each project will have to make its own resource plan and the project management office will need to integrate those plans to see what the total project resource demand is per operational team or some cases per individual.

You will get a resource plan similar as you would have per team but instead of tasks you would haven projects. Each project manager will provide a single line item per resource or skill/team for the resource plan. You can then reorganise this demand to a demand per team. On a summary level, the total demand from all projects could be something like the table below.

If you then subtract the demand for a team from the availability, you see what is required for additional hiring of staff. Using the above examples, this is for team 1 as follows:

In this example, you will need an additional person with specific skills. Initially for 2 days per week, then for 1 day per week, then not at all and then you need this person again. That is unpractical. Usually you just can’t hire skilled people this way. Therefore you might need to adjust your project portfolio by either delaying or cancelling a project. Another option is to delay or cancel certain operational tasks.

Adjustments will need to be made continuously. You might need a Unix administrator only for 2 days at the end of the project. You will need to plan this into the resource planning but as we all know, projects run rarely according to the plan. You might even find out only a week before that you need to reschedule. Alignment between projects and the support tasks is needed. If you, as an IT manager, have been strict enough not to give away the time required for support tasks and have planned sufficient contingency into this, you will be flexible to accommodate these last minute changes. Instead of doing the support tasks next week, you do them this week. This flexibility can be obtained for a large part from the proactive tasks and less from tasks such as incident management.

What you definitely should not do is to ignore the issue and simply over-allocate the resources. What happens then is that support tasks are delayed or cancelled which over time will result in an increase in the number of incidents. What also will happen is that projects will take longer than planned and will be delivered with a lower quality. The latter will result in a higher number of incidents for the support teams to resolve.

Besides people, resource planning can also apply to the systems themselves. If you have 3 projects that all want to modify an existing component, all through the development, testing and production-deployment phases, you will need to align all these activities between the projects and support activities.

Verantwoordelijkheden en projecten

In elke organisatie zal er altijd onduidelijkheid en discussie zijn over de verantwoordelijkheden. Tegenwoordig zijn organisaties bijna continue aan het veranderen. Een heldere toelichting over hoe verantwoordelijkheden ‘werken’ kan de discussie over verantwoordelijkheden in betere banen leiden en kan ondersteunend zijn het vormgeven van de organisatie.

De theorie van verantwoordelijkheden
Bij het opzetten en aansturen van een organisatie is het van groot belang om een helder beeld te hebben hoe verantwoordelijkheden ‘werken’. De eerste stap is om niet te spreken over verantwoordelijkheden maar over ‘accountability’, ‘responsibility’ en ‘mandaat’.’
  • Accountability betekent aansprakelijkheid; eindverantwoordelijkheid.
  • Reponsibility betekent verantwoordelijkheid voor de uitvoering.
  • Mandaat is de bevoegdheid om in naam van een ander te handelen, maar zonder de daarbij horende verantwoordelijkheid.
Er is een derde vorm van verantwoordelijkheid en dat is via een contract of werkafspraken (eigenlijk een speciale vorm van mandateren).

Delegeren is het overdragen van bevoegdheden, inclusief de verantwoordelijkheid. Verantwoordelijkheden kunnen te allen tijde gedelegeerd worden binnen de eigen hiërarchie. Steeds met 1 stap naar beneden. Deze delegatie betekent enkel een delegatie van de ‘responsibility’ met de bijbehorende bevoegdheden. Je behoudt dan ten alle tijden de accountability. Die blijft altijd achter. Bijvoorbeeld een directeur heeft een verantwoordelijkheid die hij kan delegeren aan een divisiemanager. De directeur blijft accountable en de divisiemanager is dan responsible. Indien de divisiemanager dan weer delegeert aan een teamleider, dan wordt de teamleider responsible terwijl de divisiemanager accountable blijft. De directeur is dan ook nog steeds accountable.

Je kan niet zijwaarts in een hiërarchie delegeren. Want dan zou de manager van de persoon aan wie je zijwaarts hebt gedelegeerd ineens accountable worden. Bijvoorbeeld, een teamleider Netwerk & Datacenter kan niet delegeren naar een teamleider Servicedesk.

Je kan wel zijwaarts mandateren. Dus een bevoegdheid uitdelen. Je blijft zelf responsible. Zodra je dat doet, wordt de manager van degene aan wie je een mandaat hebt gegeven niet accountable. Mocht het blijken dat degene aan wie je het mandaat hebt gegeven, de taken niet goed uitvoeren, kun je in je hiërarchie escaleren tot je bij de eerste gemeenschappelijke manager terechtkomt die dan moet sturen.

Je kan ook intern een dienst verlenen en dit kan dus ook zijwaarts. Dit is een speciale vorm van mandateren waarbij je afspraken maakt of een ‘contract’ afspreekt. Het is dus van belang in deze afspraken ook sturingsmechanismen in te bouwen. Het concept is in feite niet anders dan wanneer je werkzaamheden extern uitbesteedt. Maar de partij die een dienst verleent en dus een mandaat verkrijgt van de verantwoordelijke (reponsible), zal in een goed georganiseerde organisatie een verantwoordelijkheid hebben gekregen van zijn manager om een goede dienst te verlenen. Dus middels deze afspraken heb je als dienstverlener een responsibility op je genomen en dat betekent dat jou manager daarvoor accountable is.

Toegepaste theorie
De volgende partijen ondervinden dagelijks in hun werkzaamheden de consequenties wanneer er onduidelijkheden zijn omtrent verantwoordelijkheden:
  • Projectleiders
  • Servicemanagers
  • Proceseigenaren (procesmanagers)

Verantwoordelijkheden projectleiders versus lijnmanagers
Een projectleider krijgt zijn verantwoordelijkheden om een projectresultaat op te leveren van zijn opdrachtgever. Meestal een stuurgroep en van al deze leden kan hij verantwoordelijkheden gedelegeerd krijgen.

Om een project uit te voeren, zal de projectleider meestal mensen vanuit de lijn moeten aansturen. Dit is een zijwaartse stap en derhalve gaat dit om een mandaat die hij moet krijgen van de betreffende lijnmanager. Als deze lijnmanager hiërarchisch onder een stuurgroeplid valt, krijgt de lijnmanager, als het goed is, een opdracht die aansluit bij deze van de projectleider. Als deze lijnmanager niet hiërarchisch onder de stuurgroep valt, dan kan dit een probleem opleveren aangezien de lijnmanager wellicht andere instructies en prioriteiten ontvangt. Vandaar dat het dus van belang is om de stuurgroep zo vorm te geven dat het merendeel van de benodigde resources voor het project hiërarchisch onder de stuurgroepleden hangen.

Een praktisch probleem is in veel gevallen dat de tweezijdige aansturing van zowel de projectleider als de lijnmanagers vanuit de stuurgroep niet altijd consistent is en dat er daardoor onduidelijkheid ontstaat over de aansturing van de resources door het project.

De uiteindelijke responsibility van de aansturing van deze resources blijft bij hun directe teamleider. Mochten resultaten en voortgang onvoldoende zijn, dan heeft de projectleider enkel de weg naar de stuurgroep om hier iets aan te doen.

De verantwoordelijkheid van de projectleider hangt af van het werkmodel dat aangehouden wordt. Er zijn in principe 3 werkmodellen te onderkennen:

1. De projectleider zet een werkpakket uit bij een lijnmanager
De projectleider is dan alleen responsible voor het “wat” en “wanneer klaar” en niet voor het “hoe”, “waarmee”, “wie” en “wanneer doen” dat bij de lijnmanager ligt. De lijnmanager committeert zich aan het “wanneer klaar”.  De projectleider geeft het mandaat aan de lijnmanager om de tijd en het geld te besteden.
De lijnmanager heeft de volledige controle over hoe en met welke kwaliteit het deelproduct wordt opgeleverd en is dus “responsible” voor het leveren van een dienst conform de afspraken. Bij problemen kan de projectleider de manager van de betrokken lijnmanager aanspreken, aangezien deze een accountability heeft t.a.v. de responsibility van de lijnmanager.
Aangezien normaal gesproken deze lijnmanager aan het eind van het project het deelproduct ook in beheer krijgt, is dit een werkmodel met vele voordelen. Het vraagt de lijnmanager echter wel om extra planning- en aansturingsinzet te leveren. De projectleider is er dan verantwoordelijk om op werkpakketniveau te coördineren en voor coherentie in het geheel te zorgen.

2. De projectleider krijgt medewerkers en middelen toegewezen door de lijnmanager.
De projectleider is dan verantwoordelijk voor het “wat”, “wanneer” en ten dele voor het “waarmee”, “wie” en “hoe” waarvoor een gedeelde verantwoordelijkheid is.
De lijnmanager geeft de projectleider het mandaat om zijn mensen voor de afgesproken inzet aan te sturen.
De projectleider heeft dan meestal beperkte keuze over de selectie van de medewerkers en de wijze waarop en de middelen waarmee gewerkt worden, worden veelal door de lijnmanager bepaald. Deze gedeeltelijke verantwoordelijkheid levert vaak verwarring en problemen op. Met name wanneer andere activiteiten die door de betreffende medewerkers moeten worden uitgevoerd, de voortgang van het project verstoren.
De lijnmanager kan zich wel eens niet verantwoordelijk voelen voor het project, de voortgang en de resultaten. De aansturing vanuit de stuurgroep via de hiërarchie richting de lijnmanager om zich aan het project te committeren wil nog al eens haperen.
Over het algemeen gesteld kan je in dit model ervan uit gaan dat de lijnmanager zal moeten bepalen over “hoe” het project wordt uitgevoerd, aangezien dit een vakinhoudelijk aspect is en de projectleider over het algemeen deze kennis niet heeft.
De overdracht van het projectresultaat aan het eind van het project gaat in dit werkmodel vaak impliciet maar kan makkelijk problemen leveren wanneer er iets niet goed is aan het projectresultaat.
Bij problemen wordt escalatie in de lijn door de projectleider lastig. Vandaar dat er veelal teruggevallen wordt direct te escaleren naar de stuurgroep.

3. De projectleider huurt zijn eigen medewerkers en middelen in.
De projectleider is dan verantwoordelijk voor het “wat”, “wanneer”, “hoe”, “waarmee” en “wie”. De projectleider is dan niet enkel verantwoordelijk voor de sturing van het proces maar ook expliciet voor het gehele projectresultaat.
De lijnmanager is natuurlijk een stakeholder die requirements m.b.t. het operationeel beheer aanlevert, maar is verder niet bij het project betrokken.
De lijnmanager neemt het projectresultaat wel in beheer bij het beëindigen van het project en dat is het moment dat de verantwoordelijkheden worden overgedragen van projectleider naar lijnmanager.
In dit werkmodel is een groot risico dat de overdracht naar het operationele team als onderdeel van het project onvoldoende is. Hierdoor kan de lijnmanager achteraf in de problemen komen.
Op het moment dat een projectleider namens een opdrachtgever een gedelegeerde verantwoordelijkheid heeft gekregen om een project uit te voeren, heeft de directe teammanager in de hiërarchie van de projectleider nog geen accountability over het project gekregen. Hij is er hoogstens accountable voor dat deze projectleider bepaalde vaardigheden heeft en, indien dit zo is vastgelegd, de projectleider aanstuurt om het project op een bepaalde manier uit te voeren. De projectleider wordt ‘ingehuurd’ door de opdrachtgever.

Verantwoordelijkheden servicemanagers versus lijnmanagers
Voor een servicemanager geldt in feit hetzelfde. Op het moment dat bijvoorbeeld een dienst aan een klant wordt aangeboden, heeft hij een gedelegeerde verantwoordelijkheid gekregen om de dienstverlening aan te sturen. Echter de verantwoordelijkheid voor vele aspecten van de uitvoering van deze dienst, zoals het hoe, wat, wie en waarmee, ligt bij de lijnmanagers.

Een servicemanager heeft derhalve de verantwoordelijkheid om ervoor te zorgen dat het geheel aan diensten dat door de lijnmanagers geleverd wordt, een coherent geheel vormt en de gevraagde dienst conform afspraken voor de klant realiseert.

Indien de dienst naar de klant niet goed functioneert, zal de servicemanager de lijnmanager erop moeten aanspraken en eventueel de afspraken met de lijnmanagers aanpassen.

Het risico bestaat dat de servicemanager de individuele teamleden gaat aansturen. In geval van incidenten en crisissituaties is dit begrijpelijk, echter hierbij kan snel verwarring ontstaan, net zoals bij het werkmodel 2 voor de projectleiders.

Een servicemanager bewaakt over het algemeen de service level agreement (SLA) die de organisatie heeft met de klant. In feite zijn de diverse lijnmanagers verantwoordelijk voor delen van deze SLA.Als deze delen helder zijn vastgelegd, zou dit kunnen vergelijken met werkmodel 1 voor projectleiders. Onderling hebben de diverse lijnmanagers, als het goed is, duidelijke afspraken in, bijvoorbeeld, operational level agreements (OLA's). De servicemanager kan samen met de klant ook operationele afspraken maken met de lijnmanagers ten behoeve van de operationele aansturing van de dienstverlening als aanvulling ten aanzien van de SLA. De SLA beschrijft het "wat" en de operationele afspraken het "hoe".

Verantwoordelijkheden proceseigenaren versus lijnmanagers
Ook voor proceseigenaren (procesmanagers) geldt een equivalente situatie als bij de servicemanagers. We spreken dan niet over een dienst maar over een proces.

In de procedures en werksinstructies wordt dan duidelijk vastgelegd wie waar verantwoordelijk voor is. Als dit goed is uitgewerkt zou je dit kunnen vergelijken met werkmodel 1 voor projectleiders. De uitdaging die de meeste organisaties hebben, is dat dit vaak onvoldoende is uitgewerkt en waardoor er onduidelijkheden zijn.

Helder vastleggen van verantwoordelijkheden en afspraken
Proceseigenaren, servicemanagers en projectmanagers sturen hun taken aan via onderlinge afspraken en dus via een mandaat of werkafspraken.

Ook worden verantwoordelijkheden overgedragen en het is van groot belang dat deze momenten van overdracht duidelijk zijn geformuleerd. Bijvoorbeeld bij het beëindigen van een project, komt een moment dat een bepaald aspect van de verantwoordelijkheid wordt overgedragen van de projectleider naar de servicemanager en een ander aspect weer naar de lijnmanagers.

Omdat deze overdrachtsmomenten een standaard onderdeel vormen van de bedrijfsvoering van DICTU, kunnen de basisprincipes eenmalig centraal worden vastgelegd. Maar per project of systeem zullen er ook speciale verantwoordelijkheden moeten worden overgedragen of vastgelegd. Dit kan dan bijvoorbeeld middels beheerdocumentatie, service levels, procedures, werkinstructies, werkafspraken of overdrachtsformulieren.

Daarnaast gaat de organisatie steeds meer de vorm aannemen waarbij onderling diensten worden aangeboden. Ook daarbij is het van belang om helder inzicht te hebben in het verloop van de verantwoordelijkheden en de mandatering. Als diensteverlener moet je duidelijkheid hebben wat je eigen verantwoordelijkheid is die je vanuit de hiërarchie hebt verkregen en welke bevoegdheid je gemandateerd hebt gekregen en waarbij de verantwoordelijkheid nog bij de ‘klant’ ligt. Let daarbij op dat de ‘klant’ het mandaat dus ook weer kan intrekken.

Het is dus van groot belang dat naast het vastleggen van verantwoordelijkheden van proceseigenaren, servicemanagers en projectleiders, ook de verantwoordelijkheden van de lijnmanagers worden vastgelegd en dat daarnaast ook de onderlinge afspraken en overdrachtsmomenten worden vastgelegd. Zonder een heldere en eenduidige vastlegging van deze vier elementen gaat een organisatie niet effectief werken.