Few people in this world can afford to start a business just for fun - without any consequences or obligations. Of course, ideas are born more or less spontaneously, in more or less chaos, but in most cases, we have a specific goal. From the very beginning of the operation, i.e. at the planning stage of the project, we should take care of appropriate structures and clearly delineate our vision and needs. The journey towards development and creating a project will sooner or later draw other people on board, especially if the business includes software development implemented outside the structures of our organization. Then it is worth presenting our business needs as best as possible. This article will help you better define them, so you can work better with the extended software development team such as bPol.

In the previous article posted on our blog, we wrote about how to find the right software development partner. A well-prepared Request for Proposal (RFP) is of invaluable help and a great tool. Let's assume that you already know with whom you will implement a joint project. It's time for an in-depth analysis of your needs. We have several methods up our sleeve that work well both in large corporations (where they were most often invented) and also in medium and smaller companies and startups that want to use software engineering to develop efficiently. 

Business Model Canvas in digital transformation

The technological boom and the expansion of startup culture made the business plan an integral part of organizations that wanted to be associated with development and innovation. Its form, however, has changed over the last decades. The agile technique helped transform time-consuming analysis into easy-to-write mind maps that can be effortlessly prepared and edited in order not to waste time and present our ideas to business partners and subcontractors in the best possible way. In 2005, Alexander Osterwalder proposed a completely new model for a business plan template that consists of 9 blocks. On its basis, the Business Model Canvas (BMC) was shaped, which for years has proven its worth both for startups and for huge players such as Microsoft, SAP or General Electric. This visual chart consists of elements that describe a company's or product value position, infrastructure, customers, and finances. BMC can be the perfect tool to help the extended software team learn about your project needs. Business Model Canvas consists of the following elements:

Customer Segment - from here we start filling in the template. This is where we list which groups, organizations or people will use the solutions. It is worth distinguishing customer segments if they differ significantly from each other.

Value Proposition - pay attention to what sets you apart from the competition and what benefits the customer will receive.

Channels - here we define how we want to reach the customer and how we can do it to sell our product.

Customer Relationships - this is where we characterize the relationships we build with our clients.

Revenue Streams - this module is devoted to the ways in which a given service or product generates revenue.

Key Resources - indicate the tangible and intangible resources of the company that is necessary for the business to function well.

Key Activities - this is a very important block from the point of view of digital transformation. Identify the most important activities that the company must perform to provide added value, establish a relationship with the customer and generate income.

Key Partners - here, you define external entities without which the business could not function (sellers, suppliers, and subcontractors - including the nearshore team or extended team involved in software development).

Cost Structure - financial possibilities should not be forgotten either. It is worth pointing to all expenses incurred in connection with the functioning of the business model.

Below is a BMC template prepared by strategyzer.com that you can use:


User story in software engineering

Moving from general to specific, it's time to focus on the immediate needs of the recipients of your services. If you want to describe the requirements related to software development, you should definitely get to know the user story method. In the context of business needs, this phrase first appeared in 1998, when Alistair Cockburn (co-author of the Agile Manifesto) visited the Chrysler C3 project in Detroit and said "a user story is a promise for a conversation.” The user story theme has appeared in books by authors such as Kent Beck ("Extreme Programming Explained") and Mike Cohn ("User Stories Applied: For Agile Software Development"). An important milestone was also Jeff Patton's "User Story Mapping: Discover the Whole Story, Build the Right Product" which was released in 2014. The author noted that due to a systematic approach to identifying user stories and structuring them, certain relationships can be seen between them. If you don't have time to explore literature, we rush to explain what it is all about. A user story is an informal, natural language description of one or more features of a software system. There are several formats and templates of user stories. The most common is the “Connextra template”, which looks like this:  

As a <role> I can <capability>, so that <receive benefit>

We start by indicating the type of user that will use the service. It is worth preparing several variants with different entities. After all, each type of user may have a different approach to the subject. In the next step, we enter the action to be performed. The most important, however, is the last element of the user story. Thanks to the answer to the question "what's going to happen?" we learn about the benefits of a given solution. Knowing the needs of users, we can measure the success potential of a given implementation or idea for a new product. The task of the software development team will be to achieve specific results based on the needs of potential customers and this approach works very well in business.

“Connextra template” is not the only solution that can be used in the user stories method. For example, Chris Matts suggests that "hunting the value" is the first step in successfully delivering software. In such circumstances, the template will look like this:

In order to <receive benefit> as a <role>, I can <goal/desire> 

There are still more options. We especially liked the model based on the 5 Ws method:

As <who> <when> <where>, I <want> because <why> 

the 5Ws method is not far from 5 whys, which is another methodology that is worth using in the process of determining your software development needs.

5 Whys and Root Cause Analysis

Young children can annoy parents as they try to deepen their knowledge by continuing the never-ending "why?" sequence. In the case of business, there is nothing to be nervous about. Deepening the problem with questions that start with "why?" it's a simple way to solve it! Kanbanize has prepared a great example of applying the 5 Whys:

1. Why didn’t we send the newsletter on time? Updates were not implemented by the deadline.

2. Why were the updates not implemented on time? Because the developers were still working on the new features.

3. Why were the developers still working on the new features? One of the new developers didn’t know the procedures.

4. Why was the new developer unfamiliar with all procedures? He was not trained properly.

5. Why was he not trained properly? Because the CTO believes that new employees don’t need thorough training and they should learn while working.

We will use this technique not only when solving internal problems or planning the implementation of new solutions in the field of digital transformation. We can use it in communication with our end-users and thus get to know their needs better. Of course, 5 is not an obligatory value. Questions should be deepened until satisfactory results are achieved.

The 5 Whys technique can be part of a more complex process that corporations and startups use - Root Cause Analysis (RCA). As the name suggests, this method allows you to identify the root causes of faults. For minor problems, 5 Whys may be sufficient. However, there are situations when it is worth involving professionals with whom we can discuss our situation. Defect analysis can be based on tests or user reports. Regular activities in this field help to control the quality of services. In agile teams, RCA can take a retrospective form and divide it into multiple sessions that allow you to go deeper into the problem. Root Cause Analysis used in software development helps to make improvements effectively and avoid some issues in the future. Thanks to this method, business can gain in quality by getting closer to the set goals. 

Improving communication processes, identifying needs and optimization are topics that we could talk about for hours. Let us know if you would like to know more methods similar to the ones we have presented in this article. We are happy to share knowledge about solutions such as Event Storming or Kaizen Approach in software development. Let's stay in touch!