IT - what was important yesterday and what will be important tomorrow



Over the last few years, not only the way the IT industry operates has changed significantly, but also its perception by business. Today's standard was difficult to imagine a few years ago, and today's challenges are only a foretaste of what business will need in the future.


Yesterday

The operational activity of many companies took place mainly in the off-line world, where IT and software development only supported their operation, and advanced on-line technologies were not crucial to achieving an advantage on the market. Many organizations were based on monolithic IT systems developed over the years, requiring costly refactoring emerging along with the need to integrate with new business elements. This was often the reason why IT was perceived as not responding quickly enough to the new needs of the business side. With limited budgets, IT departments had to implement solutions that continued to generate technological debt (on a smaller scale, but still). Buzzwords such as Agile, AI, Big Data, BlockChain, Marketplace, Micoservices, and the Cloud began to appear, being a breath of the upcoming new approach in IT.

 

Today

Currently, we all understand that efficient IT systems are not only necessary for the proper functioning of many organizations, but also often constitute the source of their competitive advantage. Customer expectations, and thus also business expectations in this field, resulted in a significant increase in IT budgets, which translated into an increase in the demand for IT specialists, and thus their price on the labor market. Thanks to new technologies and flexibility provided by the cloud, macro-services, machine learning, and the increasingly better understood Agile methodology, IT is able to deliver business value faster and tries to catch up with the ever-growing business needs. Hybrid and remote work have become a fact, although we are increasingly seeing the threats they pose.

 

Tomorrow

In the future, we will further automate the software development process, thanks to which we will be able to deliver new stable and reusable IT solutions necessary for the expansion of our business even faster. Flexible, self-scalable and self-learning IT systems will become a natural element of the organization's development. Maintaining the coherence of hybrid / remote working teams and their commitment to the company will become a key challenge, increasing the importance of team management and thus the demand for leaders. Strong and flexible IT in an organization will become like electricity at home - obvious to everyone.

How did Agile "land" in your organization?


The word "Agile" is one of the buzz words that some time ago was spoken by everyone and in all circumstances. Many organizations "implemented" Agile and expected spectacular results that ... did not come. The great hype about this methodology is becoming more and more common, and we increasingly see that the topic is a little deeper than we thought and a bit more complicated.

How is it with Agile then? Works or not?

Yes! Properly used, it works very well. It's like a road roller - it will be the best tool for leveling the road, but you will try to swim with it ... you will sink.

Does this mean that we use Agile incorrectly?

There are many factors that favor the use of Agile methodology. There are also many environments and projects in which Agile will not help. Agile is a bit more than a methodology and goes much deeper in the way the company operates than we think.

How do we implement Agile?

Agile "implementation" often requires a change in the mindset of a significant part of the organization, which is neither easy nor quick. Therefore, usually after the initial success and a series of IT training, the organization claims that the implementation has already have been completed, even though only the first step towards agility has been done. Often, after a period of initial euphoria, there is a time of first disappointment with agility and wondering if it works properly.

Agile on the side of software suppliers

Nowadays, on the wave of a general trend, every software supplier declares that its organization is Agile. Unfortunately, in the vast majority we can come across one of several cases:
  • The organization only claims to use the Agile methodology while the whole team works as usual. The customer pays for a specific amount of resources while the supplier juggles resources between projects. To find out about it, It is enough to ask for the name list of developers assigned to us with emails and telephones, and then check from time to time how often they answer questions to find out that they are now not on the subject of our project.
  • The organization is divided into small teams that have kanban boards and does daily morning stand-up meetings. It's a little better here than in the previous case, but often, apart from these two elements, nothing else happens. The team often fails to deliver what has been declared in the sprint, and the project manager creatively explains to the client that this is what agility is all about and then gradually transfers the unfinished tasks to the next sprint. Over time, the supplier's PM builds large time buffers to show that his team is getting in time, but the effectiveness of such an organization is very low.
  • The organization is divided into small teams that are dedicated and tailored to projects. The basic principles of Agile are followed, and tasks from each sprint are implemented in time. The problem begins to appear when we want to release a product because it turns out that quality does not quite meet our expectations, which means that SCRUM at the level of the team itself works, but at the level of project management it does not quite work.
