Can your mobile application handle a million users?

Most organizations, sooner or later face the need to implement a mobile application. While writing the application itself is quite simple, the problem begins when the application grows and begins to have more than a few million users.

It turns out that other rules apply when creating a mobile application for 10-100K users, and different when writing an application for several million users.

Many companies dealing with mobile applications are good at projects for a small number of users and face a severe problem when the number of users increases significantly. When choosing technological solutions or a provider of such solutions, you must consider what volume of users we plan to have in 1-2 years, so as not to rewrite the entire application one year from the first release.

The small number of users

An application for a small number of users does not require much. Most are code written on a mobile device. For the application we have some CMS (bought or written), a local user login system, some simple error tracking, and basic Analytics. The back-end usually stands on only a few servers, which can be enlarged if necessary. Sometimes, frameworks are used to create applications that allow you to create a user interface faster. Sometimes, to solve the problem of writing codes on two platforms simultaneously (IOS + Android), Xamarin-like environments are used.

And it works for small scale applications.

A large number of users

Writing the application for more users, we find very painfully that:

1.       Errors

When a fatal error occurs in the mobile application, and we learn from it through the opinions of users in the Google or Appstore store, it means that:

• The error has been present for at least several days
• We have a significant number of users who are not satisfied with the application
1% of users with 10K population = 100 people
1% of users with 1M population = 10K people - the chance for negative reviews in the Google store or Appstore increases significantly.

Even if we immediately take action and fix our error - it will take 1-2 months for the new version to propagate to 80% of users' devices (time before users upgrade the application) - in the best case, with a massive marketing campaign, we'll go down to about a week. Even if the error has no financial consequences and only reputation is the problem, it will decline significantly during this period.

2.       Performance

The mobile application, especially with a large number of users, often becomes a powerful marketing tool that companies willingly use. While our servers can handle the "average daily traffic" of users, triggering a marketing campaign that causes the activity of many users at a given time, such as promotions, can overload our servers. Standard databases (even on top machines) may not be able to handle all the necessary requests in a short period.

3.       CMS - Content Management System:

After some time, we start to notice that some of our users behave similarly. Therefore, we extract groups of users in several dimensions and adjust the elements of the application to the expectations of these groups. The more groups we separate, and the more we adapt our application, the more the complexity of our CMS will grow.

We will quickly conclude that automation would be useful, and thus the connections with other systems in our company. Then there will be a moment of truth of the flexibility of our CMS system, which we chose earlier, and the costs associated with new interfaces and expansion.

4.       User Database

The decision on the user database architecture is usually made at the beginning of work on the application. Often, at this stage, we decide to create a separate database only for application users because it is a cheaper solution. As the number of users increases, we naturally begin to see the benefit of communicating with mobile application users also through other channels and also in topics not related to the application itself.

Such a change of approach can, at this stage mean expensive adaptation and unification of user database modules in several applications throughout the company. Besides, we have a whole set of GDPR requirements to be met for more than one system at a time, on different types of data.

5.       Monitoring:

In addition to the critical errors that we face in the mobile application, there will also be smaller errors that will make the use of certain functionalities troublesome for users. Some of them will not be 100% repeatable, difficult to reproduce, and thus, information about them will reach us with a long delay. The problem here is not the size of the error but its impact on users. An error that occurs only once in 1000 launches of some functions in the application, with a population of 1M users can mean several thousand dissatisfied users a day.

In this situation, it will turn out how important it is to accurately and deeply track errors in the live application code. In these cases, even error recording applications available on the market may not be sufficient.

6.       OS Actualization

Manufacturers of mobile phones update the operating systems of their devices several times a year.

Sometimes, however, it turns out that our application or library that the application uses does not work 100% under the new version of the software on a specific phone model. When this happens, we have very little time to react because a well-functioning application may stop working correctly on thousands of devices overnight.

