Are KPI’s blocking improvement in project management?

A lot of effort is done in organizations to improve performance. Introducing project management is one of them. I have experienced the introduction of a lot of KPI’s in this field. But in parallel I see also a lot of disappointing results. In my view the usage of KPI’s is not always helping but constraining organizations in the performance improvement. Let me show you why KPI’s don’t help and also give you a direction of the solution.

It is well accepted to control projects on budget, time and scope. Nothing wrong with that. As long as we do this on project level. But, what happens is that these KPI’s are getting deployed to individuals. They are used to control employees on activity level. You have to deliver the activity on time, you have to explain why you used 40 hours instead of the 30 hours estimated. KPI’s on activity level become targets. People respond immediately to targets. They try to protect themselves against failure of meeting the targets. In this struggle between management and employees the result is typically more detailed planning and control. Eventually this proces will only increase projects duration and budget.
A lot of managers think detailled planning and control is the best way to improve a project management environment, but it is not. It will make it even worse. Funny thing is that software suppliers support this micro direction.

Let’s reflect on the situation. In project management the level of uncertainty is high. The scope is not completely clear and estimation of needed budget and time is complicated. In such a situation detailled planning and control is not going to help. Instead, we should give people information which will help them to make better decisions. In the 80-ties Decision Support Systems (DSS) were introduced. I plea to re-introduce the concept of DSS in its pure form.

Let me give an example with the following graph.

figure 1. Historical development of the capacity (Blue), load (Red) and output (green) of a group.

The information in the graph shows that in the beginning, the group achieved an output of 2 man-hours per hour (green line) while the capacity was 4.8 and the estimated load was 6! This load is the total amount of work coming to this team from all active projects. In the KPI-world the group had to defend themselves why they did not achieve an output of 6 or at least 4.8 man-hours per hour.
I would like to turn it around. Let’s use this information as a DSS and start a discussion within the group about the needed versus realized output. The objective is to balance the load and output. The group responded as follows. First they tried to focus more on their work. They did this by reducing the amount of distraction coming from outside the projects. Within 2 weeks the output immediately improved to more than 3 man-hours per hour. After this the group discussed with management to reduce the total load to the level of the assumed capacity. As they were not any longer overloaded, they were able to even further improve the output.
What we see is that the information shown in this graph can actually help people to solve situations of overload combined with the associated poor productivity. The information will help them to immediately see the effect of any interventions. It is really supporting the right decisions. In this case the output more than doubled! Just to make sure, this graph is not made up, this actually happened at our customers.
In order to support our claim to stop using KPI’s / targets on personal level and to go back to Decision Support Systems, co-owner Albert Ponsteen and myself both started a PhD research study to investigate this hypothesis. So far our clients have substantiated the hypothesis. And they love the results.
As a closing remark, the graph above is coming from our DSS software FLOW MPM which is connected to ERP, PPM or Workflow systems from our clients. Typically all the needed data is already available in the databases from our clients. This means fast implementations and relatively small impact on the way people work with their current systems.

Jan Willem Tromp

Symptoom of Systeem bottleneck, maakt het wat uit?

Let’s start with a definition of the subject bottleneck: “A resource whose capacity is less than the demand placed upon it.” (Apics).

Let me give an example. In an engineer to order (ETO) company the production department has to catch up to deliver on time. Instead of 10 craftsmen they need 16. But they only have 12. According to the definition above, production is a bottleneck. Or sometimes I hear that the project is or has a bottleneck. Quite often companies come into a situation that they need more capacity in production and efficiency drops down. Any recognition?

What is the real problem in this situation? You should be able to find out if production is a symptom or system bottleneck. Production is a bottleneck in the example above. But was there a department that caused the delays because they had insufficient resources. In my 20 year of experience in ETO companies, I noticed that quite often the engineering department is the system bottleneck. But they are not aware of it. Why not? Because the delivery moment is still far away.

What will happen if you improve a symptom bottleneck instead of a system bottleneck? For this I can use examples from our simulator. In the graphs below you will notice that 3 departments (Yellow, Green and Orange) have a demand that is almost or even more then their capacity. (The line above 1 means demand is higher then capacity). What will happen if we extend capacity in just one department.
First we will show the development without any intervention.

figure 1. Development of the load on all departments. No intervention.

We see that Yellow, Green and Orange are becoming bottlenecks. In total 63 projects were delivered. Let’s add more capacity to department Orange on day 110.

figure 2. Development of the load on all departments. On day 110 we doubled the capacity on Orange.

We see that the load on Orange decreased till 50%. But Yellow and Green did not improve and the total amount of projects delivered stayed on 63. Conclusion. Orange is a symptom bottleneck. Let’s do it again but now add more capacity to department Green on day 110.

