Thursday, December 8, 2016

Verantwoordelijkheden en projecten


Introductie
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, is krijgt de lijnmanager, als het goed is, een aansluitende opdracht als de projectleider heeft gekregen. 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 aansturin 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

Saturday, December 19, 2015

Project Management Framework

Anywhere I go, I notice that there are always options to improve the project management framework that the organisation uses. Despite the increased popularity of agile methods, classic project management remains important and relevant.

Via the attached link, you can find a document that shows a project management framework mapped to the products of the system development life cycle. Specifically because this SDLC varies per project type. In the document I have included 2 variations for this. One for infrastructure projects and one for application delivery projects.

You can adapt this model to your needs. You can add more variations. You can specify which products will be mandatory and which optional. You can also adjust what the level of planning accuracy will be required per phase. And of course you can add and remove phases, products, etc. It's just a starting point, but the structure has the advantage of giving in a single picture the whole approach and which products to deliver.







Saturday, December 20, 2014

Big data? well, try to get little data right first

National Australia Bank reminds me of a football team mate of a long time ago. When he asked you if you wanted a beer and you said no, he would give you one. If you said yes, he would give you three.

NAB sends a banks statement by mail even if we said we don't need one and will get them online. If  we say we want one, we get two. They just can't get it right. Somewhere in their computer system they have missed the concept of the shared account. We have tried to rectify this a few times, but without success.

The dutch ABNAMRO bank is not much better. They have problems creating a new account for my son because his details sit somewhere deep in the system. Staff can't find him when you call their helpdesk or visit a branch. But the account can't be created. We'll give it one more try.

If companies can't get their basics right, they should be careful with trying to be smart with big data. Of course a single error does not matter too much when driving market trends or bother people with so called targeted personalised advertising.

But even the specialist organisations can get things horribly wrong. The dutch bureau of stastics (CBS) sent my son a survey relating to his driving experience one and a half year before his legal driving age. I won't repeat what I said when I saw this letter.

The problem with the bank examples are probably bad user interface design or bad information architecture. Besides this, probably a bit of uncaring employees who don't want to go all the way to provide a good service, both during building and maintaining the system as during customer service.