So, I almost messed up a project for my favorite client: my wife.

She’s a psychologist and runs her own practice. Recently, she told me her team needed a better way to handle bookings. Since I’ve spent some experience in web development and I figured, “Easy. I’ll just whip something up this weekend.”

I started coding immediately. I was picking out frameworks, setting up the database, and designing a slick interface. But about halfway through, I hit a wall. I realized I was building a system that I thought was cool, but I had no idea how her team actually worked.

Did they need to sync with Google Calendar? Was the bottleneck the initial intake (customer interface for booking an appointment) or the follow-up? Where would the clients even find this link?

I had jumped straight into the “how” without understanding the “what” or the “why.” A rookie mistake, and it reminded me of a Business Analysis course I took a while back. I had to stop coding and go back to the books.

Here is a look at what I relearned about Business Analysis—whether you’re just starting out or you’ve been in the IT trenches for a decade.

What is Business Analysis, really?

At its core, Business Analysis (BA) isn’t just about software. It’s a research discipline. You’re trying to find business needs and figure out solutions to problems.

Sometimes the solution is a new app. Other times, it’s just changing a manual process or updating a company policy. As a BA, your job is to be the bridge between the stakeholders (like my wife and her team) and the technical solution.

The Process I Should Have Followed

In the course I followed, the process is broken down into clear steps. If I had stuck to these, I wouldn’t have wasted a Saturday coding the wrong features.

Getty Images

1. Initiation and Planning: This is where you define the scope. You identify who cares about the project (stakeholders) and what problem you’re actually solving.
2. Requirements Elicitation: This is a fancy way of saying “talk to people.” You ask questions to find out what they need. I should have asked the other psychologists on her team what their biggest headache was. Maybe, even try to book an appointment myself.
3. Analysis and Specification: Here, you take those notes and turn them into clear requirements. You look for gaps.
4. Solution Design: Only now do you start thinking about the software or the “how.”
5. Implementation and Evaluation: You build it, but then you also check to see if it actually solved the original problem.

The Skills You Actually Need

If you’re moving from a pure tech role into leadership or BA work, you’ll find that your technical skills are only half the battle.

• Analytical Thinking: You need to be able to look at a mess of data or a confusing workflow and find the pattern. It’s like solving a puzzle.
• Interpersonal Skills: You have to talk to people who might not be “tech-savvy.” You need to negotiate and build trust. If people don’t tell you the truth about their workflow, your solution will fail.
• Technological Literacy: Knowing what tools are out there (like SQL, Power BI, or even just advanced Excel) helps you know what’s possible.

Why Experienced Pros Still Trip Up

Here’s the thing: when you’ve been in IT for a long time, you get confident. You see a problem and your brain immediately goes to the architecture. You want to “optimize the workflow” before you even know if the workflow is necessary.

We get “solution-focused” too fast.

Business Analysis forces you to slow down. It makes you use tools like a SWOT Analysis (Strengths, Weaknesses, Opportunities, Threats) to see the bigger picture.

Shutterstock

Final Thoughts

I had to apologize to my wife, close my IDE, and sit down with her for a “requirement gathering session.” We spent an hour talking about how her patients interact with her site. Turns out, they didn’t need a complex dashboard; they just needed a simple, three-click way to see availability.

Whether you’re looking to start a business, solve a problem or just want to be a better lead dev, don’t sleep on the BA basics. It’s the difference between building something “cool” and building something that actually works.

If you’re looking to dive deeper, I highly recommend checking out the BABOK Guide (Business Analysis Body of Knowledge). It’s industry standard and a great way to brush up on the formal side of things.

So, next time you’re tempted to start a project by writing code—don’t. Grab a notebook first.