figure 3. Development of the load on all departments. On day 110 we increased capacity with 50% on Green.

We see that the load on Green decreased till 66%%. But Yellow and Orange did not improve and the total amount of projects delivered stayed on 63. Conclusion. Green also is a symptom bottleneck. Let’s do it again but now add more capacity to department Yellow on day 110.

figure 4. Development of the load on all departments. On day 110 we increased capacity with 50% on Yellow.

Bullseye, we have found the system bottleneck. And because we reduced the load on Yellow to 66% the effect was that the flow of work in department Yellow went up, no more delays and because of that the other departments could start earlier with their work. In the figure below you can find the network structure of the projects we use in our simulator.

figure 5. Network structure projects

It becomes clear that if department Yellow is delaying, Green and Orange can start later.

The effect of increasing the capacity on Yellow the load in Green and Orange will also go down because they can start earlier and not loosing capacity. At the end the company has delivered 66 instead of 63 project.

Symptom or System bottleneck, Yes is does matter a lot.

With our concept FLOW MPM you can check your organization on the development of a System bottleneck now and in the future. Bare in mind that a System bottleneck is not always stable. You have to scan the situation constantly. FLOW MPM is delivering you all the needed information. Just connect our FLOW MPM tool to your ERP, Project Management or Workflow System. We know that the needed data is already in your system available.

Jan Willem Tromp

Weet u waar u momenteel staat met de efficiency van uw organisatie?

Onderstaande grafiek gebruik ik vaak in gesprek met klanten die in een multi project omgeving zitten. Het is geen wetenschap maar een discussie instrument. Ik zal hieronder uitleggen hoe het gesprek gaat.

Op de X-as staat de belading uitgedrukt in manuren per uur. Deze belading komt voort uit het werk en milestones van alle lopende projecten.
Op de Y-as staat de productie in manuren. Dat is het niveau wat de organisatie oplevert.
Linksonder is de belading nog nul en daarmee ook de productie. Als de belading toeneemt mag je ervan uitgaan dat de productie ook toeneemt tot het hoogste niveau van verwachte productie. U heeft nu de optimale efficiëntie bereikt. Als uw mensen nog meer beladen worden, dan zal na verloop van tijd de productie afnemen. Vooral in multi project omgevingen is dit goed zichtbaar. Bij zware overbelading zal de productie zelfs instorten. Wij noemen dit de blokkade van de FLOW.

Het is ook mogelijk dat bij een bepaalde belading (rode stippellijn) de verwachte productie niet gehaald wordt. Er is een probleem. Dit duidt meestal op een bottleneck die de oorzaak is dat ondanks een goede belading de verwachte productie niet gehaald wordt.

Onze methodiek FLOW Multi Project Management zoekt continu naar het niveau van de optimale efficiency. Wij informeren managers bij afwijkingen (bottlenecks) en overbelading. Hierin zijn wij uniek in de markt.

Jan Willem Tromp

voor meer informatie:
http://www.glow-management.com

Relaas van een multi project bedrijf

Willy Pottier van Packo is een klant van mij en heeft in een interview zijn ervaring weergegeven van een echt multi project bedrijf. Packo maakt fantastisch mooie producten voor de food en pharma industrie. Daarnaast heb ik Packo ervaren als een warm bedrijf. Was een eer om met hen te mogen samenwerken. Voor iedereen die de problematiek van een multi project bedrijf wil ervaren, is dit interview zeker een aanrader.

Het interview is afgenomen door Jaap van Ede, redacteur van procesverbeteren.nl

voor het lezen van het volledig artikel met je registreren met onderstaande inlogcode:

user Jan Willem_Student
pw Packo2014

http://www.procesverbeteren.nl/TOC/Packo_Inox_TOC.php

Effect project overbelading desastreus. Hoe dit te voorkomen?

Wetenschappelijk onderzoek (Zika-Vitorsson et.al 2006) toont aan dat project overbelading in een multi project omgeving wordt veroorzaakt door 4 factoren: gebrek aan een herstelperiode, tijdsdruk voor medewerkers, gebrek aan routines en aantal projecten waaraan gelijktijdig gewerkt wordt. 

Project overbelading leidt vervolgens tot afnemende prestatie, psychologische druk en afnemende competentie ontwikkeling.

Deze conclusies zijn voor mij zeer herkenbaar. Ik zie dit meermaals bij mijn nieuwe klanten. Velen denken dat portfolio management de oplossing is, maar komen niet verder dan het strategische niveau. Naar mijn inzicht is het van belang dat organisaties meer aandacht gaan besteden aan multi project management (het tactische en operationele niveau van portfolio management). Engwall en Jerbrant (2003) beschouwen resource allocatie als de belangrijkste uitdaging in een multi project omgeving. 

