Ukraine’s Tech Scene Keeps Growing

This September, I traveled to Ukraine to visit my software development team in Odessa. The Black Sea Summit, one of Ukraine’s largest tech events, coincided with my stay, so I jumped at the opportunity to get to know the local tech community a little better.

This year, the Black Sea Summit was held for the second time. The event attracted over 700 tech experts, and featured a number of sessions and workshops. The ones dedicated to inspiration and growth were my favorites.

More than 30 world-renowned speakers shared the latest industry trends with the audience and showcased the best practices to attract investment and foster innovation. I was very excited to listen to Wendy Dent, Mark Tyurell, Andrew Kolodjuk, Rich Strombuk — the  Technology Pioneers who have greatly influenced the business and society according to the World Economic Forum.

Patrick Kramer, the Chief Cyborg Officer of Digiwell, was one of the headliners. During his presentation, Patrick implanted a chip in a hand of one of the volunteers from the audience, who, as a result, became the first Ukrainian cyborg. The chip can store payment details and contact information, and even open locks without a key.

While international speakers were talking about new technologies, young Ukrainian teams were presenting their startups. Ukraine is home to Europe’s largest tech talent pool with its 74 000 specialists, and the fourth largest supplier of IT professionals in the world, so I was very interested in seeing what kind of cool new tech is coming to life here. These are the six startups that won the first round of Seedstars Ukraine at the Grow Stage: BioSens, a portable device for quick food diagnostics; Viosk, a tool that allows to create video adverts automatically; Protokol, a service for decoding speech and converting speech into text; DeviceVoice, an IoT solution for the vending industry; Glash, a video-stabilization technology that runs on smartphones and action cameras, and allows to create extreme sport videos; and Gorilla, a service for ordering food from different restaurants.

The BioSens developers brought the first prototype of their device to the conference. The invention is easy to use: just put in the product such as milk or juice on a special biosensor and in 15 minutes view the information about the concentration of bacteria and mycotoxins in the product on your smartphone. Speed is the main advantage of this new tech since the same type of analysis can take up to two weeks in a lab.

Of course, such a great conference wouldn’t have taken place without the support of multiple sponsors, and I take great pride in the fact that HYS Enterprise, our software development partner, was among them. Kudos to the entire Black Sea SummIT team for all the work they put in to make the event happen!

Jan Willem Tromp

Why is resource leveling in a multi-project environment not successful?

Interesting question. In a multi project environment people work simultaneously in several projects.  Resource allocation is the biggest challenge in such an environment. Resource leveling over multi projects demands priority rules between projects. Planners have to define these priority rules. After leveling the planner has a hard time to understand the leveling rules of the software system. He does not recognize the end result.
 
Secondly, resource leveling assumes a deterministic world. I can assure you that determinism does not exist in a multi project environment. Why? To much variations in task completion and to many interdependencies between projects because of the shared resources. Every time you level, reality will hit you soon. 

Thirdly, for 30 years the academic community tries to develop heuristic methods for optimizing the resource allocation. I know some of the professors in this world who decided to stop this avenue because it does not work! In contrast with Advanced Planning & Scheduling in manufacturing environments, this does not work in multi project environments. To much variation.

But there is one way out. Add a lot of safety to every task to deal with the uncertainty. Then do the resource leveling. You will notice that it is much more stable. But don't be sad if you discover that the efficiency of your company dropped down significantly and lead times of your projects expand.

Conclusion: be careful in believing the ambassadeurs of Project Management software that are exited about their resource leveling functionality.  

Their are two alternatives concepts: FLOW MPM and CCPM. Although CCPM is also a type of resource leveling within one project.

The project planning nightmare resolved

Just imagine you want to create a project schedule with a few hundred tasks. You split the project in a few phases and finish every phase with a milestone. On the top of your Gantt chart you put all your milestones. In order to maintain the project schedule in execution phase you connect the tasks. Setting relations between tasks in a Gantt chart is undoable that’s why you prefer a network view. And what do you get? A spaghetti network. Do you have a clear overview of your project? No way!

The classical way of creating a network with 6 milestones and just 14 tasks. It is already a spaghetti network!

We took up the challenge to improve it. We created FLOW MPM software where you easily can calculate the priorities and resource load only based on project networks. We also made it much easier to draw a network without loosing the functionality. Have a look below.

Believe it or not. But this project network in FLOW MPM has the same functionality as the first network. But we less relations to maintain. You get no spaghetti but a clear network.

Do you like it? 

Jan Willem Tromp

The balance between order and chaos in multi-project companies

According to Geraldi (2008), many management and organisational models state that an organisation is successful if it manages to combine organisational creativity and innovation with mechanical efficiency. However, most Multi Project Based Organizations find it difficult to achieve this. The desire to avoid inefficiency and the urge to minimise uncertainty and risks increases the degree of control and bureaucratisation, which often means a decrease in creativity and flexibility.

