Consensus Isn’t Alignment: Lessons from NGT, Delphi, and Wideband Delphi

When coaching a person for their PMP exam, a discussion emerged emphasizing that consensus meant alignment of expectations! Early in my career, I understood the expression, "the elephant in the room," where everyone in a collective setting fail to address a controversial issue despite the knowledge of its obvious existence. The comfort of not addressing it, bringing it to the surface due to the sensitivity of the issues, or even be labelled a naysayer for acknowledging it publicly were a few things I had observed are risks that impede value delivery! To me, silent agreement or unanimous consensus without any discussion is frequently a possible indication that important knowledge is not visible into the room and subsequently never makes it into the decision-making. 

That realization pushed me toward structured consensus techniques, not because I love process, but because I had seen what unstructured collaboration does under pressure. So, I explained three techniques, in particular, that have stayed with me over the years in light of a product that once I managed: These are the Nominal Group Technique (NGT), Delphi, and Wideband Delphi. Each earned its place through practical scars and are not juts theory.

Sometime around 2012, I was developing an innovative first-responder mobile application  for a pharmaceutical client. The application integrated with portable ECG collectors connected to an iPad and used in an ambulance. The goal was to capture ECG data from unconscious or incoherent patients, detect critical cardia conditions in real time and transmit actionable insights to hospital before arrival enabling immediate treatment including invasive interventions if needed. 

Developing this application was not just a product. It was a medical device ecosystem operating under clinical, technical, regulatory, and ethical constraints. I found out that everyone was competent and were knowledgeable but not everyone spoke the same language. Medical experts dominated the dialog about the criticality while engineers optimized the solution prematurely. Neither factored the regulatory risks until those members were specifically engaged. So, it was apparent to me that the 'unknown unknown' stayed unspoken sometimes due to the deference to the sensitivity or criticality of impact. 

Here is where I used the Nominal Group Technique (NGT). The goal was to get more breadth of features and risks to delivery without getting into the solution mode! I facilitated the interaction face-to-face in a combined setting using silent data generation (dot voting, brainstorming), undebated round-robin (brainwriting, Yes-And scenario writing), facilitated inter-group clarification (forming multiple teams of clinical, engineering, and regulatory members working together) to prioritize among diverse requirements. The advantage of this technique is that it is encouraged diverse participation and promoted consensus. It was not quick but picked up on many constraints, assumptions, risks, and dependencies. I particularly saw this NGT facilitation led to increased collaboration. For example: 

• Clinicians highlighted most critical ECG patterns to focus on such as ventricular fibrillation, elevated myocardial infarction and a few others
• Engineers emphasized battery drain and securing against signal interference risks
• Designers questioned about the ambulatory users to design for stability and UX considerations when first responders were operating in a stressful environment with gloves and moving vehicles
• Compliance specialists named medical, legal, and regulatory considerations for approval

Obviously, NGT didn't give us all the answers but it shaped the product needs better leading to the prioritization of minimum viable product. We diverged first across the problem space before converging on solution space. But, as the solution began taking space with more people involved, I found some began identifying requirements soon after the meetings were over. I found that dominant personalities in the room or the absence of anonymity were challenging for people to speak up in these facilitated settings. Here is where I found the Delphi technique come to the rescue.

The Delphi technique required people to raise their concerns in anonymous surveys and questionnaires. These surveys and questionnaire required careful design to avoid double-barred and leading questions but focused on identifying those risks across the lifecycle, regulatory and ethical edge cases, and most importantly the assumptions people were willing to challenge anonymously but not publicly. I would say that the anonymity brought known unknowns and unknown knows.  Designing the survey and questionnaire took time working with expert sometimes to ensure they collected the qualitative and quantitative data correctly and working iteratively to understand some answers. 

The Delphi technique didn't remove disagreements when the new risks and challenges unidentified in public settings were brought up. But, it removed the fear of identifying them and the bias associated with group thinking. As the development of the solution emerged, the focus shifted to ensuring that our solutions were built in such a way it maximized the regulatory approval and learning from the piloted first responders. Here is where I found the Wideband Delphi helpful. 

