Of course, you need a project-management mindset if you
have to manage complicated technical projects.
But it is not enough in a networked, dynamic world with wicked problems.
That calls for a different mindset.
We call this the process-managerial mindset – leadership is not,
or not only, a project,
but a process of aligning actors, finding out what the best solution for the
wicked problem is and being adaptive, in view of the dynamic nature of our world.
For someone with a project-based mindset, everything starts with a problem.
This problem must be defined as precisely as possible.
You are looking for the right problem definition.
The more precise you are, the easier it will be to select the right solution.
But the leader with a process-based mindset knows that ‘the right problem definition’
often does not even exist.
Problems are wicked, which means that different actors may have
very different views on what the right problem definition is.
If that is the case, you need to define the problems as broadly as possible.
The more precisely you define a problem, the more likely it is that there will be opposition
and that others will accuse you of being narrow-minded.
The more broadly you define a problem, the more likely it is that others will find
it sufficiently attractive to work with you.
Something similar applies to objectives.
People with a project-managerial mindset like to have clear goals,
because they provide direction.
But what is the risk of having well-defined goals in a networked world?
You lack resilience and are unable to adapt to changing circumstances.
You cannot learn – in the course of the multi-issue process,
unexpected opportunities may emerge that may also be attractive.
If you have a pre-defined goal and are single-mindedly focused on achieving that goal,
you will not see the opportunity and will not seize it.
It is strategically clumsy to be very explicit about your goals.
It can make you less adept at playing the game.
The clearer you are about your goals, the easier you make it for your opponents
to block these goals.
The next phase is gathering information.
In the project-based mindset, your goals determine which information you gather.
Engineers often adopt a need-to-know approach to this – you need the information that
helps you to achieve your goals and the rest is information overload.
In the process-based mindset, the attitude to gathering information is often
very different.
You need to take account of a large number of actors and any information about these
actors and their problems can be of interest – especially if you wish to design a multi-issue game.
In fact, unnecessary information does not exist.
The more you know about the players, the better you can play the game.
And there is more here.
Someone with project-managerial DNA searches for the right,
objective information.
With a process-based mindset, you know that problems are unstructured and
that a lot of information is contested.
The question is therefore not, or not only,
what the objective information is.
It is not possible to remove the many uncertainties with information alone – after all,
that is often contested.
The question is how to get the parties involved to such a stage that they see the uncertainties
as a shared problem.
And therefore join forces to manage these uncertainties as much as possible.
How do you achieve that?
By making the process attractive for them.
When the process is attractive, has a perspective of gain,
actors will be willing to work together in managing uncertainties.
How do you make it attractive?
By ensuring that there is something in it for them – by means of a multi-issue game.
Then the solution can be designed by refining the information.
In the project-based mindset, the solution arises from problems,
goals and information.
First, there is a problem,
and we then we try to find a solution.
In the process-based mindset, that is often different.
There is a solution, and we then try to find problems.
Someone has a solution that he or she wishes to achieve.
Take our mayor, for example,
who wants to achieve a port expansion.
So what do you do next?
You look whether you can link other problems to the solution.
The port expansion can, after all,
also contribute to solving many other problems than the problem faced by the mayor.
Why would you do that?
If the mayor succeeds in linking her solution, the port expansion,
to other actors' problems, she will probably gain the support of those
other actors.
Decision-making.
In the project-management mindset, you have analyzed problems,
set goals, collected information,
designed a solution, and then the time comes for decision-making.
This is an important moment – the go/no go moment.
In the process-management mindset, the difference between decision-making and
the other stages in the process is not so clear-cut.
Because of the multi-issue game, decision-making is actually a continuous process.
The decision is not made, it emerges.
Then there is this: anyone with a project-management mindset also
knows a large number of tools and techniques that are effective in a project.
The rule of thumb is: tools that are effective in a project do not
work in a process.
Take a simple tool: a deadline.
In a project, a deadline is an incentive to achieve something
on time.
But what happens if the mayor in our case study sets a deadline for all the other players?
For example, if she says that a decision must be made by
September 1st: Nothing.
Why should the other actors take any notice of this kind of deadline?
Even worse – the actors can ask themselves a simple question.
Who will have a problem on September 1st?
The mayor will, but her opponents will not.
Because they know that the mayor will have a problem,
the deadline could even serve as an incentive for delay.
Decision-making is followed by implementation.
For this, you mainly need a project-management mindset.
The final question is: what makes you successful as a leader?
What are the evaluation criteria for good leadership in a networked world?
The criteria for success in a project-management mindset are often threefold:
Have you achieved your goals?
Have you done it on time and on budget?
Of course, these criteria are not appropriate for a process,
in a networked world.
The first criterion: are you satisfied with what you have achieved?
You may have something different from what you were originally looking for – and the
question is therefore not or not exclusively whether you have achieved your original goals.
The second criterion: is there a trust among the other parties and
have good relationships emerged with them?
Remember that, in an interdependent,
networked world, you will encounter these other parties again
and you are dependent on the other parties.
If you have gained a lot but the other parties are highly disappointed – that can be extremely
damaging in future processes.
The third criterion: have you learned something?
If, through interaction with multiple parties
and by means of a multi-issue change process, you achieve what you wanted at the outset,
you have probably learned nothing.
Other parties can block your initiative but other parties and other issues can also improve
your initiative.
Then you will have learned something.