Boring Meetings? III

Planning a cross-department project using the Loops Communication Model

Photo by Maarten van den Heuvel

Let’s be clear, the meeting topic is certainly foggy in many places and there are different approaches that fail at certain point. That is a big true. But as described before it is not about the meetings but about the structure of the system behind.

So far my three previous articles were about a theoretical approach to tackle not only that issue but to reduce communication complexities and improve efficiency.

A Communication Model Based on Blockchain describes the basis of the system organization to start building an effective communication environment.

From now on, I would like to call it Loops Communication Model (LCM) as the feedback loop is the basic unit of the whole theory and its core element.

Boring Meetings? I is about how to apply the model consistently and Boring Meetings? II sees the problem from the meetings perspective.

This article is all about cross-department projects that have a defined life time. These kind of projects can be really complicated to organize due to the huge variety skills and people required to solve the problem.

The amount of wrong meetings on this kind of project can scale extremely fast and can lead to a big fail before the project starts.

We would like to apply our communication model to such projects.

The Why

It is the initial phase of everything. Before doing anything answer why are you doing this project and which problems are you solving with it. You will define the purpose of this project. And this is crucial.

With that answer in hand, it is easy to define the scope of the project and the stakeholders to involve.

At this step you don’t need anything else than defining all your stakeholders (like in other projects). That will be your first net (team). It will suddenly evolve in many others.

There is a standard meeting usually called kick-off or something similar to start brainstorming the project. Before that meeting you should meet with all your net to settle the problem(s) are you wanting to solve. Each stakeholder will interpret the problem from their own perspectives and will give you feedback about it. There you have your first loop, by the way.

The goal of this meetings is to have a well defined problem to solve. Nothing else.

With the problem well defined, the first net should discuss and brainstorm what scopes will be affected by this project. This will define the future nets (teams) to be connected to the first-created net.

So, we have a nicely shaped problem and its scopes.

The How

Now we will define the assets, the workflows, the rest of the nets, the channels and yes, the contracts: the behavior the participants on the projects will agree to follow.

Maybe you were working previously with colleagues involved on this cross-department project. Maybe you are used to have defined assets, workflows, channels and smart contracts between you and your colleagues. At this phase you will define from scratch all of them or renew them.

It is important that all this is adapted to the new project because there are not equal projects. The assets you used for an old project can harvest and create communication problems in the new project.

In this step we do have something extremely important to get done: the new nets. These are the other teams that work around the core team. They have their own assets, workflows, channels, etc.

Here is more information about the assets and (link to the loop model).

At last of this phase you should defined the Feedback Loops and their frequency.

The What

Now it is time to define what you will do to solve your why. You know how you will solve it. All that is set.

You just need now to make the net work. As the why was discussed and shared, do the same with “the what”. You can use any kind of techniques to brainstorm what you will do to solve your problem.

The goal of this meeting is to have a cloud of ideas that will solve your problems arranged by business impact.

At this stage all these single ideas will belong to a certain net or sub-net in the whole project’s structure. You should send those ideas to those teams to measure the effort required to develop the proposed ideas.

This is a process that will start from the core team. The core team will send ideas with business impact as asset and the rest of the nets will send ideas with required effort as an answer.

After this loop is finished you can map all the ideas in a diagram business impact vs. effort. With this input your core team can make your own decisions and define the next steps for developing the project.

Now your project is set. But not planned.

The Real Kick-Off

Now that your team defined the why, the how and the what, the core team should go team by team and explain them to all participants in the project so, all of them are activated and on board in the project.

By this time you should have already all the action items, their dependencies and have defined all their accountable persons.

Make sure everyone knows their function and it is aware of what the others do in the team. Maybe it sounds stupid but that is totally needed. So the workflows don’t misbehave.

When all this amount of work is done your project is set. Its success depends on the level of organization you set through these 4 steps.

Remember, there is never enough planning.

Thanks for reading! If you enjoyed this story, let’s discuss about it and before you go click the clap button and share to help others find it! Also feel free to leave a comment below.Here is my Twitter.