Skip to main content

The Others on BA Island

I sure enjoy the articles and whitepapers that are available online about business analysts and business analysis, don’t you?

We have our bases covered, don’t we? Articles, whitepapers, seminars, and conferences. Sometimes I can spend a full day reading and thinking about us!

Related Article: An IT BA on a Cross-Functional Technology Team

Clearly, the business analyst has a very complex role to play in both innovation and process improvement. Our business analysis is critical for any company hoping to grow or be successful. Yes, it is easy to think that one good BA and a Word doc is all it takes to make the world go ‘round, but sadly, not true. We know from experience that it takes partnerships to make a new process spin. It takes people who write code, and people who test for quality.

Yes, there are “Others” on BA ISLAND.

Recently, I slipped outside of my BA world to find out what these Others are doing, thinking, and saying about what I view as our common goals. Do they even know that we, the BAs, exist? If so, have they liked having us around, communicating with the outside world for them? Using our mad meeting skills so that we can tell them why they do what they do, and how to know when they’re done? Is it presumptuous of us to think that we can guide them to a successful finish? I had to know!

I started with the ever elusive engineer

The world of the hardcore application engineer can get scary. I remember when I crossed into the engineering world for a while. I can tell you the mind plays tricks on you when in the “dot” or “hashtag” world. It’s a place where one idea, even one thought, can result in pinpoint focus, a furious battle of techniques, and a mad desire to figure it out now! Need help? No! I got it! I’ve never met a lazy engineer, although they can often look that way, slumped back in their chairs, a bedhead over eyes that live in display screens. These creatures-of-the-code amaze me.

I’m going to introduce you to some IT engineers I’ve met over many years and let you know what they are saying about us, the business analyst. “Why?” you ask. Why care about what the engineer thinks about me? Because, my Fan of Business Analysis and Process Improvement, it is this engineer who judges what you bring to their table and who looks to you if there are rewrites or production issues. It is this engineer who is taking you at your word and follows your instructions. It is also this engineer who may often run alone and do their best to figure out why they are doing what they do and really, really, need your help.

Here are some engineers with different programming and corporate backgrounds. Some were old-school professionals, and others were new-world geeks. What I found they all have in common was the understanding that they don’t code in a vacuum. They know that some pieces to their code puzzle must come from elsewhere.

On Business Analysts

When asked if they work with BAs on all of their tasks, the engineers’ answers ranged from “I don’t always work with a BA on my tasks” to “I haven’t worked with a ton of BAs. My team is full of legacy apps, all technical team ownership” to “I always have a BA available on my engineering tasks.” Those who include BAs in their tasks said the BA is underappreciated. “Some people think anyone can do this job, but that is not true.” “I can tell a BA in the room by the questions they ask.” There are BA imposters, though. “Leaders and others are helpful, but their info may be dated. Still, they act like the BA.”

“I love BAs!” (This is how I heard it, folks).

Engineers noticed that BAs are different from each other. I heard it is difficult to bounce around between BAs. BAs have different approaches, and the engineer likes knowing what to expect. BAs who only know their own system are a challenge as we are all connected these days. All BAs should care about the code, but not necessarily understand the code. What is a real plus is that the BA knows how to test with others – the business, other BAs, engineers. BAs are great at communicating, and this is the number one challenge for the engineers. I heard it is a real plus to work with a BA.

What the Engineer Needs

What can the BA do for me? Well…

(I admit I was pleasantly surprised to hear most of the engineers had already given this some thought. I told you they were smart.)

The BA can see what’s on the horizon, reach out and meet with system peers, run interference with teams, be the communicator, and do some BA testing. The BA should ask me (the engineer) questions, work with me, work with the business, and clarify everything else.
Gotcha! We can do that.

The BA must understand that I need to be kept in the loop. If you give me clear specs, provide clarity and scope, I am good. In a nutshell, CLARITY is crucial – in specs, scope, and any communications. (This is why the engineers like the BA to go to the meetings.) With complete clarity, the BA and the engineer can work together on the technical solution. One engineer without a BA for his team said if he had a BA just to go to meetings and provide his team with clarity, he would be fine.

