Does Democratic Project Management Work?
I've observed many attempts to adopt democratic project management methods mid-flight, with teams keen on obtaining a majority consensus for decision-making. All of them have unravelled to an extent.
As much as I appreciate the concept, and people will point fingers at Valve (having never actually worked there and seen how it functions or its issues), the stark reality is that, in my experiences, hampers a project's agility and hinders prompt decision-making.
It leads to constant cycles of ‘more information’ and discussion, and you find yourself trapped in a Groundhog Day set of meetings, repeatedly answering the same questions, flip-flopping between outcomes like the jury in Twelve Angry Men.
Setting aside the unique case of Agile 'self-organising' scrum teams (which, in my opinion, are development units, not project management teams), it's worth noting that most project teams function within a hierarchical structure. This approach has proven effective in achieving results, much like the military's operational style. It’s for good reason. It's stood the test of thousands of years.
Many moons ago, I was tasked with project managing a contract management system for various stakeholders, including departments like Legal, IT, and Finance. Despite their differing requirements, they all agreed that having a solution was better than none. Well, that’s how it started out, but it turned into a shitshow, I'm sad to say.
The real challenge was deciding on a single solution. Legal wanted something that allowed back-and-forth contract negotiations and version control; IT wanted contracts stored in a simple repository and be prompted when they were going to expire. Sales wanted integration with the CRM and to create standardised contracts themselves. These criteria aren't necessarily mutually exclusive today, but back then, they were less easy bedfellows.
Despite having project scoring criteria that balanced things, each solution favoured different stakeholders. Extensive discussions and reviews led us nowhere. We sought collective consensus, but (in hindsight) it was impossible. All roads were 'good', but some were 'great' for specific stakeholders.
The project had the potential to succeed but floundered in indecision and eventually collapsed—the absence of a unanimous decision and the inevitable conflicts that arose stalled progress. At the same time, the business landscape changed, and budgets waiting to be used were redirected to where there was no problem deciding what to spend the cash on.
What was needed was a decisive voice, in the shape of a project sponsor or project executive, which we lacked, to take charge and choose a path forward.
Why didn't I enforce this? In hindsight, it was due to inexperience, a lack of confidence and recognition that I'd need the material to write this article later in life.
So, how would I approach it now?
Addressing Decision Deadlocks in Teams
Clearly Define Decision-Making Roles
Often, the root of indecision in projects and why they turn to the model they so readily recognise in introducing a democratic approach lies in the lack of clear roles and hierarchical structure from the outset.
Many individuals, unsure of their authority, hesitate to make crucial decisions. Others can overreach their authority and try to make decisions for the team (like my mother-in-law).
It's imperative to clearly delineate who is responsible for what decisions within the project. This involves identifying the primary decision-maker: the project sponsor, a senior user, or the development manager. Whomever. The role must be explicitly documented in the project's roles and responsibilities. If this isn't done, take the initiative to clarify who is accountable for crucial decision-making.
Without decision-making clarity, the team may seek to 'vote' on things or reach a constant state of review and discussion without moving forward. Or, even worse, two or more people grab for the steering wheel simultaneously.
It's important to remember that while multiple team members can share responsibilities, the accountability for project-level decisions should sit with a single individual. This avoids the diffusion of responsibility and ensures that there is always an identifiable, accountable figure for every decision.
I'm not saying one person makes all decisions, far from it, but it should be evident in the point of hierarchy who ultimately can make a choice if called upon by the project. Should we outsource this API or build in in-house? (Spoiler alert: outsource it).
Empower the Decision-Maker
Once the decision-maker is identified, they must be empowered to make decisions.
This empowerment comes from two fronts: firstly, by ensuring they have all the necessary information and inputs from various stakeholders, and secondly, by publicly endorsing their authority.
In the military, this part is easy, as the hierarchy is displayed on all uniforms and clearly delineated, but in businesses, its often not so obvious.
Senior management can play a pivotal role here by openly supporting the decision-maker's authority and their position in the project hierarchy. This endorsement can significantly boost the confidence of the decision-maker and reinforce their role within the team, encouraging them to make informed and decisive choices without hesitation.
It can be disastrous to attempt to establish authority while the project unfolds and decisions are made in real-time, so try to make sure things are clear right up front of the project.
Tie-Breakers
Now, in the interests of open-mindedness, if the project works well as a democracy (and we note my doubt on the matter) but then hits an impasse. A situation could arise where opinions are evenly split, and a clear decision-maker is not evident, a tie-breaker mechanism becomes an option. It's not my favoured option, but it's still there to fall back on so you can unblock the project.
This could be an external advisor/subject matter expert who brings a fresh perspective, a weighted scoring system that quantifies options based on predefined criteria, or more unconventional methods like a game of Rock-Paper-Scissors-Lizard-Spock.
The key is to have a predefined method to resolve deadlocks, ensuring that the project doesn't stall due to indecision. I’d always recommend outside influence first and foremost. An SME can change an outlook within minutes.
Confront the Underlying Issue
Sometimes, the barrier to decision-making is not structural but psychological, stemming from reluctance, inexperience, or not wanting to upset anyone. In such cases, it's crucial to address these underlying issues.
A direct approach can be practical and has certainly helped me jar a team or two out of their deliberations. Addressing the issue head-on by acknowledging the team's analysis paralysis and emphasising that they have enough information to decide can jolt the team into action. It is essential to create an environment where decision-making is seen as a positive step forward, even if it involves risks. This approach resolves the current impasse and builds a culture of decisiveness and efficiency in the long run.
In Conclusion
The challenges of decision-making in project management are multifaceted, but they often boil down to the dynamics of hierarchy versus democracy. While democratic approaches are laudable for their inclusiveness, they can lead to stagnation and indecisiveness, particularly when swift action is required. On the other hand, when well-structured and clearly defined, a hierarchical approach can offer the decisiveness and efficiency essential for project success.
As project managers, our role is not just to manage tasks but to lead people. This means guiding our teams through complex decision landscapes with clarity, confidence, and a deep understanding of project management's human and technical aspects. The journey is often challenging, but the rewards of a well-managed project are immeasurable, both for the team and the organisation as a whole.
Comments