How to establish software development processes to meet business requirements

Why is it so important to align both technical and business requirements?

Software development requires much creativity, attention to detail, and hard work, but if it does not lead to producing something the market needs, the entire work is in vain. This is why, first, it is essential to define business requirements and employ processes that will strive to fulfil them.

Keep in mind that fixing an error during the requirements phase is less expensive than fixing the same error during the design or coding phases. The cost of fixing a requirement-related error can increase substantially as the development process progresses.

The numbers speak for themselves: up to 60-80% of software defects originate in the requirements phase, according to industry studies.  

In this blog post, we will explore the key steps to establish software development processes that align with business requirements, all based on our own experiences.  

Let’s divide this endeavour into 3 stages: project initiation, planning, and realization.  

‍

‍

STAGE 1: PROJECT INITIATION

‍

In this stage, there is a checklist of processes that need to be implemented. The purpose of a checklist is to understand why a project is being initiated.  

Depending on the type of work (updating a legacy system, making an extension feature, or creating an entirely new software solution) a continuation of the specific software process follows.  

Based on the initialization checklist, we can understand what is to be done, how we are going to solve the problem, find the right solution, and decide on who is going to work on the project.  

However, before diving into the intricacies of software development processes, it is crucial to have a comprehensive understanding of the business requirements.  

A clear understanding of business requirements forms the foundation upon which successful software development processes are built.

Here’s an example of the most common business requirements:

• Fast time to market
• MVP based product
• Stable product  
• Flexible product – client centric (open for customization)

The questions of the initiation checklist are often posed according to the type of service we offer. What does this mean in practice?

Often, our clients are not software development companies, but they come to us with idea of what needs to be developed. In this case, they ask us for a team as a service, and our job is to deliver this solution.  

If they are not software companies and have a problem that they do not know how to solve, or what needs to be done to find a solution, we create custom solutions for them.  

In these instances, we must know when they expect the project to be finished, we must understand the problem they are trying to solve, and how they got the idea for the project.  

If our clients already have a team in place and they just need some help, then they turn to us for a team extension. In such projects, we are mainly interested in the organization of work. So, the questions are directed to find out relevant information – it is important for us that our clients provide a non-chaotic, well-organized environment where our engineers can perform well and enhance their skills. If we observe that our clients do not initially offer such conditions, but are open to learning and are adaptable, we can provide them with organizational and management support.

However, if they are both disorganized and unwilling to make changes, this type of project is too much of a risk for us, and we do not stand to benefit much from it.  

So, to sum up, everything that is in the initiation checklist should lead us to the relevant and complete information and help us discover if we have competencies for the project or have enough potential to develop those competencies.  

The entire initiation stage revolves around the initiation checklist. The goal is to fill it with as much information as possible.  

Usually, we first send the checklist empty for the client to fill out. Of course, it must be adapted based on the type of project and the type of our service. What happens next can be divided into two scenarios. In the first scenario, the clients fill it out and then we discuss it in a meeting. However, the second scenario where we fill the checklist out together with the clients, is the most common.  

It is important to mention that there is a whole set of technical questions and ways of working.  

Sometimes, the risks are also openly discussed.  

The next step is to create a project offer plan based on the initiation checklist. This plan is internal, and its purpose is to get your stakeholders on board. The premise is that you have found out everything about the project, and the unknown is classified as risks or opportunities.  

The project offer plan should suggest a team and anticipate the amount of work. From this information, the prices are formed.  

There are two options when it comes to charging methods:  

TIME AND MATERIAL

In this case, clients are charged according to how much time and material we have spent. For example, if we know the project will last for a year, we can make an offer where we can predict an average amount of money our clients will spend based on the average amount of our working hours each month. This way we provide a predictable cost throughout the year on top of flexibility that comes with Time & Material model.  

FIXED PRICE

As the name suggests, prices are fixed, and the clients know the exact amount of money they will pay for the entire project. This option is not as agile and carries a lot of risk.  

When we are talking about milestones, they will sometimes be defined after the initiation phase once the stakeholders decide when they need to see the results.  

To sum up, here’s a list of processes to establish in the initiation stage:

1. Identify risks
2. Define the scope
3. Define milestones
4. Implement a technique of estimating
5. Define requirements for team structure (competence and capacity)
6. Plan the budget
7. Define QA requirements  
8. Implement the right Way of Work

‍

STAGE 2: PLANNING  

‍

This stage depends on whether we plan on the project’s flow, or we jump in on the planning process. If we create the full solution, then we need to plan the following:

• All the tasks that make up the project scope
• The amount of work that needs to be done
• That the job is clearly defined
• What MVP comprises
• Roadmap

Project scope must ensure that each project requirement is covered. All in all, planning is the effort to put the entire project scope in a timeline. If we have calculated everything well, then we can include risks in the timeline. This means that we can include additional tasks that could appear if something goes wrong, or there is a need to modify parts of the project, etc.  

If all of that is complete, we can move on to the next stage – implementation.  

‍

‍

STAGE 3: IMPLEMENTATION

‍

Once the project implementation starts, the arranged Way of Work should be followed.  

This includes having reviews of the work done periodically – what was done well, what wasn’t, what should be started as soon as possible, etc.  

However, at the beginning, we must do the onboarding for the team that will be working on the project. Even if we are just providing a few people to complete the existing team on the project, we must make sure that our people will do the job well, that they will be efficient, and that their communication with the rest of the team will be transparent.  

If there are some problems, our Key Account Managers do their best to solve them. So, every two weeks there are meetings between our KAM and the clients where we discuss the satisfaction with our cooperation and the status of our team within the project.  

If we are responsible for providing the entire software development team, then we make sure that the WoW is followed. For this reason, we have created the Efficient Team Culture which ensures that we stay on track. Read more about it here.  

In this case, the reports are sent at least once a month in a form of a timesheet (what our team has done so far and how the time was spent), which a standard document that is provided along with the invoice.  

The steering committee happens either once a month or every quarter. These reports include planned and incurred costs, work, and risk analysis. This report aims to be fully transparent and to show how the plan is carried out and how it reflects the expenses.  Also, the risk analysis clearly states if any challenges happened and how they were analysed and solved before the reporting. Steering committee meetings are the perfect place to show all the project stakeholders how the work executed brings the project ever closer to meeting the business requirements that were identified in project initiation.

‍