Skip to main content

Author: Tom McIntire

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 .


Advertisement

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.

So, You Want to be a Business Analysis Professional?

Recently I had a co-worker ask me “What was your progression or path to get where you are today?” At first, I was disoriented and didn’t know how to respond.

He continued with “I want to be a BA. It is part of my 5-year plan. I have been with the company as a Quality Assurance Tester for four years now and haven’t been able to make headway”.

At that point, I realized where the original question came from. The hard part then was answering the question. I mentioned the common things such as working hard, get noticed, and other business phrases.

“To be honest,” I said, “The answer is not simple, and paths are never the same from one person to the next.”

Truthfully! The answer is different for everyone. This is pure speculation, but I would assume most people do not go to a 4-year college to become a Business Analyst. There is after school training such as certifications for business analytics, but typically certifications are obtained once you are in the field and know what you want to do in the field.

I proceeded to tell him my story.

I was born on a hot summer’s day in August 1981. Too far back. Now skip forward 28 years, and I graduated from Central Michigan University with a B.S. in Social Sciences with aspirations of becoming a teacher in the private sector. Unknowingly to me at the time, so did every other person in the world. This created an overabundance of unemployed teachers and not enough positions available. I then started working at a furniture company store as a Supervisor for one of the independently owned franchises. I won’t name the company, but let’s say just say they are known for their recliners. This was my first exposure to business analytics in a general sense as I was generating financial reports, providing cost analysis, longevity analysis, and break-even analysis on furniture as well as light bulbs and cleaning supplies.

A few years go by and a transition period came up when the franchise owners decided to retire. A management company was hired to run the day to day activities until the company could find a new owner for a franchise. During this period, there were three stores running under the management company and the previous owners shut down the servers and network. It is difficult to operate three stores when inventory, schedules, and every other day-to-day operation cannot be communicated between the stores electronically. The management company left someone in charge that was doing the best they could without modern technology. I went to this person and expressed my concerns. She agreed operations were difficult but didn’t know where to start when there was no budget and the transition period was to last only 3-6 months. I mentioned the previous model hardware was still in a tech closet in the back and if she gave me a week, I could see if I could get a new network established between the three stores with minimal cost to the company. She thought that was a fantastic idea and I proceeded. I accomplished the task in less than a week, and the business was humming on new fuel and a positive attitude once again.


Advertisement

Shortly after, representatives from the parent company made a visit to assess the current state of the operation as a potential buyer for the franchise was found. They knew the previous owners and knew that when they retired that the majority of the technology was dismantled. They were astonished by the fact that we were running so smoothly albeit technology from the late 1990’s. They were fascinated by how this came to be and the manager told them what I had done and what I had been doing before and after the transition period. How I went from a store supervisor and writing schedules, placing shipments, and customer orders to a warehouse manager, store supervisor, and resident IT Specialist. Apparently, this was a big deal. Honestly, I just didn’t want to write by hand customer orders any longer. It took 15 minutes of my time and had to be in triplicate.

One of the representatives was the director overseeing the IT System Business Analysts in the IT Department at headquarters. He asked what seemed like a million questions about what I did, how I knew what I was doing and how to do it, and what my ambitions were. I answered all of his questions and gave them all a tour of each of the stores. He showed an interest in me and invited me down to the company headquarters to meet his team and take a tour of the facility as I have never been. He said, “Consider it a job interview.”

Nervous as I was the next week I drove 2 hours away to a place I had never been, to interview for a job I had no idea what it was about. This was my first encounter to the actual role of a Business Analyst. After taking a tour, I sat down with the team for an interview. It was a standard interview with standard interview questions. However, when it came to technical questions regarding computer systems and networks I was nervous and kept reminding them that I didn’t have a degree in Computer Science or a related field; that I was self-taught except for a few college courses and my background was in Social Sciences and Language Arts. After about the 5th time doing this, one of the team members said, “Why do you keep stating that you don’t have a Computer Science degree? Don’t feel self-conscious. None of us have Computer Science degrees; I was a Marketing major”.

This has stuck with me over the years: In an area where Information Technology is rampant, no one had a degree in the field. There were Associates with history degrees, psychology degrees, marketing, telecommunications, and a couple of others I don’t recall. This was the one takeaway for me that day, and it would change my future forever. The next day I received a phone call with my soon to be director telling me, “Welcome to the team.” I would spend the next four years honing my skills as a Business Analyst with the company before moving onto other opportunities in the same field. I am forever grateful for the opportunity and my start in the analytical world.

The advice I left my co-worker was this:

It doesn’t matter what path you take as long as you reach your goal with the exception that the path is a moral and ethical one. Every path is different. Some paths are shorter; some paths are longer. Some take every bit of will and determination to make it through and others much less. I was in the right place at the right time. Fate, it would seem, placed me on this path. If you want to be a BA start by doing. Analytics is everywhere. If you are a tester on an application, you use analytics to gauge how long it will take to create a test plan or execute the test plan as well as determine the effort involved. Building, execution, approvals, implementation, warranty work…all these phases of a project lifecycle involve analytics. What you need to do is show your work. Describe your techniques to your manager and show that you can handle more responsibility. Get noticed for your work. Ask for the tough tasks or obstacles. If you fail at least, you show that you aren’t afraid to try something new and learn from your experiences. If you succeed, well, now you are a proven resource for future projects.

I hope he takes this advice to heart and continues on his path. If I’m lucky, I will have the opportunity to see him succeed.

So, you want to be a BA? Great! Do you an Associate’s Degree in Drama? Wonderful! Can you ask the tough questions? Are you willing to learn and grow techniques in analytics? Can you handle the responsibility of success or failure? Can you deal with the stress of timelines and relationships? Can you work in an ever-changing team environment and learning something new every day? If you can perform these tasks or if you can learn to perform these tasks, welcome to the team!

  • 1
  • 2