The speed of reaction is decisive here. If we learn about the problem from users, as in previous cases, it means that a significant part of them have already encountered the issue. Simple application monitoring systems will also not help much, because such problems rarely cause application crashes. Of course, the time needed to resolve the error inside of the library used by our application is correspondingly longer.

Without proper monitoring combined with appropriate application architecture and automatic live tests, this type of problem can be severe.

7.       Different versions of one functionality

The implementation of new features in the application used by a large number of users means that each new feature is "tested" by many users. Our internal tests must, therefore, be restrictive. However, when errors appear, we must bear in mind the fact that the new version of the application will not replace all the old ones in one day and for some time we will have several versions running in parallel. If the bug fixes force changes on the server side then for some time there will have to be 2 or more parallel interfaces that need to be controlled and then deleted after some time.

8.       Integrations

During the lifetime of the application, the number of servers necessary for its proper functioning, as well as the number of external servers that supply the application with data will increase significantly. Usually, such external servers are created by different teams or different companies. So every time a single server stops working, and the whole application will suffer, the component suppliers may blame each other, claiming that the error was not on their side and their SLA have been kept.

Of course, there are many other problems, such as interruptions in WIFI, battery with GPS, map positions, other UX behavior on IOS and Android, speed and availability of data transfer from cellular networks, etc.

So what can we do to make our application deal with a large number of users and increasing complexity?

Each of the problems listed above can be addressed in several ways, depending on the priorities.

The most important are:

• Application should be written in a way that allows dynamic error tracking in a production application on the side of users at least five levels:
• Source code
• Application error monitoring
• Monitoring of source code errors (separately DEBUG separately RELEASE)
• Monitoring of connections between systems
• Monitoring of system versions and live automatic tests

This approach allows tracking the operation of the application in real-time without being surprised that something is not working properly and take corrective action as soon as the problem arises, and even before users manage to express their dissatisfaction.

• Server part should be prepared in a flexible and scalable way so that it is resistant to temporary increases in the number of users using it. If needed, our servers will be able to scale to the desired size.
• The application is modular, and we can control all modules separately, and our CMS allows a lot of flexibility to automate processes. Our UX can be easily changed.
• The user base is well thought out and works with other systems in the company.

More complex application is the more activities around it need to be taken.

Costs - the solution must also be cost-optimal. By creating a mobile application you can easily fall into several traps from which the output to a larger scale can be a bit expensive. So, each element needs to be addressed in such a way that our monthly costs are not higher than necessary.

How to be more satisfied with your IT system provider?

In today's world, the vast majority of companies use external suppliers at least in some of their IT systems. In the previous part we have described the common problems like:

• BUZZWORD
• LOW ENTRY PRICE - WATERFALL
• PAY FOR OUR PROBLEMS – AGILE
• THE RIGHT PERSON MAKES DECISIONS
• PROMISES
• “I DO NOT KNOW AND DO NOT WANT TO KNOW”
• THE CUSTOMER DOES NOT INVOLVE
• THE CUSTOMER HAS NO VISION OF ITS SYSTEMS
• SAVINGS MAXIMIZATION
• TOO MANY SYSTEMS WITH ONE SUPPLIER

and here we will propose some tips which can be used to avoid them.

"What should you do then?"

Surprisingly there are just a few rules that you must follow, at least in part, to avoid problems in the future. (Of course, the list of rules can be extended)

Sometimes compliance is not easy in some business environments, however, the more attention we pay to them, the less chance we have for future problems.

The selection of a supplier should take place with the participation of at least several equivalent bidders. 

This requirement seems obvious. However, often the supplier "enters" the client's company in a way that suggests that it is the only entity on the market offering a given service, and the buyer withdraws from the planned tender procedure. Therefore, we should keep in mind that the IT world is full of great companies ready to meet clients needs.

Too many systems with one supplier. It may happen that a client satisfied with the previous implementation entrusts the implementation of subsequent key systems in the company to the same supplier. While this is desirable on a small scale, the customer must be careful not to entrust one supplier with too many important systems. The supplier, knowing that he has a dominant position, may begin to dictate the terms of the client, manifesting in overstatement of subsequent changes or long implementation times. It can also offer the client old technologies that will allow savings on the supplier's side, as well as higher operating costs on the client's side. This phenomenon is called "Vendor locking".

