Working with Various Personalities among Stakeholders

Smooth stakeholder participation is integral to the success of any project. Sometimes stakeholders hold information that is essential to thorough requirements discovery, so it is important that they be forthcoming. Other stakeholders must sign off on requirements as being final in order for a project to move forward, so it is important that they be decisive and willing to let go the discovery stage of a project. All identified stakeholders have an important role in the success of the project, so it is important that they be participatory. The failure to participate fully and agreeably by any given stakeholder can compromise the success of the project for which the business analyst is responsible. Therefore, any obstacles to stakeholders’ smooth participation are felt more keenly in requirements gathering (and other aspects of business analysis) than they are in many other endeavors.

Here, we have outlined some of the more common roadblocks business analysts may encounter in working with stakeholders along with some solutions to resolve them.

Stakeholders who fear commitment – Some stakeholders, particularly those who have been promised a finished project in the past that did not materialize as they had envisioned, are afraid to commit to finished requirements or to declare the discovery stage final. If something important was overlooked the first time, they may reason, what are we missing this time? This places an analyst in a difficult position—she also does not want to miss any important requirements that may lurk somewhere in the stakeholders’ minds or experiences, but a deadline is looming. In these cases, try the following methods:

1. If you have time, employ some discovery methods that foster an exhaustive approach. Brainstorming, requirements workshops, and other discovery methods that encourage lots of ideas and group creativity may help stakeholders to feel they are not overlooking anything important. If you have only done one-on-one interviews, job observation, and other independent analysis, that may be less reassuring to them.

2. Reassure your stakeholders, if you can, that this one project is not the end of updates for their system. Many organizations foster some type of weekly, monthly, or quarterly software builds that correct glitches and implement minor enhancements. If your organization offers this and your stakeholders later think of some point that they missed, reassure them that you and the project manager will work to place high priority on their system’s enhancement.

3. If neither of these approaches works, you will need to involve your project manager, if one is available. A project manager can stifle any waffling much better than an analyst because the project manager has the authority to say, “Beginning Tuesday, development will start, ready or not.” The prospect of a looming deadline may force stakeholders to think harder about what a project should encompass. If you as the analyst are also functioning in the project manager role, you may have to put on your project manager hat and ignore your natural analyst’s tendency to want to unearth more requirements that may lurk in the recesses of these reluctant stakeholders’ minds.

Stakeholders who cannot let go or compromise – Stakeholders with particularly strong personalities may sometimes feel quite fervently that a system should or should not contain a certain feature or function a certain way. A lead developer, for example may feel that a system should not pull data from an outside source, because then the resulting data would take two full minutes to display to the end user. He may feel that this would be ridiculous, needless and disastrous to customer service. But the project sponsor may have her own reasons for feeling that a two-minute wait is inconsequential for the end user. “Our customers are used to waiting for this type of system; they know that the data is complex and don’t expect a quick display. Further, it is important that the data pull from this source.” But if the developer disagrees cannot let go and build the project as it’s written in the requirements, this can result in long (and tense) meetings and email threads and project delay. In these cases:

1. List any reservations that your dissenting stakeholder(s) have in your documentation as known risks or dependencies. “Per our development team, this will result in a two-minute delay in results display to the end user.” Send the revised documentation out to your stakeholders, particularly the opposing parties and management. This will assure your stakeholder that he has been heard, and that his concerns are on record.

2. Assure the reluctant stakeholder that he will not be responsible for any decision he does not agree with, and that it will not negatively reflect his job performance. “Any customer service fall-out from this decision will not affect you as a developer, Tom. It is Jan’s final decision—she represents the customers. The only thing that you will be judged on is whether the software runs as described in the documentation, which does note your concern as a risk.”

3. You may have two differing stakeholders who should share the same perspective—say two project sponsors or two customer service representatives—but who have differing views that do not appear as if they will resolve in a timely manner. In these cases, a third party may need to step in and negotiate. Your job is to make the right people aware of the issue in a way that will not alienate the stakeholders. Send a diplomatic email to the project manager with copy to the two parties: “Jan and Mike need more time to research the customer impact of this enhancement. They are invested in doing a thorough job for our customers. But together, they are not yet able to commit to a path for this solution. I know that we have a fast-approaching deadline; advise?” If you don’t have a project manager, send it to your manager.

Stakeholders who are disinterested or uninvolved – You may have a stakeholder who just does not think your project is that important or within the purview of his job.

1. In these cases, try diplomacy. If you approach your stakeholder in person or on the phone, also reiterate in an email (for documentation), “Fred, no one knows as much about XYZ system as you do, and we really need your input in our meetings so that we can be sure nothing we are doing will compromise it. We would hate to deploy this new system and have it change the behavior of your XYZ system. We know your time is limited—can you tell me some times that may work for you? Perhaps I can move the meetings to accommodate your schedule.” If Fred still refuses to come to meetings or offer feedback, send a second email with copy to the project manager.

2. If you feel his lack of participation may compromise the integrity of your project, explain your concerns to your manager. Forward her your emails to Fred. She may have more persuasive powers than you. Although you want your project to be a success, never lose your cool or panic. You cannot make someone who does not report to you do something if they don’t feel the responsibility to do it. Know that if diplomacy does not work, and your manager(s) cannot pull any strings, and the end project is indeed compromised, then management will know you acted in good faith.

Any wrinkles in stakeholder participation can slow a project considerably and/or put the integrity of the solution at risk. Hopefully these suggestions will help you move your project (and its stakeholders) along in a timely manner, even when you encounter the inevitable stakeholder challenges.