Business Analysis Services for Software Projects

Business analysis is the work of finding out what a piece of software must do before anyone builds it. A business analyst studies how your company really operates, writes down the rules and the exceptions, and turns them into a specification that developers can build from and you can check. It is the least glamorous part of a software project and the one that decides whether it succeeds.

Why software projects go wrong before the first line of code

When a software project fails, the programming is rarely to blame. The usual cause is that the wrong thing was built, and built well. Somebody described what they wanted, somebody else heard something slightly different, and the gap only showed when the finished system met real work.

Business people and programmers speak different languages. An owner says “we need to track jobs.” A developer needs to know what a job is, who creates one, what states it passes through, what happens when a customer changes their mind halfway, and who is allowed to see the margin. A business analyst is the translator who asks those questions before they become expensive.

Skipping this step is like starting a five-story building without a blueprint. By the fifth floor you find the things that should have been done on the first.

Signs you need business analysis first

• You know what hurts, and cannot yet describe the system that would fix it.
• Different managers give different answers about how the process works.
• Key rules live in one person’s head or one person’s spreadsheet.
• You have had estimates for a project that differ wildly from each other.
• A past software project delivered what was asked for and not what was needed.
• You are not sure whether to buy a package or build your own.

What a business analyst does

• Interviews the people who do the work, not only the people who manage it. The exceptions that break software live with the staff.
• Maps the current process, including the spreadsheets, sticky notes and workarounds nobody mentions in a meeting.
• Finds the rules. Which orders need approval, how a price is worked out, what makes a record complete. Many exist only in someone’s head. See only one person understands how it works.
• Separates what you need from what you asked for. The request is often a solution in disguise. The analyst digs back to the problem, because there may be a simpler way to solve it.
• Documents it clearly enough that you can read it and say “yes, that is our business,” and a developer can read it and know what to build.

What you receive

The result of a business analysis is a set of documents you own, whoever builds the software afterwards:

• A process map showing how work flows today and how it will flow in the new system.
• Requirements, written in plain English, listing what the system must do and the rules it must enforce.
• Screen sketches for the main screens, so people can react to something concrete.
• A data outline describing the information to be stored, which feeds the database design.
• A phased plan that puts the most valuable work first.

With that in hand, an estimate means something. Without it, any figure you are given for a project is a guess wearing a suit.

When to bring in a business analyst

The right time is before you commit to a build. Analysis is worth doing when:

• You are replacing spreadsheets or paper with a real system. See outgrown your spreadsheets.
• You are modernizing a legacy application and nobody is sure what it really does.
• You are deciding between buying a package and building. See when off-the-shelf software does not fit.
• A previous project stalled and you need to know why. See rescuing a failed software project.
• Several departments want different things from the same system.

The analysis feeds straight into software architecture and design, where the question changes from what the system must do to how it will do it.

After the software is built

A business analyst’s job does not end at the specification. During development the analyst answers the questions that come up and keeps the project pointed at the original goal. At delivery, the analyst checks that the business is getting the benefit it was promised, and helps with training and job aids so that people use the new system the way it was designed to be used.

How a Keene Systems business analysis works

1. We agree the goal. What should be different for the business when this is finished? Everything else is measured against that.
2. We watch and listen. The analyst talks to the people who do the work and looks at the tools they use now.
3. We write it down. Process maps, requirements and screen sketches, in language your staff can check.
4. We review it with you. You correct what we got wrong, and we refine until it describes your business accurately.
5. We hand you a plan. A specification and a phased plan you can act on, with us or with anyone else.

The next step is a short, no-pressure conversation. Book a call with Lance Keene or use the form on this page.