People who have an idea about technology should participate in discussions with suppliers from the very beginning. 

Technical people can look at the service offered pragmatically and recommend the best solution in terms of technology and support, and thus the subsequent costs of "operating" the system. Although their voice does not have to be the most important, it avoids many wrong decisions appearing at the beginning of the process.

The client should have a vision of IT systems and environments development.

It seems crucial to understand that the development of IT systems is also part of business, even though it often affects revenues only indirectly. Therefore, the client should allocate some resources for coordinating IT development because their costs usually turn out to be lower than the savings resulting from planned architecture development.

The customer should be involved in specifying the requirements.

In the case of Agile, this means delegating a person to assume the function of  a Product Owner (PO) for the entire duration of the project. In the case of the waterfall methodology, a strong commitment to defining requirements, followed by final tests and product acceptance. Without such involvement, the project may fail despite the best intentions and the commitment of the supplier.

The customer should supervise the supplier's activities. 

The requirement seems unnecessary at first glance. However, it often turns out that the project can get stuck in a trivial place or drift in the direction that the client didn't want to go.

If we run projects in the Agile methodology, even more significant commitment and constant contact with the supplier is required because the work result is delivered in intervals and the client must continuously monitor progress, backlog, and set task priorities.

Estimation of costs and profits in the long run.

When implementing a new system, you need to think carefully about its use strategies in the long run and calculate the TCO - Total costs of ownership, e.g., for five years, taking into account additional changes introduced in this period, infrastructure, licenses, etc. Often, after such an analysis, it turns out that that incurring slightly higher expenses for initial implementation saves a lot more money at a later date.

Analysis of manufacturing processes on the supplier's side. 

Under challenging projects, it also happens to analyze software development processes on the supplier's side, to assess at the stage of its selection how the subsequent cooperation will take place. It is not a frequent phenomenon and requires excellent competence on the client's side, but it allows you to avoid many costly mistakes, especially in sensitive or expensive projects.

Of course, there are many more elements to pay attention to, such as negotiation and monitoring of SLA, impression in a traditional way or DevOps, selection of the optimal environment (server room or cloud), costs of system changes, supplier's experience in new technologies, supplier technology partnerships with large market players determining the technologies used. The selection and proper management of the supplier are therefore crucial for matching the supplier to the customer and translates into subsequent costs of system development and support.

"How much it cost ?"

Does it mean that I have to have large IT team to cover it all? NO! 

You don't need a large team to provide the minimum support. However, it should be clearly said that the level of competence of people on the client's side delegated to IT projects will have a significant impact on the result of ongoing projects. Sustainable expenditure in this area can quickly pay back and save significant amounts at a later date.

In many companies, doubts arise when we compare costs vs profits directly at spreadsheet. A hard digit representing the cost of implementation often wins in a collision with difficult to estimate costs that will appear at a later date. As a result of focusing only on the lowest implementation cost, we often get a higher total cost of the system spread over years of operation, less flexibility and the associated smaller system capabilities. Thus, the length of the time horizon considered for an IT system can have a significant impact on costs.

Are You manage your team effectively?

How do you manage your team? Is it just a group of people, or do they form an efficient team?

Team - The magic word. We all take care of the team, motivate it, invest in it, integrate it, etc. We want our team to be simply the best.

... And ... Then life comes ...

The market is "difficult", there is a shortage of employees, the budget is always too small, the client is very problematic, people have to work after hours, there is never time for integration and training, and the number of projects only increases

OK. What can we do about it?

Take the actions. Seriously! If we take small appropriate actions, and if we take them successively, after some time we will reach a magical state in which, after the project is completed, we will be able to look at our team and feel pride, not only because the project was a success but also because the team exceeded the limits of what we thought was possible.

How do you do it?

