Easy in theory, difficult in practice

Mention Delphi method to anyone who has passed their PMP certification exam and you will likely be told that it’s an information gathering technique used to gain consensus from a group of experts. Press for more information and you’ll hear that it involves anonymous submission of initial feedback.

All true, but that is like saying that a rose is just a flowering plant!

Delphi is one of the few tools which can be used on almost every project and at multiple points over its lifetime. However, because most foundational project management courses rarely provide sufficient explanation of how to apply it, many project managers lack the comfort to use it effectively.

So what are some conditions which should prompt you to consider using Delphi?

• Differing points of view - When preparing to gather input, Delphi can reduce the likelihood of a philosophical war breaking out if you are already seeing evidence that there is likely to be a difference of opinion. By using Delphi, while there still could be debate, but the focus will be on the problem and not the people.
• Subject matter experts include a mix of extroverts and introverts - While the level of expertise may be similar, if one team member is more outspoken they might have the tendency to stifle feedback from their quieter peers. A good facilitator can certainly direct questions to the latter group, but they might still lack confidence or desire to challenge their more vocal colleagues. Delphi levels the playing field by ensuring that everyone’s voice gets heard.
• Significant uncertainty - If there is objective evidence to support a decision, Delphi adds little value. However, when there is a great deal of uncertainty, assumptions are likely to proliferate and Delphi provides a good way to expose and challenge these assumptions.
• Impact of bias - If everyone is likely to have the same assessment of the scenario, there’s no point in using Delphi. However, if individual bias is likely to affect people’s perceptions, Delphi can reduce the impacts of bias on the final decision.
• Based on these criteria, the following situations could all be opportunities to use Delphi.
• Qualitative risk assessment - It might be assessing the overall risk profile for a project or trying to define the impact, probability, likelihood of detection or severity of a specific risk event. In the absence of a significant volume of historical data to draw upon, these assessments are subject to individual bias and differences of opinion.
• A sudden, urgent decision - While clearly defined decision-making criteria or quantitative methods such as expected monetary value or decision trees can help to reduce subjectivity, there are still likely to be some decisions which have to be made by the team on-the-fly. Open voting can be one way to make these decisions, but what will you do if you have a split or close-to-split vote?
• Effort, cost or duration estimation where there is little historical data and sufficient uncertainty to skew opinions

So how does one go about using Delphi?

The initial round of input can be gathered in advance of the meeting by sending the question via e-mail and requesting subject matter experts to reply providing their response & rationale via e-mail to the project manager only. The project manager will then consolidate the responses (without including people’s names) and bring that to a meeting where the responses will be shared with the group. Then, the project manager can ask the team to re-vote using some type of ballot box approach. This process can continue till a consensus is reached.

An alternative approach is to use a variant on planning poker. If the scenario is qualitative risk assessment, the project manager could give everyone three cards with the words Low, Medium, and High written on them. As each risk is presented, team members are asked to hold up the card which best represents their assessment of one of the risk event’s dimensions. Until a consensus is reached, the project manager can call on individuals who voted low as well as those who voted high to state why they did so, and a fresh round of voting can be held. This misses out on the anonymous benefits of true Delphi, but can still help overcome the impacts of individual team members monopolizing a conversation.

While it might require some preparation in advance, when working with remote or virtual teams a project manager can still apply Delphi by using anonymous polling capabilities which are often available in online conferencing services.

So the next time your team is faced with coming to a consensus, consider taking them on a detour to Delphi!

(Note: this article was originally written and published by me in July 2015 on Projecttimes.com)

I had written in an earlier article about using the analogy of insurance as a means of convincing senior stakeholders of the merits of project risk management, and I believe that most people academically recognize the value of the knowledge area.  However, it is likely that at some point in your project management career, you might be challenged to provide more tangible evidence of its benefits.

Risk management activities consume resources that a sponsor or stakeholder could argue would be better invested in delivering a project’s scope.  Similarly, team members might question the benefits of participating in the periodic refreshing of the risk register or their involvement in risk response activities.

When dealing with risk management practices, it can be difficult to provide tangible evidence of their value as in many respects they are a hygiene factor – we expect our projects to have predictability relative to committed baselines, and so effort spent in meeting expectations will often be seen as business as usual as opposed to something to be recognized and encouraged.

Here are a few methods of demonstrating tangible benefits to help reinforce project risk management perceived value with the decision makers.

1. Include opportunities in the scope of your project risk management activities.  While threat reduction focuses on meeting project expectations, exploiting opportunities could result in an increase in realized project benefits.

2. Use risk register & issue log data to increase institutional knowledge.  While there is often a rush on the part of resource managers to move project managers and team members to their next project, ensure there is sufficient time in your project closeout phase to analyze those issues that had not been identified as risks and incorporate the ones that have a likelihood of recurring into your knowledge bases.  Of course, knowledge that is stored but not used is wasted, but overtime it should be possible to show a reduction in the number of “been there, done that” issues.

3. Measure the overall effort spent on issue management (aka firefighting) activities when compared with overall effort spent on risk management.  Over time, if risk response plans are appropriately executed, you should see a reduction in firefighting effort with roughly the same level of effort being spent on risk management.  Not only will this reflect more in scope work productivity on the part of team members, but its a great way to ensure that your risk management practices are not gold-plated.

With project resource constraints being unlikely to ease soon, project management practices will continue to be scrutinized – through opportunity management and effort measurement, you can reduce the odds of the project risk management baby being thrown out with the unnecessary process bath water.

