Software development projects
Common mistakes on the initial state of software development
Nowadays, everybody uses devices and spends a lot of time with technology. We have smartphones, we buy things online, and more and more activities are turning digital.
The result of this switch is that a growing number of companies need software, whether for their in-house use or as a solution to an existing problem on a market that they can monetize. When the product is specific or first of its kind, there is a need to create custom software. To create it, companies are building development teams or heading to software development companies.
The great idea for software is only part of the deal. Equally or even more important is the execution of it. Entrepreneurs tend to make mistakes with both ideas and execution. The essential steps of project development are often missed or delayed. Let’s review the common mistakes entrepreneurs or the ones responsible for software development projects make at the beginning of the project development.
Mistakes on the initial state of a software development project.
As I mentioned earlier, great ideas are not enough to build good software. To be honest, to create any software, but we want to make a good one, right? The first step of the process is to check if your idea is as good as you think.
The lack of proof of concept
Commonly, one with an idea thinks it is the best and only solution to a problem. It is a wrong blind path because there is a big chance that there are already competitors and available tools or solutions for the same problem. That’s why it’s essential to analyze the market. Are there similar products? How do these products approach problems? What can we do differently or better?
Another crucial question at this point is — does the product have any chances for success? Is there a need for it? Ask your potential customers for their feedback. Their opinion is necessary to define the future of your software.
When your idea is proved by potential customers or users, and your approach differs from the competitors, you can move to the next steps.
Moving directly to the development process
Just after proving the idea, businesses tend to start development, which is not the best idea. First, the concepts should be specified and transformed into business requirements. Later on, these business requirements will be the basics for the next steps of the development process. Without prepared requirements or even an explicit vision of the product, it is entirely contra-productive to start development. Such an approach leads to chaos and creates additional costs for the development of unnecessary functionalities. So, how to avoid it? The answer to this question is connected to the next mistake.
Build all the features at once (neglecting MVP)
Every solution or tool can be built in many ways. And the scope of the project can vary as well. It’s a common mistake to try to implement all the desired features from the very beginning. But in most cases, it is not possible, and even if it’s, it is not wise. Why?
First of all, resources are limited. With such an approach, the project won’t be delivered in time and within the budget. Second, it’s beneficial to check market reaction on your software as soon as possible and then, based on feedback, plan to develop it further. The early development stage feedback will improve your product’s quality and save costs on the development of unnecessary features. Before going all-in with development, define which functionalities are crucial, which are important, and which features are on the “nice to have” list. The features that are necessary form an MVP “minimum viable product.” MVP is a product consisting of a minimum set of features, but still valuable for users and able to convince them to use. Sometimes, it’s not an easy task to define MVP; that’s why we will dedicate a separate article to this topic to provide more in-depth advice.
The lack of a responsible person (no Product Owner)
When you plan to transform your idea into a product, there should be someone responsible for this transformation. In Agile-based methodologies, this role in a project is called Product Owner. The best is if this person knows the project, background of it, business needs, knows the business value of certain functionalities to prioritize them. What is also important — he should be decisive — he should be able to answer the development team’s questions and make decisions.
The role of a Product Owner at an early project’s stage
I don’t say that a Product Owner is the only person that should work on functional requirements and preparation of specifications. A Product Owner may require assistance from more technical specialists or business analysts. Technical consultants can advise on some patterns, best practices, and estimate what is doable to make. When the Product Owner has the technical knowledge but has no previous experience in managing the project, it can be helpful to use the help of a Business Analyst. This person will be able to transform business requirements into specifications. It can be a document or even a step further — a general backlog for project scope with a list of functionalities with their descriptions. These functionalities we call Epics. We will write more about them in another article. The Product Owner’s role is not finished at this moment; he is present during the whole development cycle. But his role in the later stages of the project is the topic for the separate article.
When business specifications, requirements, and the backlog are ready, you can involve the technical team. It can be beneficial to involve a technical consultant — for example, a tech leader of a future development team. This person will bring knowledge to analyze specifications from a development perspective, find gaps, ask the right questions, and prepare a more detailed backlog later on. And, of course, he will advise on the choice of technology.
Wrong choice of technology (and why this decision is so important)
Nowadays IT is developing with crazy speed. Everything around us changes fast, and innovations and new technologies appear constantly. To create software, we have to choose the technology that will work for this project the best. Unfortunately, many businesses make the mistake of choosing the wrong technology. Not all projects can (or should) be done in any technology. Some languages suit better for one purpose and some for another. For example, some development platforms can fit better for small projects — because of their entry threshold; others are better for more prominent and long-term projects — because of their maturity, implementations of architecture patterns.
Another important aspect while choosing a technology stack is the availability of people. You need to define how big the community is for a particular technology. This fact will later affect the easiness of maintenance and scalability of the team.
It seems to be a hard decision, so how do we make it right?
There is no simple answer to it. To make such a decision, you need to have experience in the development area. So the best approach will be to ask people with experience for their advice — they will analyze your project, give opportunities, and explain all the whys. Then together with them, you can make the right decision.
No Design
We have prepared specifications, selected the technology — so you assume it’s time to start developing? I think we should stop for a moment. We have business logic and defined functionalities, but that’s not all. You need to convince people to use your software when the market is full of alternatives. You have to create a competitive solution. Even if you build the software for internal use — it should be easy to use and intuitive. Usability is the key to creating successful software or digital product. For this purpose, you need a good UX/UI analysis and design. We’ve decided what our software will do; now we have to work on its appearance and interaction.
Businesses and entrepreneurs often omit the design process. The negligence of design ends up in poor usability of the product. Poor usability causes the product’s failure or creates additional costs for rebuilding the whole software or its parts.
Before your development team starts coding, onboard your design team; their work and alignment with the development team help you avoid many problems and risks of failure. Of course, some software elements might not need UI design, for example, any APIs. But in the majority of cases, UX&UI design is crucial.
The right time to start software development
At this stage, we have specifications, prepared backlog, selected technology, and created designs. So I suppose your question is, “Is there anything else we need to prepare, or can we finally go to the development phase?” That’s a hard question to answer. Software projects vary a lot. Each project requires different approaches; also, prerequisites for each of them are different. In this article, I’ve only gathered general steps of the initial phase of the development process and showed the elements which should never be avoided. These steps are often underestimated, which leads to apparent problems in the later stages of the project. In this article, we discussed the minimum preparation you must make before starting actual development whether you create web applications, mobile apps, or desktop solutions.
Next steps of a software development project
When you reach the point of starting the development, you might think that your role in the project is finished. That the development team can take over the project, and you can just wait for the results. Several years ago, it was a popular approach, but it didn’t lead to positive results in most cases. There are some practices and methodologies which allow minimizing chances of project failure on the development stage. We will dig deeper into this topic in another article, but, spoiler alert, Agile software development is one of them.
