It is a sad fact that in knowledge work in today’s VUCA environment the matrix organization and projects are less and less successful. Reasons for this is are …
- projects are often planned without sufficient consideration of the already running projects,
- the totality of the projects use the capacities of the involved resources and employees to 100%, sometimes even more!
- This means that even the smallest changes to the plan of one project can have a huge impact on the other projects.
To solve this problem, i.e. managing those dependencies, is the task of multi-project management. For some years now, there have been good-sounding approaches to this, which mostly use computer-aided optimization. Unfortunately, I have not yet seen a well-functioning approach to this so far.
The problem is that people, especially knowledge workers, cannot be managed like machines. We must stop putting people into efficiency-optimized projects by percentage!
Why stable teams?
From behavioral research and from experience we know that people work best in long-lasting structures in which they know, appreciate, trust and respect each other, e.g. in “clans”, tribes or clusters with a maximum of about 150 members (see also “Dunbar’s number“). Stable teams within the Clusters increase the feeling of belonging and reduce the training period.
If we now manage not to provide projects with the most efficient and supposedly optimal staffing each time, but to transfer projects to the most suitable existing team, we have already simplified the complexity of project management by an order of magnitude. Of course, a stable team will never remain completely unchanged over a long period of time. The natural fluctuation of employees ensures enough changes in the “normal case”.
And for sure, stable teams will also never fit optimally for a specific project. But it is sufficient if only theNucleus of the team remains stable. Depending on the situation, the core of the stable team can be (temporarily) supplemented by required experts, but this must be the exception. This is what is called Extended Team in the P4 framework.
If several similarly suitable teams exist, they can be supplied with work from the same project portfolio.
Now let us address the second problem: Too many concurrent projects. How does it come to this? This is often due to the fact that nobody really knows how much the organization as a whole can accomplish. According to the motto “Diamonds are created under pressure”, more projects are started than are actually possible, in the hope of getting at least some of them delivered on time. But often the cause of the problem is also the large number of senior managers, internal customers and stakeholders, each of whom pushes their own projects, which leads to negotiations of project costs and additional competition among the projects. An internal organizational demand/supply structure supports this effect.
To solve the problem we have to do two things:
- We have to measure the actual effort, how much a team, a cluster or the whole organization has put into a project and
- we must put this in proportion to the original estimate.
This allows us to compare the original estimate with the actual effort. Since we have stable teams, these values will change little over time.
Now comes trick number 3: We have the estimations carried out by the working teams. This makes the quality of the estimates better. We use a unitless size and let the teams estimate the project effort relative to each other. This means that the effort estimate is not directly comparable with a time estimate. We also avoid that individuals and teams add different sizes of buffers.
Trick no. 4 is admittedly the most difficult. We only give the working teams clear priorities of the work and then let them work self-organized, at their own speed, i.e. without pressure but strongly focused and totally transparent. This results in a high motivation within the teams and a predictable performance of the teams (aka Velocity).
Trick number 5: The capacity of the team is never completely planned. There is an agreed buffer for unplanned work and performance fluctuations and a second buffer for internal improvement measures.
Trick number 6: If the share of unplanned work is too large, we assign groups of employees or entire teams to take care of these “support activities”.
The goal of all these measures is to improve the predictability of team results and deliveries. The deliverable performance of the team resulting from the previous measures can be promised and scheduled with some certainty. For this purpose stable teams use a fixed delivery rhythm, e.g. iterations, sprints, release cycles.
It is important that promises are only made once the above conditions have been met, i.e. a predictable delivery performance has been achieved. Previously made promises lead again to more pressure, more parallel work, shortcuts, errors and demotivation.
The opposite of stable teams are hyper-fluid teams, which can change at any time, depending on the situation. (Another wet dream of classical management). When the project situation changes, external “resources” are quickly procured.
One approach that is very common today is to simply purchase the required employees externally, either by recruiting freelancers or by assigning sub-projects to external partners.
This promises to get the right resources into projects at the right time and to get them out quickly when the project is finished. Both motivations are understandable: Often, it was missed to build the required teams in time (“yeah, why should we? The budgets usually come from the projects”). In addition, the costs should be as low as possible after the project is finished.
The short-term build-up and reduction of external project staff has some disadvantages, but usually the projects, not the departments involved, have to bear the brunt:
- External employees must be trained in the subject matter and organizationally. This costs time and capacity of the internal employees who have to train and internalize the externals.
- External employees have to integrate themselves into the project team (as well as new internal employees). This Forming, Norming, Storming, Performing reduces the performance of teams, at least in the first weeks of a project.
- External employees are not allowed to access all data systems used by internal employees, either for legal reasons or for internal security reasons (need-to-know). In order for work to take place at all, there are sometimes the most adventurous constructs (e.g. creating and managing duplicated data or entering of hours to be billed into multiple tools). The resulting disabilities additionally reduce the performance and morale of the teams.
The solution here is relatively simple, but requires foresight. The organization has to develop a strategy to keep and build up knowledge internally. For this purpose, the right employees must be found early on and existing employees must be trained. Only for knowledge areas that are not strategically important in the long term does it make sense to hire external employees and order service providers.
Are you still searching for the holy grail of project management? I would be happy to hear your questions in the comments, but also about solutions you might have found.
Photo by jcomp on Freepik.
One thought to “Multi-project management: The holy grail of management”