“We are sorry but we decided to end our cooperation” – such information can shock. Especially when it comes from a software house that you had been cooperating with for years. What has led us to such a situation? Why did our longtime partner that was providing us with IT services decide to leave? Why did they leave us in the lurch? We will have to have nerves of steel to face answers to these questions.
Regardless of whether we operate as a start-up or a medium-sized enterprise that has been present on the market longer, we must answer these difficult questions. What did force an IT company to leave us alone with our problems? What did lead our IT partner to a state where they decided they have had enough?
Reason number one: Lack of budget for quality software
In other words – we are not planning to invest in good software but we expect great results. In practice, we are counting on the fact that the IT company will introduce new functions to our product, but fail to notice that improvements and implementation of new solutions generate additional costs.
We refuse to accept any arguments presented by our partners that a large part of the budget is consumed by extensive automated tests, or updates of used libraries and plugins. We are falling into a trap of saving on our own offer and therefore we are going deep into technology debt. What does this debt mean? In a nutshell – our sin of abandoning good analysis and design.
We start working on a product when we are not prepared. As it goes along, we are ignoring suggestions made by an IT company which is trying to talk us into increasing the budget for necessary updates.
Overcoming debt requires time, resources, and money, and finally we have to face the painful thought that we have lost. The only thing our IT specialist can do now is throw up hands and say “did we not say that?”.
Reason number 2: very rigid definition of scope of works
We are in the middle of our IT crisis. We have fallen into technology debt and have been saying the debt does not exist for a long time. Eventually, we decided we have to fix the mistakes and get the project back on the right track.
Our partner offers us possible solutions and a wide range of works that must also be adapted to a dynamically changing technological environment. Of course, the large amount of work and the prospect of its multiplication means raising the financial rate which we do not like that much.
We have an idea how to fix the mistakes cheap and we set a very rigid scope of works. The partner patiently explains that this approach only seems like being cost-effective and in the long run it will translate into even greater expenditures and delays.
We are not convinced by this explanation. We hit a wall both with our project and and the cooperation with our IT company.
Reason number 3: Bad business model of the product
We have prepared and implemented a product that we invested a lot of money in. We entered into a long term cooperation with an IT company that technically wise has delivered a working product to us.
We are happy with the result but after some time we see the investment is not making profit and our product met with no response on the market. We consult our partners and hear what we do not want to hear. We find out that we missed huge changes on the market and we will have a hard time delivering our product to customers.
We did not react properly and our marketing strategy and business model that we developed a few years ago have aged. Our assumptions were too rigid and we have been left behind with technology and marketing of our product.
Catching up will all this means enormous amount of work and budget as well as redefining the project assumptions. We are not ready for this. Then frustration and helplessness appear.
Reason number 4: Software – we do not want to be involved in the process
We have a great idea for the software and we find a company that we want to start cooperating with. They talk to us as if they were using a foreign language unnecessarily complicating the creation of what we want to bring to the market.
The product is simple and the process of implementation should be painless. We order and pay, we do not have to get involved in the process because we have specialists that know better than us how to do it. Software house explains the meaning of close cooperation, joint design, testing and implementation processes to us.
We do not want to be involved, we prefer to get a finished and tested product. To our surprise, the company decides to resign from the order.
Reason number 5: Scrum? Why do we need scrum?
We have a big project and want to agree on a fixed price with the contractor. The company estimates working time to be many months and points out that the project has many gaps and imperfections that can cause considerable issues during implementation.
They suggest using scrum methodology and implementing individual stages following effective and agile work in sprints. However, we have an already planned budget and are afraid that gradual implementation will incur extra costs.
We insist on a fixed price for the entire order. At the same time, we do not accept arguments that with such a complex project, if the assumptions change, the whole thing will have to be coded again from scratch. Our software house withdraws from the talks.
Reason number 6: We underestimated the scale
We managed to get a big budget. We have ambitions to create a large system and are focused on actions. Our software house builds the system for us according to the specification. We implement the project and suddenly we face huge costs of maintaining such a solution.
There is a financial issues and we are forced to look for savings. Unfortunately in the worst place possible, which is in the costs of system functioning.
The light at the end of the tunnel – how to avoid all that?
The above nightmare scenarios often happen. Fortunately, we can learn from (someone else’s or our own) mistakes and avoid the situation when our software house leaves us in the middle of a crisis.
Let’s get ready well for the project and remember about:
• constant monitoring of our target group and market situation
• adapting our marketing and business strategies to dynamically changing reality
• factual cooperation with an IT company when creating the product
• avoiding technology debt
• flexible scope of work when in a crisis
• software updates
• choosing Scrum methodology
• appropriate scale of the project