The Value of Defining Business Needs in a Software Project For a software project to run smoothly and lead to a successful product, business needs must be defined early. Alexander Alexandrov BA Lead Articulating business needs is a thorough and extensive process. Similar to meticulously creating architectural designs for skyscrapers, there are multiple steps involved including the identification and understanding of a business’s goals. Defining its strategic direction and capturing any key concerns that are relevant to future challenges, risks, or problems are also critical pieces of the puzzle. For a software project to run smoothly and lead to a successful end product, business needs must be addressed as early as possible. Why is not having a well-defined business need a problem? A software project, or even a single feature, without a clearly specified business need is destined to failure or to a bumpy road full of discrepancies. Many businesses starting a new project, especially those at the enterprise level, either lack a well-defined business need for their project or their needs constantly change throughout the development process. What does that mean for the team on the development side? How is their work affected when they’re building a product without a properly determined business need? Business analysts are missing an essential thing to do their work properly. When the end business need is not clearly defined, requirements often change on a daily basis. Developers, not knowing the business logic and the problem their code is aiming to solve, are not very productive. The code starts to produce bugs or is overall not working towards meeting the end business need. And this makes perfect sense as developers don’t have a vision over the goal of the entire project. QAs become overloaded with logging bugs. When testing features without the business need clearly defined at the beginning, they tend to not know whether the feature is functioning properly or if it is buggy. This may cause conflicts to arise and satisfaction to drop, both on the client side and within the developing team. Designers also see their work stumble. They spend time creating mock-ups and designs that might look great, but probably aren’t achieving the client’s desired result — whatever that may be. When the project’s business need isn’t defined and clarified in the early stages, the product will not bring any value to the user. Even worse, it will bring unwanted value, which may cause an outflow of users and even a total collapse of the product. Case Study To illustrate the arguments above, let’s look at an example of what can happen when business needs aren’t properly defined. As part of a huge form that users should be able to submit, the team had to develop a simple datepicker functionality. The datepicker was supposed to be pretty simple as it is a common feature on any application. Everyone agreed on the feature and how it should work. The business analyst communicated that with the client, created a user story, then the team groomed it and estimated it. The design team created some nice datepickers that were both good-looking and user-friendly. The story ended up in one of the next sprints and got implemented. Everything was perfect. Then the day of the demo came and the team presented the datepicker. The client saw it and the first reaction was: “Looks good, but our users are people in a hurry and a datepicker may not be so useful for them, as they only use the keyboard, not the mouse. The user should be able to just type digits that will be formatted into month, day, and year.” The team agreed that this could be implemented in an upcoming iteration. Reworking the functionality would slow their work down, but they did the whole process again — design, BA, development, QA, demo. At the next demo, however, the client said they wanted the feature to be a combination of manual input and a datepicker, so users can choose which method to use. This double option had actually been discussed earlier on, but at that time the client had disagreed completely. This all shows how a minor “business need” such as a datepicker may cause a lot of misunderstanding and reworking. Eventually, this caused the team: Loss of motivation Frustration Waste of time Unhappy client The whole situation was triggered by poorly- defined business needs. In this case, the client wanted the application to do a number of different things at the same time and their focus tended to shift constantly. Another scenario leading to similar distress is when a project is not directed at any business need whatsoever. Either way, the end product will likely not live up to the users’ expectations once released. To avoid such an outcome, companies should invest in meetings and definition sessions, consult specialists, see how the most successful players in the sector are doing things and learn from them. Most importantly, they should stick to one business need at a time and have it well-defined, so it can serve end clients the best way possible. What is the value of defining the business need? The case study above illustrated the tumults created by non-specified needs, so let’s have a look at how projects actually benefit when being based on articulated business needs. The development team is focused and motivated. When the team has a good vision of the problem the product they are developing is trying to solve, their efforts are more likely to satisfy the business need in the end. Throughout the development process, the team can reference the ultimate goal of the project, so they are focused and feel they are serving a purpose. Hence, their motivation stays high and they are faster and more productive in their work. Tension in the team is reduced. For a project to run smoothly and efficiently, tension within the team must be minimized. Keeping in mind that internal conflicts flourish when business goals are vague and priorities are not set properly (or shift all the time), specifying the business need proves invaluable. A healthy working atmosphere means expectations are more easily met, decisions are painlessly taken, and the overall purpose is not a hazy concept but a destination within reach. The client is satisfied. With a business need well outlined already at the beginning, the project is bound to lead to a consistent, meaningful product that will serve a particular need of the market. In this case, not only users are delighted with the new application but also the company owning the product is thrilled about all future gains related to it. Last but not least, for the company that built the app there is hardly any greater recognition for their work than having a happy client in conclusion that will possibly come back with new projects. Final Thoughts As every new beginning is a land full of expectations and hopes, every new project also has an aura of optimism and anticipation. But the enthusiasm often brings with it a sense of impatience and even urgency — the project has to get going as soon as possible and the end product must be released in no time. This hurry, however understandable from a psychological and economic point of view, must not ignore a key element: defining the business need. Determining this crucial factor will indeed require time and thorough thinking, but this effort will spare the project unnecessary reworking, disputes, confusion and, above all, potential failure. Tags MobileAgile Software ProcessDevelopmentWebSystems ArchitectureCross Platform Share Facebook LinkedIn Twitter Over-Engineering Learn the causes and costs of over-engineering your solution and how to avoid it from occurring in the first place. Download Share Facebook LinkedIn Twitter Sign up for our monthly newsletter. Sign up for our monthly newsletter.