In this article, I would like to discuss the most common mistakes investors make when working with a company from IT. The title is intentionally strong to make clear that the initial excitement, enthusiasm and energy in the implementation of the IT project (although probably not only) is followed by a whole series of problems (I will call them sins in the sense of the Christian tradition). All this to make you aware of what not to do when you outsource the work to a IT company.
It is a long way from an idea to creating a fully functional software product. Therefore, I would like to link the discussion of the most common problems with a brief description of the software development process. The idea of the software development life cycle is to reduce the cost of software development while improving quality and reducing production time. It is a continuous process. It starts the moment the project is launched and continues until the last days, including the development process as well as improvements and maintenance. Furthermore, it consists of several phases: Requirements elicitation, design, build, test and deployment.
Requirements identification, we answer the questions "What do we need?"
The point is to determine the requirements and discuss the needs. During this process, you, the customer, are in the spotlight. It is your time to consult all the necessary professionals in your company to develop a coherent vision of your future product.
The most common investor's sin in identifying requirements - IMMODERATION
Investors very often present their ideas in a vague and incomprehensible way. They use industry-specific language without specifying the details because, after all, they are "obvious". This is the least of the problems because in meetings related to requirements gathering, the company IT is represented by a business analyst or project manager, and the more experience they have, the easier it is to develop a position. However, in these meetings, there is usually an exaggeration in the specification of requirements. And if the project is supported by an EU grant, the list of requirements becomes even longer, like a five-year-old's letter to Santa Claus. Unfortunately, in numerous instances, without any legitimate business need.
The solution to the problem of immoderation:
It is important to focus on the needs of potential users and identify key requirements and business expectations. I will emphasize the word key here. My advice is to conduct extensive customer research and analysis, and then use the information gained to create a list of key desired features.
Design, or answering the question, "How do we get what we need?"
This phase is about designing the entire system and its components. And it's not just about designing the look and feel of the application. This part helps determine the hardware and system requirements, as well as define the overall architecture of the system and create a written Requirements Register (Product Backlog) that serves as a source of insight and decision-making for the customer.
The most common sin of the investor is in the design phase - ENVY
Investors very often want a product like... the competition. Or no, sorry. Better than what the competition makes. Meanwhile, the entrepreneur should know exactly why his company will grow with the investment, so that the company IT him ONLY designs the functionalities with which this company will grow this business, and then improve them, if necessary, according to his vision.
The solution to the envy problem:
No amount of design work can anticipate all the complexities involved in bringing a product to market. Especially if it is an innovative product or a startup company developing the solution of the future. Therefore, the basic principle is to have a financial buffer of even 20-30% because changes and problems in the implementation of IT solutions always occur, unfortunately they show up only in the subtle interactions between the product and customers.
Build, or "Let's develop what we need."
In a few words, it's about delivering a product (in pieces) based on the requirements and design. Using the Product Backlog, developers code the appropriate modules. Coding tasks are divided among team members based on their area of expertise. The end result of this phase is a working software product and a source code document.
The most common investor sin in the build phase - pride, or I can do everything
When implementing software, there is a temptation to manage it yourself or thanks to a trusted employee. Simultaneously, it is a reasonable decision only, if your representative :
- has knowledge about the software development process
- has process ideas related to the industry in which he/she works
and
- can clearly, concretely, and simply articulate his or her thoughts
Why? Because requirements for a programmer are like the Constitution. There is no room for guesswork and interpretation here. If you write that "as a store employee, I would like the orders from the store to automatically go to the accounting system such as ERP to improve the work of the warehouse". Then you will get an export of orders from your store to ERP. Only orders because you do not specify that you want to export, for example, customer data to the customer register in ERP or export services or products from these orders to the product register in ERP. These are completely separate requirements and no, they are not obvious.
The solution to the hubris problem:
Outsourcing software development to another company can be stressful. I completely understand that. It's your beloved idea and business, so you want to keep control of it. But you cannot let it all go to waste. Especially because working with developers is ... special. Also, do not get involved in management because you think you can "save money" when you have no experience or talent in it. However, what you absolutely must do always is have a representative for the development team. A representative whose first and most important task is to answer the team's questions, choose between the proposed solutions during implementation, confirm and specify the requirements, translate the production or sales process in your company, etc. etc. This is the only way to save real money. A quick response to the doubts of the developer during the creation of the functionality allows to avoid corrections during the implementation. Corrections that can be costly.
Test, or "Did we get what we needed?"
The earlier build phase and the current test phase occur at intervals. The testers' job is to find bugs in the system. They check that the product behaves as expected and as documented in the requirements' analysis phase. But the testing phase is also an important phase in your representative's work. The point is that you should also get a piece of your product built for testing at almost every 4 weeks.
The most frequent sin of the investor at the test phase is laziness and anger
Customers usually describe the functionalities and what they want at a very high level of abstraction. And when it comes to testing and experimenting on their finished part of the product, employees who are busy with their familiar tasks are reluctant to leave their comfort zone to check what is new. Investors, in turn, are unaware of the importance of this phase and condone such behaviour from their subordinates. This leads to outbursts, often even uncontrolled anger, and explaining their earlier decision (or lack thereof) with the excuse, "Well, you do this every day, don't you know what we mean and how it should work? It's pretty obvious, is not it?" Let me give you an example from your fashion industry.
A customer comes to you and says: "I want a dress".
You ask: "What kind?".
They answer: "Green, simple, size medium".
You give him the product she asked for. Without looking at the packaging or taking measurements, the customer buys, pays and goes home.
The next day, she comes back and says, "I did not want it. Why is it the colour of peas? I want the now fashionable sea shade. Why does this dress have such a low neckline? I used to buy dresses from you. They were definitely flatter. This is a size medium? I have always worn medium and this one is too big...
You reply that after all you asked for green, dress, medium and even bought it without measuring. I do not understand what the problem is.
After that, an immediate reply. What do you mean, what is the problem? You have been doing this for 20 years, you are a specialist, is it so difficult to guess what I mean? And so on. And so on and so forth.
Now do you understand the comparison? At IT, it is the same. Only the product does not cost several hundred EUROS, but usually several or even several hundred thousand EURO. Can you afford such a waste?
The solution to the problem of laziness and anger:
Testing is an essential phase because if you take the time to verify that all the requirements are met and the software works the way you envisioned, you will save a lot of money in the later development of the product. Simply put, the earlier you find a problem | an inaccuracy in understanding your requirements - the cheaper it is to make a correction in the code, and the investment cost will inevitably be lower. So never, ever underestimate the power of testing because it prevents future problems and also allows you to ensure the expected highest quality. Experiments and feedback allow us to gain interesting insights and help you develop a profitable product faster. All other actions and working methods are a form of waste. Waste that you pay for.
Software deployment, or "It's time to start using what we have"
The big moment has arrived. At this stage, the product is finally delivered to all the company's employees and often to the Investor's customers. Once it is fully tested and has no high-priority issues, it is time to present it to the users.
The most common investor's sin in the implementation phase - greed and uncleanliness
Many, especially inexperienced Investors, think that once the product is built, it will be perfect and they will use it "living happily ever after".
Unfortunately, only fairy tales for children end this way. During a large-scale software implementation (for all employees and customers), more defects or requests come to light that are treated as defects by a larger group of people, even though they were originally requirements of the developer. Then the temptation arises among some Investors to "get as much as possible" out of the IT service provider, preferably "for free".
The argument comes up: "Well it doesn't work now. But it used to work. I paid five grands for it and it doesn't work. How can that be?"
Remember that at the beginning of this text I wrote about entering requirements into the Product Backlog? This is not an imaginary Excel file, but one of the most important tools of project management. All, I emphasize all the requirements, their changes, missing decisions, decisions that do not match the concept, additional work are registered in it. They allow to recall every decision and every requirement that was formulated. The absence of an articulated requirement, on the other hand, means that it has not been implemented.
The solution to the greed and impurity problem
Be aware that the end of programming is not the end. There will always be optimization tasks. You will need to gather feedback from users, and if there are bugs, you will need to fix them. This process of adjustments and minor work can take up to 6 months after the project is completed. Mostly it's about small things, like - such a report would be useful to pull out, or change the colour, or here, when I click, I do not know what happens, or this message could be more accurate. Or even - the connection between the store and the ERP no longer works.
So, it pays to plan and budget for software maintenance in advance. And sometimes, even at the beginning of the planning, you should ask: "What will be the maintenance costs?" and "What can we do to keep the maintenance costs as low as possible?".
Let’s wrap it up
When you have a product built, remember to take an interest in it. Test it. Test it. Ask questions. I would say that after each release, get a few people in your office to observe their reactions to the prototype and simulations. Always have a mix of existing users and people who have never worked with the product before. Also, invite at least a Project Manager from your development team to the sessions, so they can take notes on what changes need to be made and see how frustrating it is for users when they do not know what to do.
This will ensure that your product is developed in the fastest possible time and at the lowest possible cost in a collaborative atmosphere.
