The worst-case scenario for your project – what can go wrong if…

Not every partnership can be considered fruitful and successful. There are many reasons why you may tend to choose not the right service provider – you may want your app to be launched as quickly as possible, you may make your choice based mainly on the price, you may also trust a software house rep who promises the moon which you’re supposed to get on time and within your budget, naturally. 

Unfortunately, it appears after a while that the moon you’ve been promised is as far away as ever, and what you actually get is going well over the budget or a poor-quality product.

Having worked with a range of different companies, we’ve heard a number of stories about making bad decisions and about the consequences of such decisions. Instead of waiting for an “opportunity” to learn from your own mistakes, you might as well learn now about the effects of choosing a wrong service provider or skipping some important stages in the course of a project.

…if you work with just service providers, and not with reliable partners who care about your business goals and values as much as you do.

You have an idea for a web platform – an innovative tool, a web service, or a web portal. You refine your vision for weeks, you collect the resources necessary to make it a reality. It will be your first start-up, but you’re positive that the app will become a perfect response to market demands. You haven’t consulted your idea with many people yet, polishing it up alone.

You’ll spend the available budget on the development of an MVP – a minimum viable product for your platform. You establish a business relationship with a company who will help you make the MVP version of your product available to your target audience. You provide the development team with your guidelines; they start their work almost right away.

Just under two months later you launch the production version of your platform – available to end users. The app looks just like you imagined it. You analyze the behavior of its users, their interactions with the system, their perception of your product. 

 It turns out that… they simply don’t want to use your product. Your idea doesn’t appeal to them and now it’s going to be hard to modify the platform in a way that would let you win their interest.

You’ve sunk several dozen thousand zloty into a project that didn’t have a warm reception in the market. Good thing you didn’t decide to go for the full version of the platform straight away!

What went wrong?

You probably put your idea into the hands of people who didn’t have the necessary critical business approach. It could’ve been a software house focusing only on the delivery of a service, and not on creating a product that both the client and its users would be happy with. The code of your platform might have been created by top-tier developers, but there might have been nobody to advise if your vision really had the expected business potential or if it would be better to modify it a bit or go for something else entirely.

How could it have been prevented?

Making an MVP version of a platform available to a user group doesn’t (and actually shouldn’t!) be the first step of verification of a concept. Experienced and knowledgeable employees of a software house have surely supported many start-up initiatives and have not only the relevant technical but also business expertise you can take advantage of. Be open to constructive criticism, advice, and feedback. Steer clear of yes-men who have absolutely no reservations or suggestions!

…if you skip the pre-implementation analysis stage.

Your company is planning to create an internal tool – an advanced platform intended to improve employee performance. As a person responsible for the implementation of the tool, you know perfectly well what processes the system is to support, what features it should have, and how its users should interact with it. You find a software house. You talk about the vision and the form of the product. You set the date when the platform is going to be ready. The software development team proceeds with the planned work.

Each next sprint review raises more questions regarding your service provider’s ability to keep the agreed deadline. It’s more and more common for them to fail to complete the project stages according to the schedule and deliver on time. You slowly realize that the promises made regarding the deadline and the budget were actually empty, with no hard data to support them.

The software house’s employees are only halfway there but you’ve spent almost all your budget. But your company has already invested too much to discontinue the project. So you carry on, but none of the parties is actually able to tell how much the entire project will cost in the end.

What went wrong?

You’ve probably skipped the pre-implementation analysis stage, the effects of which you can still feel as the project progresses. Building a new platform without planning in advance accordingly and, what follows, without making realistic time-, deadline-, and budget-related estimates makes the project take ages to complete or results in a poor-quality solution. 

How could it have been prevented?

An in-depth requirement (pre-implementation) analysis should have been carried out, of course. The bigger the project your company is to deal with, the more you should pay to the stage of planning and drawing up the relevant documentation. A requirement analysis involves becoming familiar with the client’s needs and expectations, developing the functional and technical specifications, drawing up the work schedule, and determining the actual budget and the realistic deadline for the delivery of a fully functional version of the platform. It is also crucial if you want your product to be put together really well – during the analysis, the team involved in the process creates a backlog (a list of activities and work to be done) which serves as the basis for further stages of work.

…if you don’t place enough emphasis on quality from the very start.

You have a plan to build a new platform. You want to have it ready soon. It would be also good if it didn’t cost an arm and leg. You hire a software house who has offered you a good price. After a few months you receive a functional product.

Your team maintains and develops the platform – alone or in collaboration with external partners. After a while, i.e. a few months, a year, two years, you notice that you spend much more on problem-solving and on the maintenance of the app than on its development. Adding a new feature or modifying an existing one leads to errors or failures. Each further extension means more and more problems. Further development is very troublesome, or even impossible. Since you spend most of your budget on maintenance instead of on development, you’re unable to keep up with the competition. You see other companies develop their systems, enter new markets, and establish new business relationships while you struggle to make your system run in a stable manner in the first place. You must be wondering what went wrong – after all, it’s a brand-new platform, isn’t it?

What went wrong?