FLOW Multi Project Management (MPM) ondersteunt organisaties continu met het balanceren van de project druk in verhouding tot de actuele beschikbaarheid van mensen. Daarnaast helpt FLOW MPM met het prioriteren van de projecten en activiteiten. Onze klanten tonen aan dat deze balancering leidt tot een hogere kwaliteit, snelheid en output van projecten. 


Jan Willem Tromp


P.S.
De referenties kunt u opvragen via janwillem.tromp@glow-management.com


Referentie:
Zika-Vitorsson, A. Sundstöm, P. Engwall, M. (2006) Project Overload: An exploratory study of work and management in multi project settings. Int Journal of Project Management vol 24 (2006) 385-394.

Engwall, M. Jerbrant, A. (2003) The resource allocation syndrome: the prime challenge of multi-project management? International Journal of Project Management vol 21 (2003) 403–409

Zit u in een multi project omgeving? Ontkenning of bewustzijn!

Wanneer zit u in een multi project omgeving? Dat is simpel vast te stellen. In hoeveel projecten bent u momenteel betrokken? Meer dan één? Rond u eerst een project af of werkt u afwisselend in het ene project en dan weer in het andere project? Is het laatste het geval, dan zit u in een multi project omgeving.

Wij ervaren dat veel mensen in zo'n omgeving zitten. Denk aan R&D omgevingen, engineering, marketing, sales, software, bouw, verbeterprojecten, etc. Tijdsdruk en overbelasting liggen dan vaak om de hoek. In onze ogen is de multi project omgeving een van de meest complexe omgevingen om te managen. In dit blog heb ik al vaak geschreven wat u daar aan kunt doen. Mijn collega Albert Ponsteen en ik doen momenteel promotie onderzoek naar dit onderwerp. Wij breiden continu onze kennis uit en willen dat graag met u delen. Neem bij vragen gerust contact met ons op.

janwillem.tromp@glow-management.com
0031 6295 62613

 Voor info over ons onderzoek klik http://tinyurl.com/pczbt2j 

Werkdruk is hot, maar hoe druk je werk uit?

Het thema werkdruk is momenteel zeer actueel. We weten de gevolgen van overbelading; stress, vertraging, verzuim, extra vergaderingen, etc. Met als grootste gevaar dat de organisatie belandt in een vicieuze cirkel. Uit ervaring weet ik dat het voor medewerkers moeilijk is om aan te geven dat de werkdruk te groot is. Het is een gevoel en moeilijk meetbaar. Is de werkdruk enkel het werk dat al op je bureau ligt, of is het meer? Dit ligt er een beetje aan. Voor velen zal de werkdruk bestaan uit het werk dat op zijn of haar bureau ligt. Maar voor velen ligt dat toch anders.

De werkdruk komt voort uit de hoeveelheid manuren en uit de tijd die men krijgt om deze manuren te verzetten. Zelfs als we redelijk in staat zijn de manuren in te schatten dat nog is het niet eenvoudig de werkdruk te bepalen. Dat komt omdat een deel van het werk nog niet op het bureau ligt. Het ligt nog stroomopwaarts bij collega's of het wacht nog op vrijgave totdat de klant het contract getekend heeft. Uitgaan van een projectplan is niet voldoende omdat je niet weet hoeveel tijd je nog hebt op het moment dat het werk bij je komt. Iedereen weet dat in werkelijkheid een project niet volgens plan verloopt. 

In een situatie van een medewerker die in meerdere projecten tegelijk moet acteren (Multi Project Organisatie) heb ik de volgende oplossing uitgewerkt en pas het ook toe voor mijzelf. Ik ben in staat op basis van de project netwerken met inschatting van de manuren en een beperkt aantal milestones de totale werkdruk te meten van een persoon. Ik heb dus geen gedetailleerde Gantt chart nodig. Grafisch ziet de werkdruk als volgt uit:

De stippellijn is mijn capaciteit 0,75 manuur per uur. De blauwe lijn is mijn belading. Het is duidelijk veel te hoog. Dat betekent dat ik keuzes zal moeten maken. Maar ik kan dat niet alleen omdat ik deel uit maak van diverse projecten. Overigens, deze overbelading wordt wellicht niet veroorzaakt door mijzelf maar kan ook veroorzaakt zijn door vertraging bij collega's stroomopwaarts.

Van belang is nu het gesprek dat plaatsvindt tussen leidinggevers, project managers en medewerkers. Wij voorzien de organisatie van bovenstaande grafieken. De organisatie zelf zal ervoor moeten zorgen dat de werkdruk gebalanceerd wordt met de beschikbaarheid aan capaciteit. Als dat gebeurt, zie je de snelheid en output van de projecten enorm toenemen. Dat laten mijn klanten telkens weer zien.