Problemen oplossen in innovatieprojecten:

De rol van projectorganisatie

Versie 1.3 – Februari 2010

Rotterdam School of Management, Erasmus University

Dr. Ferdinand Jaspers

Prof. Dr. Ir. Jan van den Ende

Contactgegevens

Dr. Ferdinand Jaspers

Rotterdam School of Management, Erasmus University

Kamer T11-45

Postbus 1738

3000 DR Rotterdam

T. 010-4082875

E. fjaspers@rsm.nl

2

INLEIDING

De ontwikkeling van software staat bekend als een moeilijk proces. Dit geldt zeker ook

voor webapplicaties, omdat deze steeds complexer en geavanceerd worden (Rich Internet

Applications, Web 2.0). Hierdoor is het waarschijnlijk dat projectteams tijdens de

ontwikkeling van webapplicaties worden geconfronteerd met technische problemen.

Deze problemen zorgen ervoor dat het vaak een grote uitdaging is om deadlines te halen,

om kosten in bedwang te houden en om productspecificaties te realiseren. Zo moeten

applicaties wellicht (deels) worden herontworpen, moet programmeerwerk worden

overgedaan en moet het eindresultaat opnieuw - en in meer detail - worden getest.

Wij stellen daarom dat het van groot belang is dat projectteams bekwaam zijn in het

oplossen van problemen. Het liefst worden problemen natuurlijk snel, efficiënt en

effectief opgelost. De vraag is nu hoe u als manager kunt bijdragen aan de vaardigheid

van projectteams om problemen op te lossen. Onze onderzoeksvraag is de volgende:

A. Hoe kan het vermogen van projectteams om problemen op te lossen worden verklaard

door de manier waarop teams zijn georganiseerd?

Zoals hieronder zal worden betoogd, kunnen we een onderscheid maken tussen

verschillende soorten van technische problemen, en dan met name de mate waarin

problemen te maken hebben met interfaces tussen softwareonderdelen (‘systemische

problemen’) dan wel met softwareonderdelen (modules) zelf (‘autonome problemen’).

Daarom vragen we ons af:

B. In hoeverre hangt het effect van projectorganisatie op het probleemoplossend

vermogen van het team af van het type problemen waarmee een team wordt

geconfronteerd?

Bovenstaande vragen worden hieronder geïllustreerd weergegeven.

Projectorganisatie

Decentralisatie

Gemak van onderlinge communicatie

Gebruik van externe informatie

Onderling contact

Formalisatie van projectvoortgang

Autonomie van het project

Commitment van het projectteam

Cross-functioneel team

Bekwaamheid waarmee problemen

worden opgelost

Kwaliteit van oplossingen

Kosten van oplossingen

Snelheid van oplossingen

Systemische versus autonome

problemen

3

HET ONDERZOEK

Hier volgt kort enige informatie over de gegevens op basis waarvan de resultaten tot

stand zijn gekomen.

• De gegevens zijn via een on-line vragenlijst verzameld in de tweede helft van 2007.

• In elke vragenlijst staat een ontwikkelingsproject van een Internetapplicatie centraal.

Dit project is als volgt gedefinieerd:

Het “ontwikkelingsproject” bestaat uit alle taken die nodig waren om de

webapplicatie te realiseren. Deze taken betreffen bijvoorbeeld het ontwerpen van de

applicatie en het ontwikkelen, aanpassen, verbinden, en testen van verschillende

hardware en software “onderdelen,” zoals applicatiesoftware, databases, servers,

content, etc. Het ontwikkelproject heeft geen betrekking op de introductie, de

marketing en de “live” fase van de applicatie, maar uitsluitend op de ontwikkeltaken

van de start van het project tot de eerste echte (commerciële) introductie en

lancering.

• De vragenlijsten zijn ingevuld door projectmanagers.

• De ‘populatie’ die in het kader van dit onderzoek is benaderd bestaat uit drie groepen:

o Projecten die zijn gesubsidieerd binnen Kenniswijk;

o Complexe projecten die zijn uitgevoerd door/met medewerking van

