Projects need decisions. Unknown or unclear decisions might lead to undesirable actions. False decisions can even derail entire projects. Clearly, this is not the case for all decisions but for the important ones that give a project direction.
Given the importance of decisions, some thought should be given to how decisions are reached. Surprisingly, many projects have no systematic approach. This article outlines a methodical approach to decision making. We start with the organizational frame.
Participatory Decision Making
From the outset, we enable all team members to participate in decisions. This does and should not mean that the entire project team — which could consist of 10 or even more than 100 members — should decide. But rather every team member is given an opportunity to participate.
The objectives of this approach are:
- Reach better decisions since we’re getting maximal input and encourage diverse opinions
- Get better acceptance since everybody had the choice to get involved in the decision process
Having said that, there is still the possibility of an overrule of a particular decision by team/project leads. This is theoretically possible and should be an option but in fact we have rarely see this happening. If this is an exception (to team-based decisions) and the overrules are well explained, the approach is still valuable.
These are the hallmarks of what some refer to as Participatory Decision Making. Its importance in IT projects has been noted by Jim Highsmith in the 2003 edition of his book Agile Project Management.
Implementation
We have implemented the approach in various projects for architectural decisions, but the implementation is not limited to architecture as you will see.
First, you need to agree on which types of decisions you would like to see governed by the approach. To provide an example: In a development team we had agreed that developers should not decide on their own when the decision had impact beyond the scope of the current task for it was needed.
Once this is established, every team member can ask for a specific decision to be reached. Such open topics are best collected in a project wiki. We always added a crisp description of the topic or question along with name of the person who raised it and the date when it was entered. Here is an example of a basic layout:
| ID | Category | Topic/Question | Details | Raised by | Date entered | Meeting planned for |
Depending on the size of the project, there are various options on who should drive the decision process. It could be the team lead, an architect, an architecture board etc. A specific topic should have one person responsible for its decision process. She should announce the upcoming topic meeting and ensure that there are enough participants.
The decision process of this group is worth another blog and won’t be covered here.
Once a decision has been reached, it should be documented along with its rationale. It is important that this decision is published and the information spread to all team members. One could also present the decision in a weekly (jour fixe) or in a separate decision meeting convened regularly.
Conclusion
Our decision process is:
- Transparent: All team members are aware of upcoming decisions and of the decisions that were reached.
- Open: All team members are allowed to actively participate in the decision process.
- Open-Ended: There are no predetermined decisions.
- Democratic: Everybody can bring their experience and voice into the discussions and influence the decisions.
Next? Try it out!
Bibliograhpy
Jim Highsmith, Agile Project Management, 2003