The service provider you chose to build your platform didn’t deliver the expected quality. It’s possible that they might have engaged insufficiently qualified people into the project – people with little experience, software developers who were just making their first steps in the chosen technology, or a team composed of individual who had not worked with each other before. It’s quite likely that the service provider – in their effort to keep the price low and the delivery time short – skipped some crucial elements such as carrying out a pre-implementation analysis, developing the relevant specifications, or drawing up the work schedule. As a result, you received a product which was not suitable for safe and stable further development.

How could it have been prevented?

When choosing the service provider to work with, you should have considered not only the price or the delivery time but also the experience of the selected company – it’s good to have a look at their portfolio, testimonials, previous projects, or even contact some of their clients to ask for recommendations. If a service provider has no experience with the technology you’re interested in, you shouldn’t work with them. Alternatively, you may as well “recruit” the people you need yourself. It is, of course, a common practice when you establish business relationships with freelancers, but it’s now slowly becoming a standard also in the case of software houses. A company may let you interview software developers and verify their skills and abilities by asking them to solve a few test cases.

Keep your finger on the pulse of your project as it progresses. Check the quality of the developed solution on an ongoing basis and don’t hesitate to speak up to the team if you discover some errors or aren’t satisfied with the outcome of their work.

Feature migration to version 2.0 of the system

Moving the existing platform to a new, clear structure 2.0. Complete elimination of technical debt, paving the way for scalability and arranging for an option to develop the system without limits.

…if you pay little attention to tests.

You hire a company to handle some issue you have with your platform. This may involve optimizing its performance, changing the UX and UI, redesigning some of its features, etc. You’ve arranged the work to be done, the date by which the platform will be modified and ready for UAT (user acceptance testing), and the date when the platform will be available to its end users – to your clients or your company.

You get access to the platform’s updated version within the agreed time. You’re happy because the project proceeds according to the plan and the service provider has delivered the solution on time. You start clicking through the platform. Unfortunately, after a few clicks you already know that you don’t even have to engage your developers or testers to be sure that there are errors. You make a list of elements that don’t work as they should – including those that did work before the software house started tampering with them. Not even a full hour has passed and your list of remarks has grown really long. You definitely can’t launch a platform with so many errors – the entire schedule has just fallen through.

What went wrong?

The company you hired did not pay enough attention to tests. It’s possible that they pushed quality into the background already at the stage of development. But it doesn’t change the fact that any errors should have been reported by the service provider’s QA specialists (responsible for quality assurance, making sure that the developed application fulfills the expected level of quality, usability, or functionality) and rectified by their software development team before you received it. It’s also likely that the software house planned the work to be done incorrectly. This resulted in your budget being spent mainly on development, which meant there was too little time to test the application thoroughly. Another possible explanation is also that the quality of the product was verified by an employee who was not qualified enough or simply didn’t apply themselves to the job.

How could it have been prevented?

This should have never happened in the first place. A good software house would find it unacceptable to send a half-finished, faulty platform to its client. In order to reduce the probability of occurrence of such a scenario, you and your service provider can draw up a schedule that provides for enough time to check the quality of the developed product. Before the product is launched, you can also specify the tests to be run and name the person responsible for running these tests – if you want this person to be a ‘seasoned’ senior or a less-experienced, lower-rank employee. 

…if you don’t arrange for the right level of information security.

It’s Friday night. You go out to a bar. You’re having another glass of wine or whiskey. Then, you hear someone at the other end of the room, talking about features that sound deceptively similar to the features of your company’s system. It’s been a tough week alright, but are you that tired to be hearing things? But then you feel you have your heart in your mouth – you can hear the name of your company being mentioned. How is that possible?!

Your colleague tells you the other day that they found a file with a part of the source code of your platform on GitHub. You’re told the file was uploaded by a developer from a partner software house. The application code, which should be the most guarded element of your entire business, is now available to anyone – including your competitors!

What went wrong?

The above situations may sound surreal but they can really happen if the company you’ve partnered with doesn’t place enough emphasis on information security and doesn’t care about its internal processes aimed at controlling data leakage. Your project is threatened if you and your service provider haven’t signed an NDA (non-disclosure agreement).

How could it have been prevented?

A good software house spares no effort to secure the platform source code or to encrypt unofficial versions of your platform (development or testing environments), and has a set of principles in place that prevent its employees from sharing work-related information outside the company. It’s always a good idea to ask the software house you intend to work with about the adopted practice of securing information.

The basis for the security of your project should involve signing an NDA. If the service provider doesn’t suggest concluding such an agreement first, you should treat it as a warning sign.

To sum up

Some of the above stories did happen. Some have been inspired by the accounts our clients and business partners have shared with us. 

It’s much safer (and cheaper, first of all) to learn from someone else’s mistakes. This is a principle we ourselves live by. Whenever we’re about to enter into a business relationship – regardless of whether it’s a one-off service or a long-term partnership, we analyze the potential threats and plan the relevant processes.If you have a vision of a product or a plan of improvement of an existing platform, and if high quality, ability to meet deadlines, and stability are what you’re looking for, get in touch with our specialists. Even if you decide not to work with us, we’ll still be glad to advise you on the factors you should pay attention to when your project is already underway.