Knowledge base
How to have an IT system implemented.

How to have an IT system implemented.

31.03.2017

Piotr Ukowski

I realize that an article under this title, written by an IT company representative, immediately sounds suspicious. That's right, I am a party in the processes of implementing information systems. So can I be objective? Probably not quite, though I will try. The following text should not be treated as a recipe for everything, but I think it is worth getting acquainted with it and enriching your knowledge with another (business-oriented, not technologically-oriented) voice of a practitioner. The title of the article intentionally ends with a full stop; I assumed that I would try to provide answers, not questions. I also used the perfective tense, because implemented is a bit harder than implementing.

Let’s start with the fundamental question: what is IT system implementation? Before I give my definition, I will write about what implementation is not for me:

According to Polish version in Wikipedia: “System implementation – a stage of the system’s life cycle, consisting of the installation and customization of software to user requirements, data migration, as well as testing and launching the IT system.”

From a technical point of view, this definition is correct; however, in my opinion, it is wrong from the business point of view. Implementation is not about launching the system, it is about the benefits from this launch.

IT system implementation is changing an organization using this system.

Of course, a change for the better is assumed. The above sentence will serve as a motto and reference point to the entire text.

First: the goal

Before there is the supplier, the consultant, the auditor, it is worth (and necessary) answering the question of why we want to implement the IT system. If a company has well-structured processes but it follows them inefficiently, the goal will be to improve workflow. Such a project is relatively simple to define; we know what we do, we want to do it more efficiently. If the goal is to reorganize the operation of the company or its part, the IT system becomes only a small cog in a much broader project.

It also happens that the goal is to earn points in an application for funding another, bigger investment or to “spend money, otherwise we’ll lose it”. OK, such things happen; however, it is worth admitting it at the go before the group of decision makers in the organization and be less surprised that the project, which no one seriously cared about, cannot revolutionize the company’s activities.

The goal may be compared to a lighthouse on the horizon. Sometimes you have to turn, sometimes you have to bypass some obstacle, sometimes you have to even move back but, eventually, you can get back on track.

Therefore, I sincerely encourage you to write down the goal of the project, to define the expected outcome in the best way. And to constantly control the direction of work with respect to this reference point.

Second: the project team

“Let’s choose a professional supplier who will implement the system for us”. In practice, such an approach is sometimes even successful, but it is quite difficult. It is the enterprise that implements the system. The supplier helps, advises, proposes, configures, trains. The supplier does not introduce any organizational changes because they have no authority to do so.

Besides, in most cases, the goals of the customer and the supplier may vary. Just as my and Wikipedia’s definition of implementation vary. For some, it is crucial to deliver, configure, and launch the system, for others to improve business. Of course, both approaches have common parts, but different details can be immensely important.

Therefore, it is necessary to appoint the project team which will be able to deal with the problem in a substantive and manageable manner. The team should be led by the project manager, having a power of attorney for decision-making, an established position in the organization, and support of the decision-makers.

The role of the project manager on the client’s side is of incredible importance. On the one hand, they are the main interface for the supplier; on the other, they motivate, mobilize and coordinate activities within the company.

The goal of the project manager should not be to get the most out of the supplier. The goal of the project manager is to effectively implement the system in the assumed budget and time. And “getting the most out of the supplier” is sometimes a tool for achieving this goal. Based on my experience, I will add that it is rarely effective...

To conclude this point, if a team with a competent and authorized manager is not appointed in the project, success will depend only on luck. And counting on good luck is a poor plan.

Third: the supplier

Before selecting the supplier of the solution, we need to know what we are looking for. The maximum plan is knowing how to solve the organization's problems, the minimum plan is the identification of those problems.

Selection of the supplier is a difficult process. I cannot describe it in such a short text. But I will try to give you a few tips:

  • Identification of problems and definition of implementation goals
  • Formulation of the request for quotation
  • Presentation of solutions of various suppliers
  • Verification of suppliers (references, reference visits, presentation of specific processes on the system)
  • Decision on whether it should be a turnkey project or a more standard solution
  • Negotiations and a good contract

The supplier’s experience is an important added value. Their knowledge of the sector, processes, and issues makes optimum planning and implementation more possible. However, the statement “as a professional company you know best how it should work” is dangerous. IT implementation should not reduce the company's operations to widespread schemes, it cannot offset the individual characteristics and competitive advantages. Therefore, the supplier’s experience is something we need to derive from, be inspired by and expect; however, it is not worth uncritically building on it the scope and manner of implementation in one’s own organization.

Fourth: the contract and budget

