The importance of co-defining project dilemmas

Question: How do you ensure that you get new and essential project information from your stakeholders when it is too late to do anything about it? (And it really shouldn’t be?)

Answer: Frame the problem and project scope from only the project team’s point of view.

When a project is initially identified and scoped, it is usually borne out of a senior manager’s identification of an issue to be addressed or a market opportunity. The project, and problem to be solved by it, is often named by this project sponsor without being critiqued. It becomes the default description used by all from that time forward.

Yes, we will usually do needs assessments and other research with our stakeholders to build a robust business case, but it will often be done within the frame set by the initial labelling of the project. There may be a hidden catch in this that will hinder us from the outset in creating wise, enduring solutions.

An essential early step in any collaborative approach is to ensure that the reason for the project has been co-defined. We call this co-defining the dilemma with a wide range of project stakeholders. The term dilemma is deliberately used as it communicates the tensions inherent in any project: how to do X while taking Y, Z, A, B and C into consideration, so that we can generate the best outcomes for all stakeholders. You can think of these as the various competing elements to be resolved in project decisions.

You create this conversation with your stakeholders simply by stating: “We think that this is the issue to be solved – how do you see it?” Additional questions to explore will help you to further unpack and check all the assumptions that have been made. Questions such as:

• Is this an issue for you? In what way?
• Is this the issue that needs to be solved? Is it actually something else? (Are we solving the right problem?)
• If this issue was solved, then what happens? (Are there unintended consequences?)
• What matters to you most about any solution to this issue?
• How would you know when this issue had been solved? What would be different? What other evidence would there be?

Note that the questions on the last two bullet points are about co-defining up front the success criteria for the project. After all, if you’re not absolutely clear on the issues that a solution needs to address from all stakeholder’s perspectives, how can you be certain that one you choose will be the right one? Without these pre-set criteria, the final choice will probably be determined by the person who has the most influence or makes the most noise.

The next step is to synthesise the input from all your stakeholders into a dilemma statement that captures the shared understanding of the problem to be solved. You know that you have a shared project description when your stakeholders can say things such as “I know you know what is important to me, I can see it reflected in the framing of the dilemma and success criteria”. It’s only after this that you are ready to move on to ‘what’ to the ‘how’.

So often the temptation to dive in the ‘how’, stops us from the rigour needed to check all the inherent assumptions of the ‘what’. This is what can trip us up three quarters of the way into delivering our project.

I’ll leave you to ponder the difference in how differently this project might be run depending on how it is defined:

• How to roll out our new system of financial reporting so that everyone knows what is expected of them.
• How to roll out our new system of financial reporting so that it is user friendly for all departments.
• How to design and rollout a new system of financial reporting together with all departments.
• How to improve our financial reporting so that there is increased accuracy and accountability, while improving efficiency and ease of use for everyone.

Makes you think, doesn’t it?