The requirements doc was brought up in every conversation between an engineer and me. One engineer said he can guess what is needed, but would rather code. (No guessing, please.) Another engineer made the point that engineers often struggle without requirements. There will always be questions, even if just for acceptance criteria. While the “why” certainly matters, it’s nice to know my code is helping the business move forward, but the “what” is critical to me. What do you expect me to make happen? Requirements make for success. Who could ever have a problem if we are documenting what needs to be changed or built? (Again, clarity.)

Another common thread among Engineers was the need for communication assistance. I heard over and over that the BA should see what’s on the horizon, or the BA needs to reach out and meet with system peers, or run interference with teams and then be the communicator. I heard “the engineer is so solution driven, they are not good communicators.” Also, engineers often take things literally and communicate literally. This can cause confusion regarding expectations. The engineer probably thinks they are communicating well, but the BA excels at communication with the business. BAs should know the engineer is often too technical and focused to notice the details hidden in discussions.

My takeaway: Less than full requirements that result in changes is not a good thing. Period. Give the engineer the necessary requirements, failure cases, known holes; do full regression testing and you have one happy engineer.

What about rewrites?

One engineer deemed rewrites the worst mistake an engineer can experience.

The majority of engineers I spoke with said that rewrites would not be needed if a BA was on the task to tie the threads together. The BA simplifies the process before the coding begins by providing clear requirements and communicating with everyone involved. I liked hearing the BA could help here, and felt the pain the engineers went through when they did all that work, only to find out they were on the wrong track. Unfortunately, just being wrong may often be determined after the automated process is in production.

I heard, “The worst time was working without a BA and just not getting the big picture.” It led to a rewrite, causing delays and frustration. Business use cases would help us understand how the code will be used. I even heard that a BA could save a task by their requirements, running the requirements by the engineer before publishing them, and by collaborating with the engineer on the documentation.

My thought here is “Why haven’t the engineers said something to us?” Is it because using a BA on a task has never been an option for their department or team? I remember being the first BA in a systems and programming environment. After a short time, engineers were lining up to ask me to talk to the requestors for them to clarify some specs. Engineers visiting the other side of the island is a good idea!

Has your code ever been part of a production issue?

With no one really answering my question, the common response was, “In today’s world, everything talks to everything. Get the wrong people in the room or work with outdated documentation or no documentation and production issues happen. Miscommunicating or not knowing all the pieces to test equals failure.”

Lack of experience was mentioned by a few as a possible root cause. Then a comment was made saying someone tying the threads and communicating effectively would cut down on the unexpected happening in production and mitigate this lack of experience. One engineer’s comment about going to production and having a problem was that a BA would understand the current state, and know when the task is done and ready for production.

Here are the common threads about production challenges that I heard: business-use knowledge and communication. I say no one manages these threads like a business analyst.

After the Interviews

The engineers spoke with me about where they see room for improvement in their engineering world. While giving and receiving productive feedback, I heard a lot about a place for the business analyst. The BA never came off as the savior for implementation slips or test omissions. The engineers I spoke to seemed to appreciate the special skills associated with the business analyst role.

One thing new to me and I heard it many times during the interviews – It seems the engineer learns a lot by failing. While I accept this is a component on the engineer’s path to success, failing over and over for the same reason is not. Add to this, the engineer who is too busy forgetting requirements and things start going downhill fast.

What did not surprise me was hearing that engineers who started including a BA on their team projects said they can’t go back now. I was told the full impact of a BA communicating and documenting has been remarkable. I heard that BAs need to keep doing a good job. That was nice. Clearly, there is value added by operating as a cross-functional team, rather than simply an engineering team. One engineer just asked his leader for another BA for his team before he and I sat down to talk.

I feel a great responsibility after all of these conversations, and I hope you do as well, so I can’t help but ask:

• Why is an engineer dealing with a different quality of BAs?
• Do we all have standards in place for our BA skill level?
• Are we seriously working on our communication skills with not only the business client but the technical teams around us?
• Are we working in a silo, or are we gaining knowledge about the systems that our clients and teams are talking to?
• Finally, why isn’t the business analyst a role on every engineering team? Why would we not include this valuable skill?

Now, I gotta go. I think I spotted some QAs on the island!