Along the project life-cycle, employees face diverse types of challenges. Projects tend to emerge as chaotic systems, as projects start with an unique idea, the project scope is still not clearly defined, project stakeholders are not sure of its feasibility, the contract linking possible parties still does not exist, authority and responsibilities are not clearly defined, the new members of the project are still getting to know each other and identifying the best form of cooperation, etc. Thus, projects are still in chaos, i.e. formless or disordered, or at least, significantly less defined and formalised than the subsequent phases of the project. The following phases clearly demand higher levels of order. Procurement, production and assembly – involve many companies and people; consequently the decentralization of authority and responsibility is necessary to cope with the amount of work to do on time. The final phases demand a very high coordination of tasks and companies on site, and consequently, well defined structures and clear responsibility, but still with some flexibility for unpredicted issues that frequently emerge on site.

Thus, projects demand both mechanic and organic paradigms, both order and chaos; in other words, the management of projects faces different challenges and requires organizations with different degrees of flexibility.
This paradox is especially pronounced in multi-project companies – companies such as software development, engineering consulting, plant engineering companies, civil engineering, event management. These companies have projects as their main function and source of turnover. Consequently, these companies deal with the different types and intensities of complexity in projects, as well as among different types of projects in the company’s portfolio, between projects and supporting functions, as well as among subsidiaries, acquired and merged companies, and relevant project partners. Such heterogeneity demands structures with different degrees of flexibility.

GLOW Management developed FLOW MPM that helps multi project organizations to balance between order and chaos. While developing and executing the projectplan we are aware in which phase you are in and deal with the uncertainty coming from the edge of chaos and strive for balance between order and chaos.

Jan Willem Tromp

GERALDI, J. 2008. The balance between order and chaos in multi-project firms: A conceptual model. International Journal of Project Management, 26:348-356.

Plan less, Get more, the new way in multi project management

It is a myth that in order to get good priorities and load graphs in a multi project environment you have to create a detailed project plan and actualize the Gantt frequently.
GLOW Management has done a lot of research in multi project environments and found out that the dominant way of doing project planning is not sufficient anymore and extremely labor intensive.
We turned it around. Our main goal was to develop a planning method for a multi project environment which would deliver the best priorities for tasks and actualized load graphs for all resources, with less effort.
With FLOW MPM we are able to do that. You just have to create a project network. It is sufficient enough to connect summaries with milestones (instead of all tasks). Secondly, you do not need to put task bars on the right spot in your planning. FLOW MPM is very sophisticated software that creates a Gantt automatically based on the network and buffer time. You don’t have to input and maintain a lot of parameters to run FLOW MPM. We dislike parameters but love agility.
A project manager in heavy machine building said: ”I do not need a planner anymore. Together with my team we created a network. During the project, FLOW MPM gives me the right priorities and actualized load graphs over all projects. We only have to update the remaining work. FLOW gives much better information and insight, resulting in high reliability, more speed and efficiency. It also saved me a planner. We plan less and get more”.
Jan Willem Tromp

We will start your project later in order to deliver earlier!

This counter intuitive title is not a paradox. If your most loaded people have to play a role in an extra project, all projects can delay. First of all because the waiting times go up and secondly because this extra project causes bad multi tasking. People have to divide their attention to more subjects.

Let me give a short example of an experience.

A client (R&D department) of us wanted to improve the due date performance. We did an analysis with our software FLOW MPM and the conclusion was the following:

• The most loaded resource group assumed a capacity of 4 man-hours per hour (5 men). 
• FLOW* calculated a workload of 11 man-hours per hour. Way too much. 
• And the output* of this group was 2.3 man-hours per hour, 

The output is the actual capacity in this circumstance. By reducing the load to 6 man-hours per hour, the output went up automatically to 4.7 man-hours per hour. Why? Because the people in this group were able to focus on less projects.

End result. The lead-time dropped more than 70% and the finished projects doubled.

* coming from the tool FLOW MPM

6 basisregels voor hogere snelheid en efficiency in multi project omgeving

regel 1. Zorg ervoor dat geen enkele resource groep meer dan 10% overbeladen is. Monitor de ontwikkeling daarvan continu.

regel 2. Prioriteer activiteiten over alle groepen en projecten heen. Na vrijgave zijn alle projecten gelijkwaardig.

regel 3. Grijp bij overbelading direct in door werk te herverdelen, milestones te verschuiven, projecten bevriezen, deadlines verschuiven of capaciteit te verhogen (indien mogelijk).

regel 4. De gemeten output is je bewezen capaciteit. Volg de trendlijn want deze is dynamisch van karakter.

regel 5. Zet niet bij alle projecten de deadline vast. Zorg voor flexibiliteit. Het is je reddingslijn.

regel 6. Zo gauw een groep vol beladen raakt, email en telefoon uit voor 75% van de werkdag. Geloof me, dit werkt fantastisch.

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