The Wideband Delphi is a hybrid technique. It combined the best of both the NGT and the Delphi technique. No longer was the focus on diverging to understand the problem space and converging to focus on solutions! No longer was the focus on power imbalances or biased interpretations leading to further risks as all the team members were in a 'performing' stage! But, as first responders identifying needs such as the UX needs to be simpler (fewer bigger buttons to click rather than nested menus) and iterative regulatory focus emerged (agreements on the details behind the ECG patterns), a mini Delphi approach to product backlog (missed documentation, design considerations) from experts along with a discussion to prioritize and estimate them followed. The planning poker and PERT are all Wideband Delphi techniques to facilitate them in a light-weight setting.  

It was wonderful to retrace my earlier product development experience to reconnect with these techniques on how we need to unearth risks. All these techniques have been time-tested and practiced in various settings whether or not we know them by their names! But, ignoring their benefits and thinking silent consensus is team alignment is not acknowledging the elephant in the room. 

The person I was coaching felt very grounded and satisfied. What do you think? What other techniques have you used or benefitted from?

Risk Management in Agile

Extending observations from one of the classes I facilitated on digital project management, I was wondering how to address the impact of risk management in agile initiatives. Earlier this month, I had a family emergency and I traveled to India to meet a family member who was critically admitted to the hospital. As I discussed the medical condition of my family member with the physician, I remembered one of my earlier speeches where I had discussed the notion of ECG waveform as the warning trigger of risk in monitoring one's health daily.

I resonated with the ECG waveform and its principles to agile approaches to project management or product development. The ECG waveform represents the heart pumping a certain volume of blood every fraction of a second (varies from person to person due to many reasons). From a physiological standpoint, the P wave represents the atrial contraction pumping oxygenated blood into the ventricular chambers. The QRS wave represents the ventricular contraction denoting the rate of  blood distribution. Finally, the T wave represents the ventricular relaxation before the heart is ready for another cycle. It is, therefore, no wonder, that one can think of every PQRST cycle as an iteration. The amount of blood consistently bumped represents the velocity.

Now, if this analogy is true, then, we can relate to risk also in an agile iteration. When we contract work to other teams or depend on others to complete the work, the functionality of the other organs (e.g.: respiratory systems) to deliver oxygenated blood without any challenges arising from circulation is critical. It is not surprising, therefore, why project managers always relate to the risk domain when procurement domain is involved because non-delivery per contract or non-performance of contracted work leads to the risk of resource overloading.

When one doesn't take care of their personal health properly by following quality policies (such as dieting or exercise), challenges arise such as a heart attack. The same concepts apply when the team compromises on technical excellence in design or addressing quality by design principles in their workflow. The escaped defect therefore represents the heart attack or an emergency trip to the hospital.

When the team members in the team fail to work together, that leads to failure. For instance, the block within heart system causes to resistance to smooth flow. Similarly, resistance to agile practices and lack of the team's self-organization introduces the risk of failure.

When the team is not self-organized or demonstrating high levels of team maturity, the scope compromises in velocity demotivates the team. Although the heart is much more resilient, overwork or imbalance introduces anxiety and stress, and people react differently. Similarly, lack of product vision or constant changes to iteration backlog compromises the team's ability to deliver. Many business challenges can impede the team's ability to deliver as well and become a high-performing team.

Such challenges, when go unchecked, impact the team's ability to deliver over a longer timeframe. The emergency visits to hospital leads to a loss of trust for caretakers requiring external intervention in the form of medicines or medically recommended rest. Stakeholders can lose confidence in the team's ability to consistently deliver on the strategic product roadmap when costs increase more than the benefits realized. Customer satisfaction fatigue can be seen in the voice of customer feedback and lack of adequate referrals.

In summary, I can see how this simple ECG waveform that we can all relate to proves to be emphasizing how risk is pertinent to everyone's health in daily life. If every day is a project, then, every heartbeat is an iteration which has the seeds of risks. The warning triggers must be understood and appropriately managed even in an agile project.

Thoughts? Please share with me.