When it comes to 100% bespoke software development, we cannot overlook the biggest taboo in this market: unmet schedules and deadlines, dashed expectations, and the end of the partnership between the supplier and the client.

Considering these points, in this article, we will share our perspective as a project development company and present the pillars that hinder the success of outlined expectations.

Throughout the content, we will address the following points:

• PILLAR 1: Software maturity
• PILLAR 2: Process
  • Waterfall for closed scope
  • Team allocation and the use of Kanban for paced deliveries
  • Agile methodology in team allocation with a macro goal

• PILLAR 3: Multidisciplinary team
• PILLAR 4: Expectations alignment
• Stay alert to certain situations

PILLAR 1: Software Maturity

Throughout the year, Ubistart engages in conversations with an average of 600 companies to understand their challenges, opportunities, and projects. Consequently, we have identified that the main pillar for the failure of a project is the potential client lacking software development maturity.

This is perfectly understandable for us, as we cannot expect directors, administrators, entrepreneurs, and department heads to be well-versed in something as complex as software project development.

However, alongside this understanding, our greatest challenge is to convey to companies that, to provide a software quote, it is not sufficient to have 2, 3, or 4 interactions in scheduled meetings. For the information to be as precise as possible, we need to delve into hours of planning, layout construction, and understanding integrations with external tools.

Even so, in our experience, when we explain this to companies, a significant portion of them expects a quick quote containing all possible scenarios of the scope, including those that have not been mapped yet.

This is also reflected in companies developing internal products, where they anticipate a 4 to 6-month plan, but in practice, the timeline extends because not all possible scenarios have been mapped.

In this regard, the question to be asked is: why were they not mapped? Well, largely for two reasons:

• Certain functionalities become clearer during the development process, consequently presenting a higher degree of complexity.
• Depending on the project and its target audience, the scope becomes “alive” and changes based on user tests in the initial deliveries.

In some projects, we spend 3 months planning so that we can provide a firmer view of a closed scope, including a schedule and budget. It’s quite interesting because when the development stage begins, the client’s first request is often a change in scope.

Therefore, we should not be frustrated by this because we already understand that the software development culture is not sufficient to clarify this scenario from the client’s perspective. It’s part of the process.

PILLAR 2: Process

There are several ways to develop a bespoke project. Some are more traditional, such as the waterfall for closed scope or small and quick deliveries using Kanban. Others are more recent, such as the Agile methodology, which employs SCRUM.

Here, we will focus on each of them, providing our perspective according to the company’s current phase.

Waterfall for closed scope

The waterfall model can be considered the most classic and generally works well for most corporations that have a history of software procurement. In this case, the software factory seeks to understand the entire project to provide a more accurate view of the schedule and budget.

In this type of model, there is a high risk of delays because the larger the project scope, the more uncertainties there will be along the way. Due to this, when working with a closed scope here at Ubistart, we establish budget limits and a strict process for planning requirements. All this is done to avoid disappointing our clients, ensuring they return for future collaborations.

The waterfall model is widely used in the automotive industry since a partial delivery of a car to the market is not feasible. However, software companies are increasingly realizing that tying complex scopes into contracts is detrimental to both parties.

In situations like this, both the contracting company loses the opportunity to monitor the project’s evolution with improvements, and the contracted company is obligated to be precise and inflexible regarding changes.

Team allocation and the use of kanban for paced deliveries

This working approach is widely used in faster development processes or when the software factory does not necessarily want to strictly adhere to the Agile methodology.

For companies that require more agility in project development and use task lists to complete them within a shorter timeframe, Kanban is the most suitable option.

However, when dealing with a more advanced development process due to the complexity of the demand, Kanban may prove to be too simplistic. An example of this is the development of applications and platforms that involve 4 to 6 months of development.

Based on this, we can conclude that Kanban is more suitable for support, specific improvements, or fine-tuning. For software development with a multidisciplinary team, it may not be the best choice.

Agile methodology in team allocation with a macro objective

Now let’s talk about the most famous and desired methodologies. However, embracing this methodology with open arms is not very common in a more traditional software culture.

If we stop to think, which company or director is willing to sign a blank check for their development team or software supplier? Or not have concrete deadlines for when their project will be ready?

Well, certainly, this is a delicate situation that requires transparent conversations with the client, along with a careful analysis of all scenarios by both parties.

The Agile methodology, by its nature, works with a goal to be achieved over a longer period, ranging from 4 to 12 months, making deliveries every two weeks, known as sprints.

In addition, there is also a highly skilled team, including project managers, requirements analysts, UX/UI designers, testers, developers, scrum masters, and product owners. Even with this powerhouse team, if directed towards a clear objective, they can give their best but may not always meet the company’s goal.

Here at Ubistat, the Agile methodology has been growing significantly as we demonstrate to our clients that it can be powerful for adjusting priorities, testing before the full solution, and client involvement. However, all of this is certainly contingent on a clear objective.

Nevertheless, a company willing to use the Agile methodology must understand that there is no scope set in stone, unlike the closed scope where extensive planning is done in advance.