Internetbureau’s die lid zijn van PIBN (Platform Internet Bureau’s Nederland

en/of voorkwamen op de lijst van 100 ‘beste’ ICT bedrijven volgens de

Emerce Top 100 2005;

o Projecten waarvan in de afgelopen twee jaar melding is gemaakt via de

website Planet Multimedia.

• De resultaten zijn gebaseerd op gegevens van 92 projecten.

• Dit is een response rate van 60%. Daarmee zijn de resultaten van dit onderzoek naar

verwachting van de auteurs sterk representatief voor de relaties in de populatie als

geheel.

4

RESULTATEN

A. Het effect van projectorganisatie op probleemoplossend vermogen

Op basis van onze analyse van 92 innovatieprojecten kunnen we het volgende stellen:

1. Uit ons onderzoek blijkt dat het voor het oplossen van problemen van groot belang is

dat teamleden gemakkelijk en open met elkaar communiceren en informatie delen.

Dit is niet alleen positief voor de kwaliteit van de oplossingen, maar ook voor de

snelheid en de kostenefficiëntie waarmee problemen worden opgelost.

2. Ook blijkt het belangrijk te zijn dat projectmedewerkers over voldoende vrijheid

beschikken om problemen naar eigen inzicht op te lossen. Projectleden worden

hierdoor extra gemotiveerd om zich (creatief) in te zetten voor het oplossen van

problemen. Naarmate teamleden over meer vrijheid beschikken worden problemen

over het algemeen effectiever opgelost (projectleiders zijn meer tevreden over de

kwaliteit van de oplossingen) en ook met minder kosten. Uit ons onderzoek blijkt

bovendien dat deze voordelen niet ten koste gaan van de snelheid van het project.

3. Projectteams maken in meer of mindere mate gebruik van kennis en informatie van

buitenaf. Externe kennis kan bijvoorbeeld worden vergaard door overleg met

leveranciers, door het bezoek van conferenties, door marktontwikkelingen

nauwlettend in de gaten te houden, etc. Voor het vermogen van projectteams om

problemen op te lossen blijkt het over het algemeen weinig uit te maken of dit team

‘open’ of ‘gesloten’ is voor inzichten van buitenaf. Hieronder zullen we dit algemene

beeld nuanceren en concluderen we dat het onder specifieke omstandigheden wel

belangrijk is om extern kennis en informatie te vergaren.

5

B. Verschillende soorten problemen

Niet alle problemen zijn identiek en verschillende problemen vragen om een andere

manier van problemen oplossen. Een belangrijk onderscheid kan worden gemaakt tussen

autonome problemen en systemische problemen. Autonome problemen hebben

betrekking op individuele onderdelen (modules) van een webapplicatie en deze kunnen

worden opgelost zonder dat dit consequenties heeft voor andere modules. Systemische

problemen hebben juist betrekking op meerdere modules tegelijkertijd en wellicht op de

gehele applicatie. Deze problemen vereisen bijvoorbeeld een compleet herontwerp van de

applicatie of het opnieuw afstemmen van interfaces tussen verschillende modules.

Hoewel systemische problemen betrekking hebben op een groter deel van de applicatie,

wil dit niet zeggen dat autonome problemen makkelijker op te lossen zijn of dat

autonome problemen minder verstrekkende gevolgen kunnen hebben! Autonome

problemen kunnen er namelijk gemakkelijk voor zorgen dat de applicatie als zodanig niet

aan de eisen voldoet. Bovendien is wellicht zeer gespecialiseerde kennis nodig om de

desbetreffende applicatiemodule te verbeteren.

Afhankelijk van het type probleem dat een projectteam over het algemeen moet oplossen

(overwegend autonome problemen in het ene uiterste en overwegend systemische

problemen in het andere uiterste) blijken verschillend georganiseerde projecten succesvol

te zijn in het oplossen van problemen:

• Uit ons onderzoek blijkt bijvoorbeeld dat de kwaliteit van oplossingen voor

systemische problemen over het algemeen erg laag is als de leden van het projectteam

relatief weinig contact hebben met elkaar. Systemische problemen hebben immers

betrekking op meerdere onderdelen van de applicatie en daarom is veel onderling

contact nodig om onderlinge afhankelijkheden te identificeren en om taken af te

stemmen. Teams met weinig onderling contact zijn met name geschikt voor het met

hoge kwaliteit oplossen van autonome problemen. Dit is te verwachten: autonome

problemen hebben betrekking op een enkel onderdeel van een applicatie en hebben

dus weinig gevolgen voor teamleden die verantwoordelijk zijn voor andere taken.

• Ook het type projectmanager blijkt verschillende effecten te hebben onder

verschillende omstandigheden. Een projectmanager met grote autonomie om zelf

beslissingen te nemen (zonder daarbij afhankelijk te zijn van bijvoorbeeld top

management) blijkt positief bij te dragen aan het snel oplossen van systemische

problemen. Een verklaring is dat projectmanagers met veel beslissingsbevoegdheid

over het algemeen veel ervaring hebben en veel kennis bezitten. Vooral voor het snel

bedenken en implementeren van oplossingen voor systemische problemen is grote

kennis vereist van de architectuur van de applicatie en van de relaties tussen de

verschillende onderdelen. Bovendien moeten hierbij wellicht afwegingen worden

gemaakt over hoe de verschillende productonderdelen moeten worden aangepast. Ook

moeten de taken van de betrokken teamleden worden gecoördineerd. Relatief sterke

en ervaren projectmanagers lijken dit soort processen sneller te managen dan

managers met relatief weinig autonomie.

6

• We vinden ook dat systemische problemen efficiënter worden opgelost als

projectmedewerkers grote vrijheid hebben bij het uitvoeren van hun taken.

Systemische problemen hebben betrekking op meerdere applicatieonderdelen en het

implementeren van oplossingen vereist dan ook inspanningen van meerdere

teamleden. Voor projectmanagers is het onmogelijk om de taken van al deze

teamleden in detail te specificeren. Daarom lijken onze resultaten aan te duiden dat

het projectmanagement oplossingen voor systemische problemen dusdanig moeten

formuleren dat individuele teamleden grote vrijheid hebben bij het uitvoeren van hun

taken, maar dat dit tegelijkertijd tot een coherente oplossing leidt.

• Tot slot rapporteren wij een interessante bevinding wat betreft de mate waarin

projectteams bij het oplossen van problemen informatie en kennis van buiten hun

team en moederbedrijf halen. Hiervoor blijkt een sterke afweging te bestaan tussen de

kwaliteit van oplossingen enerzijds en de efficiëntie van het oplossen van problemen

anderzijds. Voor het oplossen van autonome problemen met hoge kwaliteit blijkt het

waardevol te zijn om informatie van buiten te betrekken. Voor systemische

problemen blijkt een sterke focus op externe bronnen van kennis juist te resulteren in

oplossingen van lagere kwaliteit. De verklaring is dat extern, zoals bij leveranciers,

universiteiten en andere experts, vooral kennis aanwezig is over individuele

technologieën. Extern is veel minder gedetailleerde kennis aanwezig over hoe

verschillende technologieën zijn gerelateerd. Het gedetailleerde ontwerp van een

applicatie en de specifieke relaties en afstemming tussen modules is vaak maatwerk.

Extern zoeken naar waardevolle informatie is dus vooral effectief voor autonome

problemen en dit is veel minder het geval voor systemische problemen. Hoewel

extern zoeken sterk bijdraagt aan de kwaliteit van oplossingen voor autonome

problemen, blijkt dit sterk samen te hangen met flink duurdere oplossingen. Het is

bijvoorbeeld duur om experts en leveranciers in te huren, om licenties te nemen en

tevens kost het middelen om de externe kennis zelf meester te maken en te benutten.

Met andere woorden: autonome problemen kunnen door projectteams zelf worden

opgelost. Dit is dan vaak relatief goedkoop, maar gaat gepaard met lagere kwaliteit.

Het omgekeerde is ook waar: betere oplossingen worden gerealiseerd met behulp van

externe kennis, maar dit is flink duurder.

Voor systemische problemen geldt de tegenovergestelde afruil. Zonder gebruik te

maken van externe kennis worden overwegend betere oplossingen gegenereerd door

projectteams, maar dit gaat dikwijls gepaard met hoge kosten. De verklaring hiervoor

is dat kwalitatief hoogwaardige oplossingen voor systemische problemen zeer

gedetailleerde kennis vereisen van het productontwerp en van de onderlinge relaties

en afhankelijkheden van de verschillende componenten en technologieën. Deze

kennis kan moeilijk van externe partijen worden betrokken, maar om deze kennis

intern te ontwikkelen zijn doorgaans flinke investeringen nodig. Zo moet veel worden

overlegd tussen teamleden en zijn wellicht behoorlijk wat testen en parallel

programmeerwerk nodig om gedetailleerde ‘systemische kennis’ te ontwikkelen.