There are no miracles here. There are several elements that need to be addressed and kept an eye on. It won't be easy the first time. And ... the next time you will still have to spend some time :)

1. Recruitment & team composition

Recruitment is a critical stage in the formation of our team. If we have the chance to recruit new people, we must do it carefully.

In the current world where we try to save every 5 minutes, I believe that taking the extra moment to understand the candidates will ultimately bring us much more significant savings in the future. So let's take a few moments more to better understand the candidate's CV or ask a few additional questions during the interview, or let us invite a candidate whose resume is not entirely clear to us but he has the potential

Let us not give in to stereotypes saying that people who have been fired from work or with holes in their life or simply other than the market standard should not be taken into account. On the contrary, such people often (but not always) prove to be more valuable than the average mass.

Before we start looking for new candidates, we also need to think about precisely what kind of people we need. Not in the sense of position but the sense of place in the team. We need to think about what role individual members will play in our team, so that the team is as effective as possible

It may happen that we will have a real star in our team who will prefer large and difficult topics, we can also have people who prefer small and simple tasks. We may have those who can set standards for others and those who will comply with them. Our job is to find the right place for each team member, where he will feel best and where will be able to give the most.

2. Integration

For many managers, the recipe is simple = once in a while we gather everyone for an integration trip and sometimes go out for a beer with the team after work. Nevertheless, we won't achieve any spectacular results if we don't go further.

Integration is a team activity - thanks to it, team members work together more easily and effectively. So we have to find a way for team members to perform more tasks together.

• These can be repetitive activities that require interaction with others, which are performed periodically by someone else.
• These can be short trips to conferences (usually they are cheap, and one day outside the company without a sophisticated agenda gives you a chance to change the team's optics.)
• These can be workshop tasks in the office during which all team members will be involved and where the result will be the work of the team (e.g., the team can come up with a new process or internal procedure.) 
• These can be internal training done by team members for colleagues.

And more ...

3. Tailored Tasks

Each team member is different and has a predisposition to something different. Our goal is, therefore to find the right tasks for each individual. Tasks in which he/she will be able to prove itself 100%, e.g:

The best developer may feel great being able to solve a difficult problem or find a well-hidden error. However, if we ask him to write documentation of what he did - he may take it as the greatest punishment. We may also have team members who will not write the algorithm as quickly as others, but based on frameworks created by others, they will refine the application and make small adjustments.

So, tasks depend on the environment and predispositions of team members. Dynamic matching of these tasks is also essential so that everyone is happy to do what they do. Keep in mind that preferences can change even a few times a year, so it's a continuous process.

4. Management

Here are the basic elements:

• We do not use micromanagement,
• We give as much freedom as possible, but we firmly require a minimum of artifacts necessary for the functioning of the project.
• We check the status of work regularly, but not often
• We help! - Helping is the most crucial point here - our goal is to help our people achieve their goals because they work for us.

5. Motivating

What motivates people ...?

There is nothing new to discover ...

• VISION
• GOAL
• Participation in decision making
• Responsibility
• Teamwork
• Communication and Integration
• Manager's person - description below
• Rewards – not money based
• Money :) - Yes, there are some conditions in which this method works - but this is the last element on the list, and the situations where we should directly use money as a motivator are very rare. I invite you to my article on motivating and money.

6. Appreciation

Every employee from time to time exceed the average level and do something exceptionally well. It is important to appreciate it and to appreciate it publicly so that others also want to feel appreciated.  In this way we can significantly increase the efficiency of the entire team.

From the other side, if it happens to you that a team member did not perform as much as he should and failed, then according to the rules, instead of admonition, we talk with such person 1: 1. and check what went wrong and why, instead of showing our dissatisfaction. We need to show tips for the future and ask about the lessons learned. Constructive feedback is critical here.

7. Manager

Yes, It is no surprise that the team leader has a significant impact on his team's effectiveness.

Experienced manager:

• He knows what to do not to tire the team on a challenging project.
• Anticipate emerging problems and react before you have to put out the fire.
• He will address the problems of the project, and will correctly match the team to the given project.
• Coordinate the project's business activities with team activities to solve potential problems before they occur.
• He will take care of motivation, integration, and most importantly, team communication.
• He will address emerging problems instead of avoiding them, hoping that the team will deal with them on their own.
• When a problem occurs in a team, it will solve it instead of duplicating.

It's no secret that the effectiveness of the entire team, depending on the manager can vary by 200% or more. So the same team doing the same project can be 2x more effective (or 2x less effective) depending on who manages it.

It must be remembered that the use of the elements described above requires a certain amount of time. However, this time is more than paid back. Creating spaces for our team can be compared to creating a highway for cars (our developers). On the right track, you can develop high speeds and race against others. If the road is narrow and bumpy, we'll enjoy getting to our destination.

Are you overpaying your developers? Productivity vs. Salary

Do your developers earn adequate money for their effectiveness? Maybe you overpay for some?

It seems evident to us that those who work more and better should earn more. Sometimes, however, we have the impression that this correlation is not so clear. So what does it look like in a typical project team, and what can you do about it?

Let's consider the IT developers

Imagine a big hall full of IT developers - let's say, 100 people. For simplicity, 

let's assume that they were all employed at the same time by the same recruiter and earning precisely the same amount of money +/- 20%.

How big the difference in efficiency can be between the weakest and the best developer ...?

I can almost hear voices saying that there will be a Gauss curve... Sure, it will be a Gauss curve, but what value will it have?

Let's try to estimate how much the effectiveness of 2 developers may differ?

10%.....?......20%.....?......50%.....?......100%.....?

The Answer:

The subject was scientifically tested several times over the past several years, and the observed results ranged say the difference between the worst and the best programmer around 10 TIMES! YES! Side-by-side developers can vary in efficiency by ten times or more.

Can the difference be greater? - There is no limit. The most significant difference I have personally seen was around 100 times. Nevertheless, to simplify the further discussion, let's stick to the x10 multiplier.

Since the difference is so significant why developers earn almost the same amount of money?

An essential element here may be seniority (junior/senior) Senior earns, of course, more than junior and it can be assumed that the length of the internship may slightly affect its effectiveness, but in reality, the multiplier x10 is not expected here. A person who works for a long time does not have to be more effective than a person with relatively low seniority.

How often have you seen a developer who is five times more effective than his colleagues and earns only 20% more, and leaves after some time because he does not feel appreciated?

How often have you seen a developer who is five times less productive than his colleagues and earns almost as much as his colleagues despite working much less effectively?

What can we do?

Let's focus on three essential elements that will allow us to increase the overall effectiveness of the team.

• Appropriate recruitment

• Measuring effectiveness and developing knowledge

• Suitable team composition and adaptation

OK. Can we measure the real efficiency of developers?

At first glance, this seems simple; We can ask the developers to write the same algorithm and see who will do it faster...

Unfortunately, this is not so simple, and the more we explore the subject, the more we will understand that we are trying to compare pears to apples.

Does this mean that developers' efficiency cannot be measured?

It can be done! Should be done! The truth is, however, that we can't easily translate the number of lines of code, time spent, issues fixed or errors found into the real effectiveness of programmers. Reliable measurement must take into account several factors, preferably over a more extended period.

OK. Let's assume that we have measured the effectiveness of our developers.

Is it not enough to get rid of the few least effective, and significantly raise the salary of these top developers?

Not necessarily.!

Let's not forget about point 3 above.

Without developing the right composition of the development team (the last of the 3 points above), the other 2 points are of little value.

Throwing out less effective developers from the team is not always the best solution because they can sometimes play an essential role in the team. Similarly, a significant increase in the salary of the best developers (the measured ones) can generate more demanding attitudes.

Besides, it should be taken into account that less efficient people can perform other vital roles in the team that we are not even aware of. Removing them from the team without analyzing the composition of the team can do more harm than help.

