Taking Care of Your Stakeholders

When planning the requirements definition phase of a project it is necessary for PMs and BAs to consider the diversity of stakeholders and their need for clarity, care taking and accountability.

In a recent project to implement an enterprise wide software product and related procedural and organizational change, the PM initiated a process in which a large number of business operations stakeholders from different departments would take part in the analysis and discovery of requirements for changes to the package and to plan for the procedures they would follow to make the system effective in their business areas.

The process was referred to as gap-fit analysis.

Members of each of the business units were to be introduced to the system’s features that would impact their roles in a series of presentations and demos. Then the stakeholders would explore the system’s features in a sand box environment. They would use their experience and knowledge of their roles to decide on change requirements.

Senior management had agreed to the principle that there would be minimal change to the package. People would change their procedures to fit the package rather than change the package to enable retention of the status quo. 

The PM had a good conceptual plan and buy-in from senior and middle management. But, things started to go wrong when attendees (supervisors, clerical staff and lower level managers) began to complain about the fact that the schedule of presentations was dictated to them and they weren’t given sufficient time to clear their schedules. Some pressure from above got them into the presentations.

Then, having attended the presentations, which were informative and allowed time for discussions and questions, many attendees did not have a clear understanding of their next steps. They were unclear about what they were supposed to do and how they were supposed to do it, even though they were given a template to use to provide their input.

Some people left their presentations thinking that they had to completely change the way they had been working for decades simply because the new system and the IT department said so.

Others were anxious about using the sand box, an instance of the system that had been set up to enable them to “play” with the features that supported their roles. They were afraid to mess things up, even though the feedback template had a sentence on it that explicitly said that it was ok to just play without concern. Some never read the introduction to the template while others didn’t really let what they read relieve their anxiety.

Stakeholders did not know who they could call if they ran into trouble. They had not agreed to the arbitrary ten day time frame for doing their exploration and turning in their feedback. They were not given the “hand-holding” they needed.

Within a week of the onset of the presentations, senior business management was reporting the displeasure of their people and as a result, their own displeasure, to the PM and then, when the PM made excuses, to his director.

Several people did not really know what “Gap-fit” analysis meant.

Intervention Needed

An intervention was needed to turn things around and make the best of the situation.

What went wrong? What were the causes underlying the near failure of a logical and sound conceptual plan? What needed to be done to turn things around?

At the root of the problem were untested and incorrect assumptions and expectations:

• The stakeholders’ needs and priorities were not fully defined and validated.
• The need for speed was assumed.
• The participants’ understanding of what was being asked of them, why it was being asked and how they should go about doing it was assumed but not validated with them.
• Participants were expected to behave like assertive “professionals”.

Needs and priorities

The assumption that the needs and priorities of business stakeholders in a project are completely aligned with project priorities is more often incorrect than correct. Current operations always take precedence over any future oriented activity. Projects are always future oriented.

The desire to maintain the status quo is usually quite strong, even when the status quo is painful. People dislike uncertainty. There will be resistance.

Make sure participants in requirements gathering activities are given sufficient time to adjust their schedules and that they are convinced or at least open to the idea that the project will improve their lives and the health and well being of the business. Remember the participants are working full time on their current jobs and that the requirements definition work is extra.

Senior level mandates might get people into the room but it won’t necessarily make them receptive and cooperative.

The Need for Speed

Getting things done quickly in projects is a common excuse for sloppy planning and insensitive communications. Clearly, we want to get things done fast but not at the expense of quality. Over and over again we pay for moving too quickly by having to suffer the consequences of errors and omissions. Planning takes time. Assuming that people will know what to do and will do it takes no time, but is a formula for disaster.

In this case, a week or two spent on planning, documenting and vetting the schedule and process would have gone a long way to make for a more successful engagement. People would have better understood objectives, their roles and responsibilities, and the work they were to perform. Planning would probably have identified the need for support and it’s ramifications on cost and schedule.

Participants’ Understanding

Assuming that people know more than they do is all too common. Some may think “since I know something, everyone else does too.”

I once facilitated a knowledge exchange between IT specialists and the bankers they supported. At the break after the bankers made their presentation regarding their business one of the technology guys came over to me and said that he finally understood what it felt like to be bombarded with a bunch of acronyms that were totally incomprehensible to him.

When we ask people to do something, we need to make sure they know what we are talking about. We cannot rely on them to ask. People are often averse to asking questions because they feel it would make them look stupid. Yes, they need to get over that. But until they do, it is necessary to draw them out, explain things clearly and in a language they are likely to understand and get them to feed their understanding back to us. This takes time and effort, but less time and effort than doing it after the fact.

Assertive professionals

Expecting people to behave like assertive professionals is asking for trouble. First of all we barely know how such beings behave and even if we did there would be significant exceptions. Some people are naturally assertive while others have to work on it. The ones that have to work on assertiveness may not be aware of their need. They just do what comes naturally.

When faced with someone who doesn’t ask questions or make their needs known take the time and effort to draw them out. Intuit the questions they might have by reading body language and facial expressions. Ask questions like, “Some people may think that this is a dumb idea, why would they think that?” Use written responses and small group exec praises to get people who are reticent to express themselves in large groups to talk. Take the time to list probable questions and issues, both positive and negative, so you can raise them if no one else does.

Conclusion

To maximize the probability of the success of your requirements and design sessions take a service oriented attitude. You are there to serve the stakeholders not just to elicit and document their requirements. Being a good servant, you must anticipate their needs to give your stakeholders what they want and need before they ask for it. Intuit their needs and cater to them. Find subtle ways to transform resistance into cooperation by building trust and understanding stakeholders’ objectives and how they relate to project objectives.

Know the personalities of your stakeholders and the organization’s cultural norms. Adapt your approach so that you are giving them what they need in the way they need it. Test your assumptions, ask the stakeholders for their cooperation and follow up to find out if you have met their expectations.

Don’t forget to leave your comments below.