Meetings: Tool for Managing Benefit Realization and Stakeholder Engagements

Every organization uses the meeting as a tool to accomplish many things. This concept of a meeting has become so mundane in today's business context. Whether we are leading a project, designing a product, coordinating a program, or supporting the operations, there are meetings galore on everyone's calendar! Meetings exist to collect & share information, review progress and risks to delivery, updates to management or team such as kill gates, management checkpoints, or health check reviews, manage changes to the projects or programs or problem-solve a technical or management challenge among many other reasons to have a meeting.

However, when you ask the question of how effective the meetings are in accomplishing the outcome the meetings are supposed to address, there is a wide spectrum of comments and objections one can hear! How often is the organization or even a project using the meeting as a stakeholder engagement tool? 

There are several books, blog articles, and training guides on conducting effective meetings. Then, why are some organizations advocating against meeting free days (hickey, n.d.) or email free days?  Synthesizing major recommendations of many of these recommendations come down to three things: 1) have an agenda, 2) involve the right people, and 3) have an effective facilitator. Let us look at these principles a little closely.

The first recommendation espoused was the golden principle of having an agenda to begin the meeting. This recommendation emphasized the focus on the purpose of the meeting.  I am sure some of us can relate to not attending any meeting without an agenda. However, despite having a written agenda published several days back, how conclusively we can agree that all these effective meetings had an agenda and so were efficient? The fundamental root cause is that productivity is associated with outcomes. A mere attendance at the meetings or raising a viewpoint doesn't accomplish anything except burn people's time! The goal of every meeting is to have clear outcomes that advance towards the benefits to be realized for the benefit of the project, team or organizational objectives. This means there should be decision points agreed on and actions items articulated with a clear accountable and responsible owner and with a definitive timeline to provide an incremental update on the action items! Meetings are an effective source of productivity loss (Rajagopalan, 2014a) if there is no laser focus on outcome management.

The second recommendation we listed involved the right people! In a world that appreciates "less is more", is involving too many people in a meeting appropriate use of people's time especially if the meeting's purpose is not to disseminate information (multicast)? A successful meeting is the one that has carefully identified the right parties with the decision authority to advance completion of the agenda/objectives towards an outcome or take accountability to follow up with an action item to close (Rajagopalan, 2016). Meetings are also an effective stakeholder engagement tool because unengaged or non-participating members are also contributing to the cost of a meeting (Rajagopalan, 2014b)! These members can be released from the meeting completely or early on so that they can be productive in what they do the best! Not managing this rightful audience and measuring the contribution effectiveness of the delegates in a meeting is a leadership failure on the organizer/facilitator of the meeting.

The third challenge we noted was having a good facilitator! Especially in meetings where participation from meeting attendees is required, this facilitation is critical. While we need to allow innovation, creativity, and problem-solving to continue, we also need to make sure that we allow tangential discussions and gut-feel thoughts that derail the meeting. Depending upon the value of such ideas, the organizer may have to put this parking lot, or delegate or seek the support of a leader with the decision authority to address that right away. Having another person to be a scribe (meeting notes taker) or a scheduler to keep up with the time is also an important element of facilitation, particularly considering today's virtual meetings where the facilitator may be presenting on the screen and can't have the luxury of taking notes! Not having a timebox to ensure that outcomes are identified, or action items are listed is a disservice to the other members who are attending the meeting.

So, next time you call for a meeting or organize a meeting, think what outcomes the meeting should accomplish, what attendees with the right decision authority are present, how much are the meeting attendees able to delegate their work, and how you will facilitate the meeting to ensure that action item are identified to advance every meeting incrementally and iteratively towards realizing the benefits for the organization. 

References

Hickey, K.F. (n.d.) How to take back your productivity with no meeting Wednesday. Retrieved January 31, 2018, from https://wavelength.asana.com/workstyle-no-meeting-wednesdays/

Rajagopalan, S. (2014a). Enhancing productivity. Retrieved January 31, 2018, from http://agilesriram.blogspot.com/2014/03/enhacing-productivity.html

Rajagopalan, S. (2014b). Effective virtual meetings. Retrieved January 31, 2018, from http://agilesriram.blogspot.com/2014/05/effective-virtual-meetings.html

Rajagopalan, S. (2016). Agile or Traditional: Productivity management still has basic roots. Retrieved January 31, 2018, from http://agilesriram.blogspot.com/2016/06/agile-or-traditional-productivity.html

Starting the Problem Half solved: Strategic about Successful requirements gathering

In one of the recent round table discussions that I spoke on the differences between traditional and agile approaches, it became apparent to me that there was some disconnect in the notion of what constitutes a requirement. The software development approaches leveraging traditional plan driven approaches to project management focuses on scope planning activities that centers on requirement definition because it is well known that a successful definition of the problem means we have the problem half solved.

Considering the developments in agile approaches to project management where change is welcome even at later stages in the development, the gathering of up-front requirements is often frowned upon. Although the requirements definition may be a daunting task when there is ambiguity around it, value delivery happens only when an attempt is made to eliminate such ambiguity. When client facing members fail to ask powerful probing questions and engage the expertise to eliminate some level of ambiguity, the business goals are often compromised.

For instance, a requirement should at a minimum address what the software must to do satisfy what the users need so that the value is maximized, and benefit is realized. On the contrary, if the requirements are conflicting and attempts made to eliminate ambiguity are thwarted, then neither the traditional nor the agile approaches to software development will benefit. As the movie, Apollo 13 calls its mission at the end, such requirement gathering from the beginning can only lead to "Successful failure."

Readers are directed to check out an interesting video at this point to gather some insights into the incomplete requirement gathering This video is on youtube at https://www.youtube.com/watch?v=BKorP55Aqvg. What went wrong here? A few thoughts are as follows. Share your thoughts.

• Is starting immediately with a “No” a good approach?
• When trying to ask what the end result will look like, is attempting to over-please rather than understand the business goal appropriate?
• Is both the client facing person and the project manager on the same team as the expert?
• Were any attempts made to negotiate for an acceptable best alternative?
• Is this project setup to succeed?
• Is this a productive meeting?

What powerful questions can you add to ensure that redefine the requirements correctly? Stepping outside of this video into our own projects or products, what additional questions can we ask to understand the client’s requirement and the reasons behind the requirements better to position ourselves for success?