In my last post I described 3 reasons customers cite for not participating in development. One of the reasons, and one that a project manager or business analyst can impact directly, is the customers feel that the meetings are not a productive use of their time. They feel the meetings don’t accomplish anything, take too long, or that they were unable to contribute and their presence wasn’t necessary.
I’ve witnessed many meetings with customers that I would describe as dysfunctional, and I’ve worked in many organizations where meetings with no agenda, no direction and unclear outcomes are the accepted norm. The focus of the meeting is vague, such as “requirements meeting” or “planning meeting” or is clear to the project team but not to the customer, such as “Vision and objective discovery for Phase 2 of BW-SAP roll-out.” Other common problems are where the meeting is dominated by one or two participants, the subject of discussion wanders, or where each participant is left to determine the outcome for themselves. I’ve often been left wondering how anything got done in these organizations. One of my co-workers summarized it best when he mused that “most large organizations succeed in spite of themselves.”
There are two elements required to solve these problems and get frustrated customers back to your meetings. The first is to prepare ahead of time. Prepare the customers, prepare your team, and prepare the meeting. The second part is to manage the meeting, which will be the subject of a later post.
Preparing the customers
If the customers are frustrated, you will need to convince them that future meetings will be better. Before the meeting, set up phone calls or meetings to discuss their issues directly. I prefer to meet with each customer individually rather than as a group, as it encourages the openness needed to find the root of the problems, while avoiding the situation where the customers gang up on you or the team.
Approach this conversation as a negotiation. Make sure you have some requests to make of them, such as ensuring they are prepared when they come to the meeting and that the attendees will have the knowledge and authority to make key decisions. In return, ensure them that the meeting will not go over the prescribed time, that the meeting will be facilitated in order to ensure it stays on track, and that there will be a follow-up conversation to evaluate what went well and what didn’t, so they can provide feedback to improve the process.
One pitfall to avoid is the Blame Game. It can feel satisfying to point out that the dysfunctional meetings weren’t your fault, and it is instinctive to get defensive when the customer is presenting their grievances. However, pointing fingers rarely provides any value to the discussion and is unlikely to convince the customer to participate. Focus on what needs to change in the future without dwelling on who was at fault.
Preparing your team
Technical teams must participate or at least be represented in planning, development and design meetings. However, I’ve had customers tell me that they don’t want technical staff in the meetings because they are seen as overly negative, always quashing ideas in brainstorming sessions, or because they carry the conversation into technical discussions that the customers don’t have the knowledge to participate in. Ensure your team members know what their role is in the meeting. In most cases they are there to ask questions to better understand the customer’s problems and ideas, and they may also be needed for their ability to give rough estimates.
Preparing the meeting
As I mentioned in a previous post, I don’t understand why it’s so rare that a meeting’s purpose and agenda is provided in its invitation. Most business people today go from meeting to meeting, and keeping track of which one is for what purpose can be next to impossible. Provide a brief description of the purpose and the expected outcome of the meeting and provide attachments or links for additional information, such as the items currently on the backlog that are to be selected in the meeting. Don’t bother writing long descriptions with detailed instructions, however. Most people just scan their emails these days, and anything longer than a paragraph is put on the ‘to do later’ pile.
Don’t overestimate what can be accomplished. Aim for small meetings with modest goals to start. Choosing the stories from the backlog to be included in a sprint can take several hours, for example, when the sprints are long or when the customers don’t have a lot of experience with Scrum. Don’t expect to do a complete analysis and firm estimation of the user stories in the same meeting.
Preparation is half the battle, and if you’ve done the above you’ll be halfway to getting your customers back on board with development. Delivering the meeting is the other 50%, and it will be the subject of my next post.