Here are a couple important things a BA does on a project:
- BAs break down the work in small chunks. This makes work easier to understand and confirm. It also makes developing and testing easier.
- BAs document the scope and keep the project on track.
This is difficult stuff. Take a look at results from the Standish Group’s Chaos Report. I’ve put the success rates they measured for software projects into a graph below. We deliver projects on time, on budget, and as expected we only meet those goals about 1/3 of the time. Our success rate is terrible!
Compared to 20 years ago we have made huge strides. Project teams and tools are improving. Failures are trending lower. The project success rate has doubled over in 2 decades! Despite this headway, more than half of all software projects are failing or challenged. Why are there so many struggles? According to a recent Chaos Report, here are the related reasons for our problems. (Hint: You, my fellow BA, are part of the solution)
Failed Project Factors:
- Incomplete Requirements – 13.1%
- Lack of User Involvement – 12.4%
- Lack of Resources – 10.6%
- Unrealistic Expectations – 9.9%
Challenged Project Factors:
- Lack of User Input – 12.8%
- Incomplete Requirements & Specifications – 12.3%
- Changing Requirements & Specifications – 11.8%
Do you see what I did there? I bolded some of the key reasons for breakdowns. They are the exact areas where a good business analyst is making an impact. For years I listed all the problems and said, “Look—this is why we need BAs. Analysts help solve all these problems! Our specialty is requirements, specifications, user input & involvement.”
I would draw on a whiteboard or give a presentation when I had more time. (See the graphic for a handy example!) I explained the result of few documented requirements was wasted work and missed opportunities. I said how we helped the business explain their needs today. I painted a picture of our goal, requirements maturity.
I would talk about the process of analysis. I spoke about understanding the big picture and little, tiny details. I ranted about tools, the details, and the conceptual steps in between them.
I could pontificate for hours about what we needed to do and how projects would benefit. If all projects had a BA, then we would answer the challenges of the Chaos Report with better documentation.
Sometimes I would add more items to the list above while sitting around with trusted colleagues. “Why else do we need business analysts?”
- When a project manager is overwhelmed, then BAs are great providing support to the project team and sponsors.
- When communication breaks down—and it does all the time(!), then BAs fill in the gaps.
- When there is confusion about the scope, requirements, or testing, then BAs are ready with an explanation and helpful hand.
These three items are samples of the other services BA provide project teams. BAs are grease in the gears of the project, allowing it to move forward when it might stick or stall. Many people think project managers handle these responsibilities even when they are overloaded with budgets, schedules, and reports.
Ensuring everyone is working well together and has the same understanding is a great function to have on the team. These things are not a given or automatic response from putting individuals onto a project. These things are . . . squishy.
I know soft skills are the hard skills. I think good managers realize this, also. It is difficult for a Business Analyst to say “I keep things on track.” First, no one believes you. Second, this is not in your job description. Third, this stuff happens behind the scenes and under the radar; not everyone sees it. Spending time making sure teammates get along can lead to people wondering where you add value.
Unfortunately, I was answering the wrong question. Sure, the software industry needs better analysis. Yes, 50% of software built is rarely or never used(!). Yes, we had huge gaps between the original goals and delivered software.
So what? Who cares? While interesting to researchers and academics, the topic isn’t about the industry. It isn’t even about your company. It’s about you, the Business Analyst.
Which leads to the central question needing an answer. What do people want to know when they ask, “Why do we need Business Analysts?”
They are politely asking, “Have you been a key reason why this project succeed, or didn’t? Where did you add significant, game-changing value?” Or maybe, “What have you done to justify your salary?”
On the bright side, this set of questions means people expect something from you. They think you can make a difference. This is great news. You have a chance to shine, to excel! When you get this question, share what you have done and how made the project a success. Let them know about your contribution and how it made a difference.
On the other hand, if your team, or boss, or executive is asking this question, then you might be too late. It means people may be questioning what you do and if you can make a difference.
Through out the coming year, we will be exploring what it means to add value as a BA, from simple techniques for capturing elicited requirements to the squishier skills that make a difference. So stay tuned and come back.
In the interim, please do me a favor. Do it before you are again asked, “Why do we need Business Analysts?” Evaluate how you are making an impact. Come up with the answer that will let people know you understand their real concern and how projects are better with you involved. And while you’re at it, tell them what you need to make an even bigger impact?
* I see this frequently in environments with a traditional or waterfall SDLC. I do not see this in companies using Agile methodologies. We will talk about his in the coming year, also.