Business requirements vs technology capabilities

is it better for a project to be driven by business requirements or technology capabilities?

 

Who’s driving your project? In this question I’m looking to discover if your project requirements are weighted towards the business team or the technology team. Often I come across clients who are unable to describe their low level requirement details. This is generally due to lack of understanding of what the business process is. Also a lack of understanding about all the permutations a particular user journey can have. With this lack of understanding, the direction from the client is generally “What can the technology do?” or “What can you build?”. Which leads to requirements being driven by the technology, which is not necessarily a bad thing. But can cause problems. 

There is a common saying in software development – “Anything can be built, it just depends on how much money you have.”

 

It is essentially a Business Analyst’s (BA) role to help guide the client to define low level requirements, by doing research in both the business and IT space. To do this well, the BA will need some strong IT knowledge, else they will be too heavily guided by the technology team. Who may have their own interests at hand, not in a malicious way, but as I have explained in other articles. The business team is generally concerned solely with the business side, and the development team on the technology side. Rightly so, interests are aligned with each team’s core business area. A good Business Analyst is unbiased towards the technology or the business team. 

 

Here is a little dialog that I always come across even in well established development teams. 

Business Analyst: “How do you want this feature to work, to best support your users?”

Client: “I don’t know, what can the Development Team build?”

Development team: “We can build whatever you like, what does the client want?”

 

This kind of conversation can go round and round in circles. And often does, if there is no one to control the requirements. Email trails can go on forever and achieve nothing. 

How to help client develop low level requirements

The first approach should always be that the business requirements drive the technology design. The only exception to this is if the organisation is a tech company or the main business driver/strategy of the business is technology (mobile application, for example).

1. 1. At the core, the business team/product owner should have a strong understanding of the project’s objectives which should be aligned to the company’s overall strategy.
      
   2. The first step is to define the problem. It’s important to have a problem statement or at minimum a line or two about what the issue is. So it doesn’t get misinterpreted or evolve over time.
   3. A Business Analyst should define at least 3 possible scenarios or proposed solutions, and discuss with the product owner the potential outcomes of those scenarios.
   4. This would be done with consultation with the development team, in order to understand the impact from a business and technology, point of view. This is important for the BA to understand the business process impact and the health of the software that will support the process.
   5. There are a few methods to communicate these low level requirements. 
      • State transition diagram
      • User stories, with a flow diagram 
      • Structured English
      • Simple prose with an infographic
   6. Documentation in big projects is key, the following documents are important to articulate problems and solutions. And ensure people’s interpretation of the solution is the same and doesn’t change throughout the project. 
      • Business Requirements Statement (BRS)
      • Functional Specification

When to pursue business needs over development needs

Business requirements should drive the decisions made by the development team.

1. 1. Customers come first, users are the frontline
      When the problem directly affects the customer and users, the business needs will outweigh the technology needs. This doesn’t mean that the technology team can’t and shouldn’t have a say in the solution. What needs to happen is the BA should consult with both the business and the technology teams, and help design or advocate a solution that is best suited for the situation.
   2. Competitive advantage
      The technology needs to be aligned with the business processes and it is through those processes that a business functions at its most optimal and has a competitive advantage. What shouldn’t happen is that the business process is hampered and cannot be adaptive because the technology is too rigid.
   3. Business process flexibility
      A business and its users need flexibility to handle any internal and external change that might affect a company. Sometimes business processes need to change dramatically and or rapidly. Therefore there needs to be a culture and development process in place that can cater for changes in business needs. Thus, it is important that the development team can handle enhancement requests and there isn’t so much push back from what the technology is capable of doing.This would have been especially true in early 2020 when the COVID-19 pandemic broke out. Companies needed to be extremely adaptive with their business processes. And therefore needed to drive requirements/solutions to maintain competitive advantage and support customers. 

When to pursue technology needs over business needs

There are instances where it is more prudent for the technology team to drive the business needs. 

1. 1. Timeline
      When the delivery timeline is too short, the fastest path to a solution may need to be taken. This might mean changing the business process and not the technology. However, it is likely that the technology needs to guide the path forward. This is generally because of the complicated work and checks that are required to analyse, design, build, test and release a solution.
   2. Technology is life
      If your business is heavily reliant on new technology or your business is a tech company, then decisions will naturally lend themselves to technology over business needs. On the furthest end of the spectrum, technology may break or refine typical industry business processes/best practice. For example, when Apple launched the first smartphone. They created new business processes, where none had existed before.The technology in your company may be so important to delivering services that it must have at least equal weighting in decision making. An example of this might be a company that sells large volume online. This kind of company would be so reliant on so many systems like an ERP, CRM and front-end platform.
   3. Technology limitations
      Technology will always have some kind of limitation. There are times when the development team needs to push back, because a particular enhancement will break something else, or diminish a service from another part of the company. Software developers will also have to guide business decision making so it isn’t harmfully self inflicting. There are times when I have seen business decisions lead to unclean, incomplete or erroneous  data. This in turn creates further problems for the business in their ability to serve customers.

Summary