Often, suppliers also use the word Agile as an excuse for poor management of the project itself. "Since the client pays for each day of the sprint team, he can also pay for the day of delay." Let's keep in mind that agility does not release anyone from delivering the agreed sprint scope on time.


Agile on the client's organization side

Agile "implementation" usually starts with the IT department. Project managers and engineers learn that instead of working on a requirements document, they will now be working on user stories. A tool supporting task management is being implemented, and a whiteboard with yellow stickers appear in the room. Everyone organizes daily stand-up meetings. We have enthusiasm for a while. After several months, however, it turns out that:

  • Projects implemented in Agile tend to drag on forever
  • Business owners behave like children in a candy store - every few minutes they are at a different shelf and want everything
  • PM is pushing more and more functionalities into every sprint because the dates are running out
  • After a few months from the start, it turns out that the project is not delivering the expected functionality and additional resources are needed to complete it
Why is this happening?

In a standard approach, IT is responsible for final user satisfaction. In other words - If the finished product does not suit the users - this is an IT problem. So IT has analysts, who describe what exactly is to be done. It is done at the beginning of the project, through a series of workshops with a business client and business users. The disadvantage of this solution is that it is often impossible to do it accurately enough or business conditions change over time (often also business owners changes). Sometimes, users do not know precisely what they want until they see the finished product, then it turns out that "a few" additional functionalities are still missing.

Agile meets the problems described above and reverses the situation slightly. IT is only a service provider and contractor, and a significant part of the analysis is carried out by the business. IT still helps, but the involvement of the business side is significantly higher.

And here the problems begin, because it turns out that Agile has not been fully "implemented" in business and the business side is not aware of the benefits, risks, and potential problems associated with Agile. In particular:
  • The business side is not fully aware that the burden of analysis rests on it and most importantly prioritizing of what will be done through the project
  • Since never before, no one asked the business side how an application should be made, and now suddenly business side can decide, it begins to decide, and generates many changes focusing mostly on non-essential additions instead of the most important elements of the new product
  • Because the conditions around the business change frequently, the backlog changes often, and thus the direction of application development is altered. In moments of panic, the business owner pushes another "critical" functionality into the current sprint or even adds new features during the sprint.
  • Sometimes the business prerequisites necessary to perform IT tasks in a sprint are not ready before the sprint starts and the project team gets them only a few days before the end of the sprint.
  • A business owner without experience or proper training is not able to correctly set the priority list for tasks, allowing to deliver a working project on time by focusing on the essential elements only.
  • The organization as a whole is not yet ready for agile projects and does not give the business owner sufficient autonomy. As a result, having no other choice, the business owner is under pressure and adopts more and more insignificant changes coming from project stakeholders.

It is clear that the business side has a difficult position here. In the case of Agile, all these activities require much more time from the business than with the traditional approach. The role of the business owner is much more important here. An organization that wants to act agile must be prepared to delegate 100% of the business owners time to the project, instead of adding the project as an additional element to current tasks.
It is one of the fundamental problems that arise in organizations that are starting to use agile methodologies because it requires changing the approach and communication of business with IT and acquiring the necessary competencies on the business side. What's more, it is often necessary to make further changes in the organization, such as developing project management competences on the business side.

If we go further and want to provide software on a continuous basis - using DevOps, Continues Integration and Continues delivery, allowing for even greater agility, the organization must change even more (this time more on the IT side). Thus, Agile initiates a whole series of far-reaching changes in the organization, which implementers are often not aware of at the beginning of the journey towards Agile.

If for some reason we stop our walk to agility halfway, we will not be able to take advantage of its benefits even though we will bear its costs. That is why Agile is more of a business philosophy that ultimately covers a significant part of the organization and goes far beyond IT. Well implemented Agile can significantly accelerate the implementation of some IT solutions. It should also be clearly emphasized that the delivery of some projects will still be more effective using standard methodologies.

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 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