Business analysis done in sales saves software projects

The uncertainty of the future caused by the pandemic made business decision-making much more cautious. In 2020, technology budgets for major industries dropped by 2.5%, and they might remain flat throughout 2021.

Just last year, the Project Management Institute estimated an 11-21% IT project failure rate  and a 30-41% scope change rate across industries.

The root of failures in technology development is hard to pin down. Tom Poppendieck, an Enterprise Analyst of 25 years, suspects the lack of efficient and effective communication, saying “The disparate perspective and even vocabularies dominating each discipline make unambiguous communication difficult” (“Impact Mapping: Making a Big Impact with Software Products and Projects”, 2012).

Products that were poorly defined from the onset or suffered during development activities are another cause of product failure, even though the idea behind them might be good.

Some business leaders also reported to us about being gaslighted by their software development partners. It’s smooth sailing before signing the contract, but once the partner cashes out, the relationship isn’t that agreeable anymore. Mikołaj lived through this scenario as a homeowner. Once he paid the last instalment for the property, his agent wasn’t eager to pick up the phone.

What happens during business analysis

You might already know several risk management methods for IT projects.

We’d like to make a case for doing business analysis early —  in the planning or sales phase — which is a practice that The Software House (or TSH) stands by on the grounds of our experience in delivering 200+ projects.

We see each project as a journey we and the client go through together towards shared success.

From the authors’ experience, business analysis can help optimize several factors already during sales to secure the project’s success and the development team’s work comfort. These factors include:

• Understanding the operations and needs of the business without mistakes
• Registering the scope accurately, so that nothing derails the project later
• Verifying the client’s technological capabilities

On top of that, a popular risk-aversion method encourages including the often-overlooked business analysts (BA) and Product Designers (PD) in the development project.

From this article, you’ll learn about the value a business analyst brings to the sales process. While a BA shouldn’t replace the salesperson as the captain, their intuitive fact-checking ensures all parties will reach a consensus before any mess-ups happen.

Scenario 1: investigate before you commit

Once in The Software House’s history, a well-prepared SME client called in, inviting us to develop an HR system for internal and external users. Their company had a clear-cut vision of what the software should do with a stack of documented requirements to back it up. 

While our salesperson mediated the process, we did our due diligence to look for potential business problems hidden in the collected information with the help of our BA. To estimate if the client’s development roadmap is solid, that person:

• Decomposed development tasks to estimate the actual amount of work by rewriting them as smaller steps
• Conducted gap analysis to be sure our team collected all critical requirements
• Researched the client’s competitors to verify if the to-be-build technological solution will be a marketable product

Still, it turned out the client didn’t define some areas we needed to grasp to produce the design. We all needed at least one workshop centered on needs and requirements to prepare an honest plan for our partnership.

There was even more done. So why did our company gain here? Much greater confidence about where to lead both parties. We learned of the business by heart, gaining a deep understanding of the basic and complex processes of the future system with its functional and non-functional requirements. 

Here, the BA’s work took little time thanks to the shared knowledge TSH gained over the years. But that person’s focused input helped us form a realistic project roadmap that potentially saved us from entering a partnership that could end in disappointment.

Too many cooks spoil the broth…

You might wonder if this old saying is true for a sales team with the added business analyst. Does it make sense to expand the team if the process has been working? Yes. And we’re glad you asked.

Sales and business analysis skills and responsibilities can overlap. Professionals in either of the roles will:

• Focus on the client’s business goals
• Establish a trustworthy relationship with a reliable knowledge-flow
  
• Discover the client’s organizational structure
• Extract high and low-level requirements
• Suggest a cost-optimized solution to the client’s problem
• Seek logical answers to the “why?”, “who?”, “what?”, and “when?”

So yes, the similarities are there, but both roles have a different job to do. Pairing a BA as an independent consultant with your salesperson increases the team’s project awareness by a notch. 

Salesperson’s focus

Salespeople lead the client’s relationship onward with a surface-level concern how difficult the development can be. If sales hear from the CTO that something can be done, that’ll be enough reassurance for them. You might say they know how a car drives, but don’t know every nut and bolt of the engine. 

While they know each software project has many dependencies, they put their attention on being a “business guide” for the client.

Business analyst’s focus

BA’s spend their days with developers as reliable advisors with deep insight into cross-project execution. They’re like that assistant to the master repair person at the auto shop. While the salesperson can lead outstanding negotiations, the BA will help them and the client consider technicalities that could blow up the project’s scope if forgotten.

Scenario 2: A fixed scope requires caution

This time, the client came forth with a set budget and deadline for development. After our team got the project documentation, our BA took time to examine if The Software House can deliver under this limited scope. Our concern was about potential changes, roadblocks, and fixes from the client’s side that could delay the last delivery.

Here, the analyst debated the risks with the development team, which allowed us to establish shared expectations with the client where we could have made false promises.

At The Software House, we don’t push through the sales process just to secure the first contract. That’s really short-sighted. 

We’ve mentioned before that we see custom development as a journey two parties go on together. Having an early-stage understanding of the vision, which the BA helps to establish, minimizes risks and often leads to an extension of the partnership into ongoing development support. That, of course, is preferable for the client, because they have a reliable team on demand, and for us, as it’s easier to work with people who know us best.

Scenario 3: What happens after a BA joins in

We were right after closing the sale with a new client. Because of the honest groundwork we did beforehand, we had a comprehensive project analysis, a realistic scope in its first version, authorized product designs, and a backlog for 2-3 sprints. It’s common for software development companies to finalize these a month or two after the deal – we’ve been there.

When we moved into development, work was smooth as sea waves because both sides fully trusted one vision. You see, when the client feels that the sales team went an extra mile to understand the needs and requirements, there’s less decision-hesitation that steals precious time.

Since the client got to know key team members earlier, their PM was much eager to decide, react, and support The Software House. It might not be so obvious, but we saved dozens of hours for Q&As with the client because the business analyst stepped in. That person’s input is much more visible closer to the deadline when nobody stresses out about delivering software people can be proud of.

Start business analysis from the first conversation

The three scenarios you discovered suggest that a project sold doesn’t mean that it was sold in the right way.

To prevent your project from ending in the 11-21% failure group, engage in a deeper analysis done with a BA already during sales. Remember that although development might start when the contract is signed, collecting intelligence starts from the very first client conversation.

At that moment, your salesperson is preoccupied with relationship-building and gathering requirements. Without the BA’s involvement, these might go unchecked until it’s too late to backtrack. What you extract from the client in that conversation can contribute to the project’s glorious success.

BA and the salesperson can work with a pre-made checklist of what’s necessary for your company to deliver without compromise. You want to reach a shared understanding of what’s the vision, the needs and requirements, and technological expectations.

Business analysis in sales – two strategic questions for the go

Let’s remember that business analysis also helps your company find optimal projects to work on. Keep in mind these two revealing questions when you carry on:

• Is the partnership form we have in mind the best choice for us and the client?
• Will our development team have the comfort of work and understanding of our goals?

The last point you should know is that BA’s physical presence for a call or a meeting isn’t always critical. We’ve met several sharp salespeople who could cover 100% of business matters and 60% of technological matters. They might bring you enough to estimate a project with satisfying certainty.

Nevertheless, an additional expert often broadens the perspective on what can be that one person wouldn’t notice. Whatever your sales team setup is, we hope you carry on in business with no roadblocks and sharp turns.