The Wide World of Stakeholder Approvals

I have found that the simplest tasks or gates within an SDLC (System Development Life Cycle) can often be the most stressful.

One of these tasks in particular has left me frustrated beyond belief at times. I’m speaking about, of course, Stakeholder Approvals on Requirements. Let’s look at the following scenario:

As a project team, we have completed the requirements gathering process, we have answered any outstanding questions, we have documented the requirements thoroughly, we have had a walkthrough of the requirements, and the approval session and timelines has been established. Approvals should be obtained well within the time frame.

WRONG! Only in a perfect storm would this occur.

Often times as BA’s we have to battle different personalities that can hinder the approval process and cause delays.

The Part Timers

These are stakeholders that glance over the requirements and approves without reading in full detail. This can create more work later in the project life cycle as requirement may have been overlooked or stated incorrectly and will need to be corrected and reapproved.

Try to express to these stakeholders during the kickoff and reiterate during the requirements process how important it is to fully review everything. If you feel that they are not fully committed ask if they would rather be a reviewer and delegate their approval to another stakeholder.

The Bewildered

Initially, these stakeholders understand the requirements during the elicitation process, but when review and approval time comes around they do not understand the requirements as they are presented during the review and approval process.

It is important for all stakeholders to understand the requirements, so it is your job as a BA to confirm this. If they are unprepared for a review meeting and they are challenging every question, try cancelling the meeting until they are prepared; this can really only be achieved if it is a one-on-one review or just a couple of people. If there is a larger group attending the review, ask the person to hold their questions and have a side meeting with them to cover the requirements so they fully understand. Don’t ignore the situation. There may be a viable reason the person doesn’t understand. Perhaps someone else doesn’t understand either, so you may have to clarify your requirements.

The Late to the Party Stakeholders

These types of stakeholders wait until the absolute last minute to provide feedback and/or approval on requirements. I particularly find it extremely difficult to work with this personality type the most. However, I have developed a few ways to overcome the problems BA’s face .

---

---

Be in frequent contact with them. It may seem like you are bombarding them with phone calls, emails, or personal interactions, but it is important for them to know how important this process is to you and the company.

Another technique is to set the review deadline date ahead of the stakeholder approval date. This way the stakeholder will review the material by the deadline and there will be time available to answer questions and make updates prior to the “actual” approval date.

Lastly, if push comes to shove, ask yourself: Does this stakeholder need to approve the requirements?

Is there someone else that can step in and approve for them? Often times In these situations I find myself asking these questions. If there are multiple people from the same department on the review and the one with the approval role is not timely I will notify he or she along with their manager that I will remove their approval role by a certain date and move forward with the approval from a reviewer role member from the same department. The initial response may be negative, but if the stakeholder in question is constantly missing deadlines there are few options.

The Flip-floppers

Flip-flopper is a phrase that has been coined in recently Presidential elections. A flip-flopper is stakeholder that keeps changing their minds on requirements and often at the last minute. Try reviewing the requirements in a power workshop that leads up to the final review session. In this setting the stakeholder feels more involved in the process and if questions arise then they will be brought up sooner and can be handled properly. No more last-minute change controls for additional time on the project. A side meeting may be needed to go over requirements and questions in detail.

The Grammar Police

We all know this stakeholder. Don’t misunderstand me. Grammar is important. We should not provide documented requirements that are full of grammatical errors and misspellings. However, should the approval on requirements be delayed due to a couple misspellings? No. Small grammatical errors can be resolved after the approval and be noted as such if ever questioned on what changed. Express your concerns for the timeliness and deadlines of the project. Examine with the stakeholder if the concept of the context is correct and how perhaps all the wordsmithing isn’t always necessary.

The Noobs

These stakeholders are new to the project by either replacing a current stakeholder or a new resource was needed over an area of the requirements. Initially, you may not have complete buy in to the project and if they have to approve requirements this stakeholder will have lots of questions that will slow down the approval process. To remedy this situation, cover in great detail the benefits of the project. This way they will see value in what the core group is doing and the solution in general. It is important to work alongside with the project manager during this process in order to provide a solid front line against any speculation.

Where do we go from here?

Communication is the key aspect of dealing with these various personality types. If communication breaks down, then the project is going down in flames. The advancement in technology has often made us “lazy” in the sense that we no longer speak to stakeholders face-to-face or over the phone. We rely on email, text messages, or software applications that provide automatic updates to stakeholders which can often get over looked or ignored. Pick up a phone or set up a quick meeting to discuss. If we, as BA’s, can effectively communicate the goals and expectations then every stakeholder should be held accountable for their actions or lack thereof.