Elke innovatieteam wordt geconfronteerd met onverwachte problemen. Het is belangrijk dat teams problemen snel, efficient en effectief oplossen. Niet alle problemen zijn echter hetzelfde. Sommige problemen zijn 'systemisch' ("alles is op elkaar van invloed"), andere problemen juist autonoom (losstaand). Dit rapport gaat in op de vraag: hoe zijn projectteams georganiseerd die problemen succesvol oplossen?
More than Just Lines on a Map: Best Practices for U.S Bike Routes
Innoveren = problemen oplossen
1. 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
Bekwaamheid waarmee problemen
Decentralisatie worden opgelost
Gemak van onderlinge communicatie
Gebruik van externe informatie Kwaliteit van oplossingen
Onderling contact Kosten van oplossingen
Formalisatie van projectvoortgang Snelheid van oplossingen
Autonomie van het project
Commitment van het projectteam
Cross-functioneel team
Systemische versus autonome
problemen
2
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.
3
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.
4
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.
5
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.
6