(Note: this article was originally written and published by me in September 2011 on my personal blog, kbondale.wordpress.com)

Since 2015 when Google's research identified psychological safety as one of the key attributes of high performing teams, it has received a lot of airtime. While there might be greater awareness of this characteristic, there is little guidance on how to cultivate it within an organization or team where it is absent. Hence, when I saw today's Dilbert cartoon strip, it reminded me that instilling psychological safety is a cultural transformation.

Scott Adams does not provide insight into why the Pointy Haired Boss fired Ted but Wally's curiosity about recent terminations and his use of Ted as a scapegoat for his project's schedule variance clearly demonstrates that they are working within a corrosive culture of fear where failure is not recognized as a statistically expected outcome but rather is the catalyst for a witch hunt.

Sound familiar to any of you?

In one of my earlier articles, I'd provided some suggestions on how a project manager could help to instill psychological safety within their team but did not cover the need to understand the underlying causes for its absence.

While we think about psychological safety as being a team-level dynamic, it is a deeply personal feeling and like all change, needs to start at a individual level.
There are two forces operating against our feeling psychologically safe - from without and from within.

Our colleagues possess the ability to destroy our confidence in being able to take calculated risks. Every time we see someone being criticized for attempting to push the envelope it supports our personal need to play it safe. Relationship-oriented organizations can unwittingly reinforce this as no one wants to be perceived as rocking the boat.

But we shouldn't ignore our own insecurities which might be causing us to avoid taking risks. I've frequently encountered individuals who hesitated to make a decision which they believed to be the right one simply because they felt they couldn't. When pushed to identify a specific policy, standard or mandate supporting this, they were unable to and yet they still remained unwilling to proceed. When their leaders were asked if they had said anything which might have caused this, they were flummoxed. Pogo continues to be omniscient - "We have met the enemy and he is us."

Taking the time to understand what might be causing one of our team members to feel unsafe is time well spent as it will improve our likelihood of changing their perceptions.

When organizations decide to transition from traditional approaches to agile ones, this change impacts all project roles but the most drastic shift could be that experienced by project managers.

This is especially true for organizations that are at a high level of project management maturity. In these, project sponsors or owners are likely already used to working closely with the project team and are comfortable with the need to be actively engaged in refining and prioritizing requirements. Project team members are also used to proactively informing their project managers of issues and provide their task progress updates using quantitative effort remaining estimates instead of the less trustworthy percentage complete.

For project managers, however, the shift in the nature of their roles is likely to be more significant.

On a traditional project, during planning and execution phases, the project manager plays a very directive role and may even act with a reasonable amount of authority. On the agile project, this approach won’t work as it could stifle or throttle the communication flow between the team and the customer and can reduce the empowerment of the team to get the work done.

A project manager that is used to spending hours on administrative activities such as managing change requests, updating massive project schedules and producing voluminous status reports will suddenly find themselves with less need to focus on the artifacts of the PM process and greater ability to facilitate communication between the customer and the team as well as being actively engaged in removing any and all roadblocks towards achieving optimal velocity.

This shift from administrative and directive activities during the core project phases should not faze PMs with well honed soft skills but for the less seasoned practitioners it is a good idea to be paired up with an agile-savvy mentor who has sufficient availability (and patience!) to be able to participate as an observer to scrum sessions, iteration planning meetings and iteration retrospectives. The beauty of agile is that the PM is able to receive actionable feedback at multiple times over the lifetime of the project without the need to wait till the project is over to know how they did and what could have been refined.

Project management is all about realizing change, but sometimes the hardest change to effect is in ourselves!

(Note: this article was originally written and published in June 2011 on my personal blog, kbondale.wordpress.com)

The end is in sight, deliverables have been approved, the team is starting to eye their next assignments, and your sponsor is likely breathing a huge sigh of relief.

But before you shut the door and move on to your next gig, here are three questions to reflect upon.

If we did not deliver the expected business outcomes, what could I have done different?

Projects fail to achieve their original expectations for a variety of reasons, many of which are outside of the control of the project team. But just because external factors or shortfalls from team members or other stakeholders might have been key contributing factors doesn't mean that we shouldn't do some soul-searching to envision what might have been if we had taken a different course of action.

This reflection should happen frequently over the life of a project. Waiting till the end of a project to consider our own performance means we've likely missed some important learnings, but this final reflection provides the opportunity to consolidate the micro-lessons into one or two key calls for personal action.

Would I have wanted to work with me?

This second question moves us from the "what" to the "how". The project may have been deemed a success by our customers, but do we have evidence to prove that team members or stakeholders enjoyed the journey? If not, was that related to how we treated them, especially when the going got tough?

Our ability to forge and grow positive relationships is the secret sauce towards our success as project managers, and if we left bruised egos and morale issues in our wake, we've lost the long game.

Did I further any of my personal goals through my work on this project?

We don't manage projects just to get paid well or to have a fancy title. Many professions pay better and provide more glory if that is all we wish to achieve.

What higher purpose of ours did we progress through the project, and if the answer is "nothing", isn't that reason enough to question our choices? Perhaps this is an opportunity to identify specific outcomes that are aligned with our long term aspirations which we'd like to achieve in our next project.

Introspection will establish your personal continuous improvement from one project to the next.

(Note: this article was written and published by me in March 2017 on my personal blog, kbondale.wordpress.com)