Considering all of this, it’s not surprising that, to start the development stage with a closed scope here at Ubistart, it may take 3 to 5 months, while the Agile methodology can begin in just 1 month.

PILLAR 3: Multidisciplinary team

When we are cultivating a client’s development culture, it is common to hear the following question:

“So, can’t we just hire the developer instead of this whole team?”

This question arises frequently, and we understand it because the client is not obligated to understand the intricacies of hiring for software. However, as a software consultancy, we have the responsibility to guide them on the best path.

The question above is common because, at first glance, it may seem like “too many chiefs, not enough Indians,” as the popular saying goes. Instead of working with just a developer, we explain the importance of a complementary team, as outlined below:

• Business Analyst: Maps out the rules and specializes in speaking the language of business combined with technology.
• Tech Leader: A senior development professional who oversees both quality and addresses developers’ queries.
• UX/UI Designer: Specializes in observing usage behaviors, proposing the right usability for the application, and creating screens that can be approved before development begins.
• Test Analyst: Tasked with finding errors in the platform, a crucial role since other professionals may be “accustomed” to using the application, hindering their ability to identify certain issues. The test analyst introduces usage processes to stress-test the platform and prevent users from encountering these problems.
• Project Manager (Scrum Master): Responsible for the smooth progress of the project, addresses impediments for the team, and fosters a good relationship with the client’s Product Owner (PO).
• Developers: Can be specialized in visual web elements, business rules, applications, and even infrastructure.

In essence, a multidisciplinary team brings quality and seriousness to project development and delivery. When assigning a single development professional to manage strategic projects for the company, we are placing the entire burden of management and other responsibilities on them. In our view, everything has its moment:

– Specific and one-time demands: A development professional can indeed help.

– Complex and long-term demands: A multidisciplinary team is essential for the project’s success.

PILLAR 4: Expectations alignment

There is another request that occurs quite frequently:

“Team, we need this project delivered in 4 months, double the development team, and we’re good to go!”

To help you understand, let’s use an analogy that illustrates this scenario well:

Take a chicken that should be roasted for 3 hours at 150ºC and put it to roast for 1 hour at 300ºC. What will happen? Will increasing the power make the chicken delicious inside and out? We know it won’t! In the end, the chicken will still be raw inside and charred on the outside.

In this sense, we can identify that certain things cannot be solved simply by increasing their capacity to deliver faster. And software is one of them.

In some projects, adding an extra developer actually extends the timeline instead of reducing it. This is because, in the end, one professional has to transfer knowledge to another, and there is still a learning curve.

Therefore, caution is needed when considering the possibility of increasing the number of professionals as a strategy to speed up the process. Every project requires a specific maturity period.

Thus, we can see that this pillar is closely connected to software maturity. When entering this development journey, it may seem that things are simpler and faster than they really are.

Therefore, here at Ubistart, we always advise clients on setting deadlines before having a clear understanding of the scope. For example, 2 months is a very short timeframe to start complex platforms from scratch.

Moreover, one must be mindful of very affordable prices compared to what is charged by large companies. In this market, when a company charges more, it’s not because they are overpricing, but because during their journey, they have understood how much time is needed to make the project viable.

Based on this understanding, we can define three desires that always collide:

• I want to pay less.
• I want to receive quickly.
• I want quality.

Usually, if the company chooses the first, quality will certainly be affected. If they choose the second, the likelihood of not receiving something within the deadline is high because, as we mentioned, there is a minimum construction time. And finally, quality is what we always recommend because, shortly down the road, the solution may need to be continued and scalable.

Be Alert to some situations

Finally, it’s essential to be attentive to some warnings that we always share with companies concerned about meeting deadlines and expected investments. Check them out below:

• If it’s your first venture into on-demand software procurement, examine the company’s portfolio, and request a conversation.
• Be cautious of firm deadline promises when the company has had little time to understand the project. Here at Ubistart, we sometimes use 100 hours to comprehend a project and provide a firm deadline and budget. Meetings lasting 2 to 10 hours, in total, are not sufficient for a complete project costing more than 200 thousand.
• Want security? The option is a closed scope (waterfall). If you want flexibility, the path is Agile methodology. Still, don’t attempt to secure deadlines and values while expecting flexibility in changes during the process. Agile methodology is ideal for innovation, projects that change during construction. Closed scope is for companies certain about what they want to build and know they won’t change their minds during the process.
• A developer is not a hero who will solve all your problems. It’s essential to understand if you want to “fix the kitchen floor” or “build a house from scratch.” If building a house from scratch, you need more specialists.
• If you want a quick budget for comparisons between companies, you might end up frustrated because you’ll receive highly varied estimates, and some companies may communicate that they don’t work that way. Complex software projects are more about a trusting relationship between companies than comparing the cheapest or fastest.
• The well-done, cheap, and quick end result is for a finished product. Usually, software projects take time and involve a significant investment, so they need to be approached with caution, especially when choosing a reliable partner.

Of course, you may have some questions after reading this article. In that case, you can contact us and clarify anything you find necessary. Just click here, and we’ll be happy to understand your challenge and support you in whatever is needed.