The old rule says that “a contract is signed in case of war, not peace”. If everything goes well, it’s basically the table with quotes and a schedule that are important. In the event of problems, the contract must specify:

  • Scope of the project
  • Acceptance procedures
  • Support of possible delays
  • Change and additional costs management
  • Responsibilities of the supplier and the client
  • Schedule and quotes, as well as invoicing and payment policies

In addition, I would like to point out two elements. The first is dragging out the negotiations. If we want to complete the project, say, in 8 months max, and we spend half of that time negotiating the agreement, then we significantly reduce our chance for success. The second is striving to shift the responsibility and risks onto the supplier. Of course, we have to look after our own interests and strive to conclude the best agreement, but a one-sided and unfavorable agreement is usually signed by desperate-suppliers or incompetent ones. Is it really worth collaborating with such suppliers, even based on a great agreement?

Here is another tip. You should set aside an additional budget for changes. Let it be unavailable for the supplier, but let it provide the project manager with means to do more. During IT implementation, something unforeseen always occurs, even with full engagement, professionalism, and great preparation. Even a tight but accepted budget significantly improves work.

Fifth: analysis

Once we know what we want to achieve (the objective), with whom (the project team), using what tool (the supplier), we need to specifically answer the question “how?”. For this purpose, a pre-implementation analysis is used, often conducted based on a separate agreement before signing the implementation agreement.

The analysis will not answer every question, it should not get stuck on the details, especially as during implementation there will be changes anyway. A good pre-implementation analysis:

  • Defines the scope of implementation
  • Determines its stages, schedule and actors
  • Provides a quotation and closed budget
  • Answers the question of how the system will work in specific areas and how the implementation goal will be executed
  • Defines the acceptance criteria
  • Describes the integration interfaces
  • It is created on the basis of analytical meetings with all interested parties both on the customer’s and the supplier’s side

Sixth: communication

Without good communication, there is no smooth implementation. Information channels should be unblocked both within the organization and with the supplier.

The project team must have up-to-date knowledge on the scope and deadlines; the management board must be provided with regular reporting on the progress being made; implementation participants need to know what is expected of them and at what stage; they must also have the possibility to plan their work and submit comments.

The project manager should be in touch with the manager on the supplier’s side throughout the implementation, the key arrangements require written form (e.g. e-mail).

Additionally, it is extremely important to master the flow of information in integration projects when the systems of different authors are linked.

Seventh: division into stages

Implementation of an IT system is not the subject of the enterprise’s activity, it is a means of streamlining this activity. It should not be too burdensome and it should not distract you from running your business.

I am a staunch advocate of step-by-step implementation and system startup. It reduces risks, spreads the users’ training in time, avoids the cumulative deployment burden and possible downtime that are catastrophic for the company’s normal operations, and finally it makes it possible to achieve the first benefits of the implementation at a relatively early stage.

There are also disadvantages: it requires planning. It requires dividing the project into parts which can be (reasonably) run in stages, coordination of works. But it is worth it.

Eighth: change management

I mentioned that change is an inherent part of the implementation project. You can be mad at it, or you can anticipate and plan it. This planning is especially important during:

  • Supplier review – it will let you see their approach to change management
  • Creation of pre-implementation analysis – it will safeguard your interests in unforeseen details
  • Signing of the agreement – it will let you tackle additional costs

Of course, we are talking about relatively minor changes, the introduction of which does not undermine the whole project but aims to attain the goal in a better way.

Big changes will always be expensive. However, the earlier they are diagnosed, the cheaper they are.

Ninth: tests and documentation

On the customer’s side, tests must also be scheduled and conducted on an ongoing basis when accepting subsequent stages of the project. This is not about checking to see if the supplier handed over untested trash, which is verified only by the user during operation. Responsibility for the tests of the system’s correct and consistent operation is of course on the side of the supplier.

However, it is the customer who should check, before production start-up, whether the handed over stage meets their expectations; they should expect a functional description, e.g. in the form of a description of acceptance tests or job instructions (it is important to have this requirement included in the agreement).

It means creating and maintaining two environments – a test environment and a production environment – as well as planning and carrying out acceptance tests.

Tenth: cooperation

It is worth assuming that once we pass the difficult stages of selecting the supplier, negotiations and execution of the agreement, we are playing in one team, whose goal is the efficient completion of implementation. The project’s manager, who understands the supplier and tries to look at the issue from the supplier’s point of view, should not necessary be suspected of acting to the detriment of their own company. A supplier who is flexible in approaching problems and strives, above all, for a good implementation effect, is not necessarily insane.

Implementation of an IT system is very difficult. This will not be changed by advertisements like “ready straight from the box” or “you will start it yourself in a week”. It is difficult but not impossible to achieve. I have a lot of evidence for this.