And here we come to the point - sometimes it is not as important as the effectiveness of a single developer, but how effective is the whole team with its participation.

Moment, Does this mean that you can't do anything or you don't have to do anything?

You have to do it!
You have to measure efficiency, but... it won't be 1 KPI.
You have to pay more for the best but... not x10 and not directly to everyone.
You have to deal with people who add nothing to the team - but...
You must also take into account factors other than efficiency.

&….

The most important thing is to arrange the team, rules in the team, how to work, and to adapt roles and tasks to make the teamwork well.

Only then, treating these elements as a whole, can we say that we have a good team.

Are you satisfied with your IT system provider?

In today's world, the vast majority of companies use external suppliers at least in some of their IT systems. There is a broad market for IT suppliers who can provide all possible IT technical solutions, so the right choice is difficult.

Can every supplier guarantee high quality at low price?

Here are some examples of what might go wrong:

• The IT solution provided is not what the customer expected
• Implementation goes on forever
• Software does not meet the expectations and is not used after deployment 
• System and infrastructure maintenance costs are high
• An inflated price or base the system on expensive components
• Use of technology that is considered obsolete
• Poor quality of delivered product and difficulties with expansion
• High costs of subsequent changes and corrections
• Lack of proper support and frequent failures
• etc…

Most of these problems boil down to incurring higher costs by the customer or generating technological debt, which requires  repayment in the future by subsequent modification of IT systems, and thus further charges.

Every customer strives to get the "best price." Besides, they expect a precise valuation of the implementation, even though they describe the requirements in a very imprecise way. In addition, the final price of the IT system has many components and not all are visible immediately.

"What exactly does low price mean?"

Here are some examples of IT system price components (there are many more)

• The price of the implementation itself

• Cost of future system expansion and changes (usually higher)

• Cost of implementation of additional future interfaces

• System maintenance costs

• Price of component licenses

• The cost of the infrastructure on which the system runs

"Why do the problems with suppliers and customers appear?"

As usual, the world is not black and white and problems appear on both sides the one of the solution providers and the one of the customer. Sometimes these problems are dictated by pure economics, sometimes by a lack of knowledge, and sometimes by a well-thought-out strategy. Often there is also a mismatch between the supplier and his capabilities to meet the customer’s needs, and then a lack of adequate control over emerging problems. Even the best supplier will not help if the customer does not know what he wants and does not allocate resources to find out what his expectations really are.

Regardless of the source of the problem, the result means usually a higher cost. Let's see what can happen on both sides. (of course, the list does not exhaust all possibilities)

Problems that the Supplier generates:

Many IT suppliers have excellent practises developed over the years, thanks to which customers implement systems without any problem. However, there are also those with whom cooperation goes hard.

BUZZWORD

IT service sellers use keywords that are supposed to make the customer find him more professional/reliable, which will allow him to sell his product more easily. In some companies, floral speeches using the words "Agile" "BigData" "BlockChain" "Machine Learning" "AI" and others impress the auditorium unaware of the topic, which results in buying an idea of future technology rather than a real system.

LOW ENTRY PRICE - WATERFALL

The supplier is trying so hard to get the contract that it lowers the system price to win the tender. In theory, the low price problem stays with him because he signs a fixed price contract. However, the problem lies in the scale, the deal, and it concerns both parties. It is called “Low ball”. Within a few months of starting work, the supplier who has lowered the price begins to creatively justify the increase in expenses so that the project pays off to him. If the client is not heavily involved in the project and does not control the whole situation, he can agree on additional costs considering the deadlines and the money already paid for the previous stages, especially considering the time associated with repeating the supplier selection process.

LOW ENTRY PRICE - AGILE

For the Agile methodology the supplier can declare and receive remuneration for a larger team than actually working on the project. If the client does not check how many people are involved in the project, it may turn out that the low sprint price means a smaller team.

THE RIGHT PERSON MAKES DECISIONS

