The Delphi Technique, Why It’s Important and When to Use It

By: Dan Creinin

I had the opportunity to spend some time with Jim Stanton (one of his claims to fame is working on the Apollo lunar landing module.  Yes that one).  He shared a story about how the team overcame some of the challenges about gaining consensus on some project’s complex issues.  The term that he used was “The Delphi Technique”.  Being curious, I went to the source of all truth to find out what it was.

What Is It?

In looking at the various definitions (and there were many), the one that seems to best describe it is found in Wikipedia:

“The Delphi method is a structured communication technique or method, originally developed as a systematic, interactive forecasting method which relies on a panel of experts.”

The Delphi Technique’s (aka the Delphi Methodology) application centers around anonymously gathering information at an organization’s ground level.  There are many survey organizations that enable organizations this. I have personally used a number of these applications in an attempt to anonymously gather and report both broad and specific cultural issues.  They have yielded some great results, in that these tools highlighted cultural oversights that were easily addressed.

Why It’s Important

Looking beyond culture, this technique has use for a given project or initiative.  By appropriately structuring the survey, the Delphi Technique answers the following questions:

  1. Is everything going well on a given project or process (and why/why not)
  2. What are other issues that we don’t know about that we need to address

In a typical organization, when executives want to understand the status of a given project, they may speak with their direct reports.  These conversations will yield a small subset of issues that need to be addressed, and, may mask some of the larger issues that directly affect the project’s success.

Anonymously gathering information through anonymous surveys across a larger population provides a more accurate and meaningful response.  This ultimately accomplishes the two objectives above much more efficiently versus interviews with a small group of direct reports.

When To Use It

There are three basic times when the Delphi Technique can be effectively applied:

  1. Sideways – When a project is going sideways, it is critical to find out why. Doing so anonymously enables open and honest conversations.  The key element is making sure that management is not interested in WHO is providing the information, but, using the information to make appropriate decisions.
  2. Beginning – Gathering information before a given initiative takes place can yield some good results. Finding the gaps between the intended goals and some potentially unintended consequences is best determined anonymously.
  3. Ongoing – It is important to not only know what isn’t working, but, to also know what is working well so that you can replicate it throughout the organization.

Conclusion

Upon wrapping up my conversation with Jim, I asked him about how NASA got to getting a man on the moon and bringing him home.  His answer was quite simple.  He loved his job, felt part of a much larger purpose, and felt that if he was not there, that he was letting someone else down by not delivering what he committed to.  While not every organization is tasked with historic objectives like a moon landing, I think that most people would like to feel that kind of passion about the teams they are on, their co-workers and the projects they are asked to complete, and to guarantee their project’s success.  The Delphi Technique is one way to help organizations achieve those goals.

Next Steps

MVC Consulting implements this technique with our Project Healthcheck service.  This service provides the following deliverables using a modified Delphi Technique:

  1. Understands the stated goals of a project, whether in flight or proposed, and creates a survey to anonymously gather information about the project.
  2. Sends the survey out to the targeted stakeholders and teams implementing the project.
  3. Provides results analysis, and potential additional information to be gathered.

To learn more about this service, please contact us through our home page, http://mvcconsulting.com/contact-us/

How Should We Assess Risk For Our Projects?

Firstly, we need to consider that doing risk assessment is our attempt as project managers to minimize the possibility of failure. We define failure as one of three things:

  • Exceeding the time allocated to complete the project
  • Spending more than the budget allocated for the project
  • Not meeting our client’s requirements

Secondly, we can generalize that projects fail for two reasons:

  • External events negatively impact the project – such as having insufficient resources, uncontrolled scope changes, and unanticipated events
  • An overly optimistic plan requires the team to hit pre-set targets – sometimes due to having these targets dictated by others without sufficient insight into what it takes to get the project done, and at other times due to failure to properly scope the project, or blithely expecting that all targets will be met in a timely way and technical problems will be minimal – in the name of being a good team player.

We would maintain that part of planning for risks consists not only of expressing time and budget estimates as ranges at the beginning of the project (which allows for the actual risks that may occur) but using those ranges and estimates to establish contingency percentages for the project (most effectively done for the project as a whole rather than at the task level). However, although contingency planning is necessary, it is not sufficient. The part that is often left out is that a full risk assessment should be done once the project team has been fully assembled and has started to work on the project – around the 20% completion mark.

Performing an assessment at this point allows the team to determine how realistic the original risk assessments were and also to add to (or subtract from) the list of possible project risks. Any assessment of this type needs to involve the key members of the team (Project/program manager, Lead Business Analyst, Lead Technical Architect, Business sponsor, senior program and QA leads, etc.) to get a true picture of all the risks impinging on the project. This type of assessment should be done one-on-one with each individual for larger programs/projects and/or using a survey instrument for smaller projects and needs to include both a quantitative assessment (What level of risk, on a numeric scale, does a particular risk represent to the project and/or to the business as well as the probability, on a numeric scale, of the risk actually coming to pass) AND in addition, a qualitative assessment.

Many organizations often ignore or downplay the need for the qualitative assessment. However, as has been proven many times with techniques like Six Sigma, your staff is usually very aware of the issues that are occurring or likely to occur, and can pinpoint them and suggest possible solutions. Our experience in doing this type of assessment for companies has shown that this type of risk assessment is best led by individuals not involved in the project being considered to avoid conflicts of interest in reporting what is actually happening within the project.

Performing this type of assessment and covering both the quantitative and qualitative issues will insure a higher likelihood of risk assessment accuracy and result in more successful projects over time.