Soul Mate - A real world example of team collaboration
Being a partner in an EU project is very different from doing trainings. It’s one thing to show others how they can streamline their office processes or optimize their time management and use digital productivity tools. And it’s another thing to apply the same digital tools and techniques in a project with others. A long running project on top of that: 3 years.
The EU financed project we’re part of is called Soul Mate. Its goal is to produce educational material for people with disabilities about how to cope with work place related stress.
Soul Mate was initiated by Kopf Hand und Fuß (KHuF), a Berlin based NGO focussing on support for people with disabilities. Partners from four different EU-countries had to get on board to receive funding from the EU: KHuF and VSBI (Erfurt) from Germany, SATIS (Rome) from Italy, People First (PF, Pécs) from Hungary, and Work With Ease (WWE, Dobrinishte) from Bulgaria.
Each partner is contributing to the project from a different perspective with its specific experience and competencies:
KHuF: project management, online publication platform for project results, video production
VSBI: production of accompanying documentation
SATIS: psychological research
PF: alignment of results with the needs of the people with disabilities
WWE: selection and documentation of digital tools and techniques to help dealing with work place related stress
If getting people to smoothly work together in a single company is a challenge, it should have been clear right from the start, that a multi-national and interdisciplinary team is even more daunting.
But we all were pretty naive about that, unfortunately. And it took the team 2 years to fully realize how naive…
So, what did we learn from this project?1 Several questions need to be answered rather sooner than later for friction free collaboration. None of these questions is new, of course. But it’s one thing to know them or have them in the back of your head — and another altogether to actually sit down and find answers.
How to get everyone on the same page?
The first and most important question is: What is a project all about anyway? Why come together for collaboration? What’s the purpose, the goal?
Sure, there was an accepted project proposal. The EU had agreed to fund the project. But as it was obvious — at least to us at WWE — after the initial kick-off meeting, it wasn’t clear to everyone what it actually was we were supposed to achieve.
In retrospect it’s very strange we were able to sit together for hours and not be able to state the project’s objective in a single sentence everybody had agreed upon.
Neither was anywhere this sentence noted down, nor was there a shared clear understanding of what the project’s deliverables were. Sure, everyone had a more or less fuzzy idea of “stuff to do”. But it turned out in a meeting in December 2024 — after 2 years into the project — there were (still) marked misunderstandings about content and form of the deliverables.
But not only the objectives and the results where unclear. Also there was no definition of how exactly these results were to be produced by the partners. There was no process definition, not even a rough/preliminary one. There were partner’s areas of expertise, there were so called “work packages” (aka phases or milestones), but there was no clear connection between the two and concrete results.
That was bad.
Conclusion: Don’t start a project without perfect shared understanding of:
Purpose: What problem to solve? Why does it matter?
Target groups: Who does it matter for? Who are the stakeholders, i.e. who wants to or should have a say in what defines success?
Goals: Which measurable changes “to the state of the world” to achieve? Think SMART.
Deliverables: What tangibles will be produced with regard to each goal, e.g. documents, media? Who are the recipients of this?
Responsibilities: Who will deliver what until when?
I’d even go as far as say this all should be written down, printed out, and signed by every project participant. Yes, even in the digital age: print it out, make it tangible, make it a formal act to everyone to remember: “This is our pledge…!”
Instil a sense of accountability for everyone, plus the understanding of “We are in this together!”
How to form a team?
A contract like this would be just a piece of paper, though. As important as such clarity is, it needs to be brought to life, it needs to be embodied.
The natural body for a project is its team. But where can a team or 5 international partner companies and more than 10 people be seen, touched? A football team is present at the same time in the same place to perform as a team. Not so a distributed team like ours. That made things even more difficult.
But fortunately the project setup and the project leaders experience had thought about that. The solution to “feeling the team” were meetings with mandatory attendance.
Every month all partners would meet for 90min online to retain a sense of the unity of the team and update each other on the progress of the project.
Once or twice per year all partners would meet at the site of another partner in person. That have us a chance to learn more about the culture of the partner’s and the environment they are working in. (I won’t deny this was an appealing aspect of the project; we got to go to Italy and Hungary on business expenses.)
These meetings were essential, even though they could not prevent some of the frictions in the project (see above and below). But without them things would have been much worse.
And as it turned out just getting together “in good will” wasn’t enough, either. It took us a couple of monthly meetings to realize there was something missing: a structured approach. Hence a facilitator was hired. She guided us in a very systematic way through our meetings. A great help! Also it was beneficial, I think, that she wasn’t part of the project; she did not belong to any of the partners. That way she had a more impartial view from the outside.
Conclusion: A team without meetings won’t stay a team for long, I’d say. Team members must actually see each other from time to time. The frequency and the means (online or offline) might differ from team to team and depend on the type of project. But once a month looks like the bare minimum to me. With physical meetings to raise the energy and cohesion even more.
To have regular meetings is fine, but they don’t need to be scheduled too strictly. Just try to not let them slip too far apart.
And a facilitator is invaluable! Someone to see to that actually things get accomplished during the meeting. The less involved she/he in the project, the better.
How to communicate?
Communication between team members is key, isn’t it? It’s not only knowing, “feeling” them, it’s also to actually be in touch with them between team meetings. How to do that?
Let me be clear: I think communication is waste in the sense of Lean thinking:
Waste is any action or step in a process that does not add value to the customer.
Communication — sending an email or a message in a team chat — most often fits this definition. To inform somebody about something or to ask somebody for more information or even help does not add value to the deliverables of the projects. It’s a symptom of a lack of something which should have been available in the first place or in a more natural manner.
If value cannot be added by a single team member communication ensues. As deplorable that is, it’s hard to avoid. Some communication is always necessary because it might be more efficient to compensate for a lack of something that way than the alternative.
So, the question is: How to communicate? What are the communication channels?
For the Soul Mate project this seemed to be all set. Partners were to use Microsoft 365 (M365) to exchange messages. Email was deprecated, instead MS Teams should be used. Hence a team was set up with a channel for each team. Also some MS Sharepoint folders and an MS Planner board were created.
This sounded reasonable — to turned out to be a premature optimization for two reasons:
Not all partners were equally proficient/comfortable in using M365 tools. That way data was inconsistently stored, tools were not used systematically. The initial structure deteriorated and/or wasn’t used effectively.
The structure set up early on in the project was based on an incomplete understanding of deliverables and processes (see above). Hence it was bound to be incompatible with reality. Also it was rooted in a theory, not in practice.
What resulted was confusion and inconsistency. Where to put documents? Where to find documents? How to name documents? Where to communicate (channel, personal chat, MS Planner card)?
And finally: What to do in case of a conflict or misunderstanding?
This led to additional communication beyond the inevitable. More waste was produced which took a toll on the partners’ patience/motivation.
Conclusion: Communication is a waste, but it will and needs to happen. Therefore proper communication channels need to be set up. A team chat tool like MS Teams, Slack, Discord, Mattermost is helpful — but it needs to be configured/structured. And it needs to be taught. Team members should feel very comfortable to use it, and must not miss relevant messages. Depending on individual habits and digital literacy this might require some effort.
Deliverables and intermediate results need to be made available for all partners to easily store and find. Appropriate tools also have to be set up as resources. Where to put documents and notes? This also might require some getting used to. To fail here might lead to a lot of friction, though.
My impression from the project is that well intentioned structuring of these media can backfire easily. Hence I’d say: less is more. Start with the bare minimum in structure — and let further structures be driven by need and created on demand.
What’s added or changed can be explained in the team meetings. Everybody should agree. All media are “commons” for the project, shared resources to be understood and governed by all.
Where does that leave email? As a communication channel with the team-external world.
Where does that put the phone? On the cradle most of the time. Synchronous communication is a powerful tool to be used sparingly. Sometimes it’s easiest to quickly converse over the phone to sync views, get more information, mitigate conflicts.
To use the phone a bit more often indeed was a learning from the project. But a balance has to be found.
Bottom line: Smooth communication does not happen on its own just because everybody is good willing. It’s a matter of team formation and will take time. Less, if this is understood by everybody.
How to get things done?
Communication (largely) is waste; it needs to be minimized. Communication must not be confused with value creation. Value is what every stakeholder of a project is interested in. That’s what goals and deliverables are about.
What’s value? It’s that what stakeholders — more specifically: customers, i.e. the stakeholder with the money — want more of. More value is always great. More communication not.
In our case value lies in a so called guidebook (VSBI) and a series of videos (KHuF + all partners) plus social media engagement (all partners). These deliverables have prerequisites, though. Research needed to be done (SATIS), tool and techniques needed to be selected (WWE) based on the research, everything has to be checked from the perspective of the target group (PF). Each of these steps is made up of several tasks to be accomplished in sequence or in parallel.
Faced with this kind of “process hierarchy” the question right from the start was: How do collaborate best towards the goals?
And the answer was… none. Because the question was never really posed. Everyone was just beating around the bush. There was no project plan hanging on a wall for everybody to see. There just was one buried in some EU application, and none of the partners actually used it consistently. Instead every body was very busy trying to wing it. Which in conjunction with fuzzy goals/deliverables and misunderstandings caused conflicts and delays.
This was very sad and stressful to watch and being part of. Not an experience to be repeated. Only after a very intense meeting in person over the course of a week did this change. Fortunately. Now we are on kind of on track.
Conclusion: Running a project without an explicitly and commonly accepted plan, a shared vision is a no go. Don’t do that! The plan needs to state
who is going
to deliver what
until when
to whom?
This needs to be stated as precise as possible, but don’t overdo it. Maybe the What is more clear than the When? That’s fine, leave the due dates more flexible.
Most important, I think, is the general sequence of tasks with the responsible parties. Because then it’s crystal clear where where handovers have to take place. At those interfaces communication will and needs to happen. It’s like in a relay race: Where should the runners stand to make passing the baton as smooth as possible?
But this project plan must not be something hidden in a basement! It needs to be a living document to be looked at by all parties during the meetings.
Where are we?
What has happened since the last meeting?
What’s supposed to happen until the next meeting?
What went well?
What needs to be improved?
It might seem boring, but this checklist should be worked through at every team meeting to sync the understanding of the whole effort.
In our project that happened sometimes, but mostly not really. And that was reflected in the progress of the project and the number of conflicts.
Sure, not all team members might be working equally all the time on the deliverables. Some might be waiting for the results of preceding steps, some might have already contributed most of what they were tasked with. Nevertheless everybody should have a rough idea of where the project is standing. And those whose tasks are due need to focus more.
This does not need fancy digital tools, but they can help.
This does not need to be perfect, either. And such a plan does not have the same resolution at all times. At the beginning the beginning of course needs more detailed planning than the end. But as time progresses (and hopefully created value increases) more and more details are revealed.
I think one of the fallacies of planning leading to much frustration is trying to create an evenly detailed plan for the whole duration of a project. So, don’t try that in your project. Start out with a rough overview and keep refining the plan as you move forward.
As Eisenhower is supposed to have said: “The plan is nothing, planning is everything.” Don’t cling to your plan — and that’s easier if you haven’t put too much effort into it too early.
Conclusion
This project was a great experience! But for different reasons that we initially thought.
We were happy to contribute to a good cause. Seeing the world more through the eyes of people with disabilities enriched our lifes. And it was great to collaborate when collaboration actually worked.
However, there were a lot of frustration, confusion, misunderstandings, conflicts to deal with — which could largely have been avoided, I guess. We kind of knew better, but felt unable to address these issues during the project. We, too, got carried away by the enthusiastic mood in which everything started out. We would have felt like spoil sports if we had said “Hold your horses! Not so fast. We better sit down and hammer out a couple of things first.” It would have felt too German, I think. Too systematic, too disciplined for such a good cause where everybody is good natured, good willing, trying their best.
Well, except it would not have been too much but the bare minimum. That’s what we’ve learned: you really, really need a framework to hold everything together and guide everyone at every step all the time. Only then the potential of people truly is set free. Only then frictions are kept to a minimum. Trains are running on tracks for a reason.
Thanks to all the partners for putting up with our confusion and sometimes our nagging! Thank you for providing us the opportunity for this experience!
It was a pleasure to get to know you all!
Which is still ongoing for another 5 months at the time of writing.