IT solution providers sometimes focus on "selling" the system to people on the customer’s side who do not understand its technical aspects. In this case, technical IT people are only included in the project once the implementation is established in business terms. As a result of this course of action, the client may unknowingly purchase an outdated or expensive IT system that does not fit into the overall IT strategy.

PAY FOR OUR PROBLEMS – AGILE

It happens that suppliers working in the Agile methodology have problems with delivering the content of agreed sprints. Often it is due to a poor estimation, poor management or temporary resource problems. The effect, however, is shifting some of the functionality to the next sprints, thus increasing the cost of the project. If the situation is common, the project costs for the client may increase significantly.

PROMISES

"Nobody will give you as much as I can promise you." Many suppliers promise that they can provide any system in any technology in a very short time. And of course in Agile methodology! In most cases, there is nothing behind the declarations and the supplier has experience only in a few of the most popular technologies and adjusts the final solution to the technology he has mastered. Sometimes it can be compared to making a car out of cookies. It looks and tastes good but does not really want to ride.

Problems that the customer generates:

The customer himself unknowingly creates many difficulties in implementing an IT system.

Here are some common examples of problems generated by customers:

“I DO NOT KNOW AND DO NOT WANT TO KNOW”

Corrections and changes in the IT project are normal practice and result from the process of refining the customer's specific requirements. If however, the client assumes that an IT supplier will come and use a magic wand to solve all his problems without knowing the principles of its operation. In this case, the customer makes a lot of assumptions that are not spoken out and written down. As a result, despite the best efforts of the supplier, the customer buys a system that does not meet his unspoken expectations and which will require many corrections immediately after implementation. The phenomenon of generating technological debt often arises, which inhibits the further development of customer systems.

THE CUSTOMER DOES NOT INVOLVE

Carrying out a project with an external supplier requires a considerable commitment of resources on the client's side. He should control and synchronize his activities with the activities of the supplier, as well as perform tests of the delivered product. Lack of such involvement may result in dragging projects over time and problems appearing in the system long after its completion. If we use the Agile methodology, the participation of the Product Owner (PO) is even more critical, because he should prioritize tasks for each sprint and make sure that the delivered product is in line with expectations. (more on this in the Agile article). Product Owner (PO) is a very important function on the client side, if the supplier proposes or agrees to engage with the Product Owner (PO) on his side instead of on the client side it can be a sign that Agile in the project appears only as a virtual concept.

THE CUSTOMER HAS NO VISION OF ITS SYSTEMS

In today's world, one of the greatest values in a company is data and their flow between existing systems. IT architecture and the speed of making changes in IT systems can be a decisive factor determining the company's competitive edge on the market. If the architecture is inefficient, the customer will be forced to wait a long time and incur high costs of data processing that allow even fundamental decisions to be made. The implementation of subsequent solutions on such architecture will cause further increase in complications, delivery time, costs and, as a consequence, will generate the technological debt.

SAVINGS MAXIMIZATION 

IT systems do not have to be expensive. Often, however, when deciding to implement the system, customers choose the cheapest possible solution that only partially and in the simplest way solves the business problem. After several years of such activities, it turns out that IT solutions in the organization are one big collection of corrections to corrections that generate high costs and which cannot be developed cheaply. Therefore, when making decisions about project costs, it should be remembered that initial savings can quickly turn into high monthly fee, because suppliers may want to make a profit on a low budget project through higher support and correction costs.

TOO MANY SYSTEMS WITH ONE SUPPLIER

It may happen that a client satisfied with the previous implementation entrusts the implementation of subsequent key systems in the company to the same supplier. While this is desirable on a small scale, the customer must be careful not to entrust one supplier with too many important systems. The supplier, knowing that he has a dominant position, may begin to dictate the terms of the client, manifesting in overstatement of subsequent changes or long implementation times. It can also offer the client old technologies that will allow savings on the supplier's side, as well as higher operating costs on the client's side. This phenomenon is called "Vendor locking".

"What should you do then?"

As the topic is still extensive we described this in a separate article “How to be more satisfied with your IT system provider”