6 Steps from Awareness to Implementation Success - Step 4: Preparing Environments and Business for Go-Live

From this article, you will learn:

1. What are the most common mistakes between implementation analysis and go-live?
2. How to properly define processes before production start?
3. Why is team stability crucial for implementation?
4. Does each "station" in implementation look the same?
5. What are the main causes of implementation failures?
6. How to prevent ERP system overload and optimize processes?
7. How do cross-functional tests influence implementation success?
8. Who is the Solution Architect and why is their role key?
9. How to ensure the technical quality of implementation?
10. How to avoid mistakes before go-live?

We are in phase two – preparing the system based on the approved analysis document.

In most cases, such a document can be described in two words: comprehensive and individualized.

Business analysts try to record every word from the client during meetings, while the client describes their domain without distinguishing between past and future. If we multiply the number of business areas by the volume of written text, in many cases, we would surpass the length of the Gutenberg Bible.

For some, this is an achievement; for others—volumes of knowledge impossible to absorb.

If we conducted a survey among those who have read Nad Niemnem by Eliza Orzeszkowa, most would remember the fate of the main characters, but only a few would focus on the nature descriptions. Orzeszkowa was fascinated by botany from childhood—she included as many as 460 different plant species in Nad Niemnem.

Each of us perceives the world differently, whether we are a service provider or a recipient.

The document should be clear and understandable for a consultant, Project Manager, architect, and developer alike.

Project definition – Process, Element, Action

Let’s observe and document the client’s world from the perspective of processes, elements, and actions.

The product of the number of processes, their elements, and actions within these processes determines the implementation schedule. The larger the calculated value, the bigger the project.

If we treat a process like a metro line, we can use analogies to different cities:

• 3 processes – Prague
• 11 processes – London
• 16 processes – Paris
• 27 processes – New York

A sample business process in an IT system could be placing an order with a supplier in China, with the final stage being the recording of all fees and obligations towards the foreign supplier, customs office, and tax authorities.

The elements of this process include:

• Sending the order from the system to the supplier
• Recording the product's movement across land, sea, and ports
• The physical acceptance of goods into the designated warehouse location

Each element of the process requires recording specific actions. For example, in the product acceptance process, the actions include:

• Determining the cargo arrival date
• Unloading goods at the ramp
• Labeling and distributing goods within warehouse locations

This process can be compared to London's Victoria Line, which has 16 stations, with transfer options at nearly every station.

Transport for London – Implementation Teams

Each project has a sponsor who funds the implementation of a new system by making payments to the provider. The responsibility for the proper execution of the project on the provider’s side rests on the shoulders of the Project Manager (PM). Large-scale initiatives cannot be managed by just two people, which is why implementation teams are formed. In the previous section, I introduced the fundamental characteristics of such teams and the key principles they should follow during the analysis phase.

If we compare this to the London Underground, the sponsor would be the Mayor of London, while the implementation team would be the executive agency, Transport for London. At the head of the team stands a person appointed by the board, referred to in the project as the Project Manager (PM). Their task is to oversee the team and implement the plan described in the analysis document. Every PM must stick to the schedule to ensure that the launch of individual transport hubs occurs without delays, as punctuality is the core feature of effective communication.

The Station

Each team is built based on area-specific competencies. Team members include consultants responsible for finance, production, projects, resources, and service. They work closely with developers and system administrators. Each of them is accountable for their designated area in the system, essentially building their own "metro station."

Depending on competencies, the final appearance and functionality of a given station often deviate from the assumptions outlined in the project (analysis). Unfortunately, this is one of the key challenges affecting the planned launch of a major project, such as the start of the metro.

What factors determine failure?

An improperly assembled team can lead to issues that affect the timely launch of the project. One of the most common mistakes is the lack of an experienced leader who can effectively manage their subordinates. Another critical issue is excessive team turnover, both on the provider’s and the client’s side. Staff stability is crucial for a successful implementation.

Always ensure that every newly built station has an experienced leader who consciously manages the team. Many companies showcase their best, most experienced employees during presentations and analytical discussions. However, we must demand team consistency throughout the entire implementation process. Accountability should not be diluted during project execution. If someone participates in discussions, analysis, and design, they should also take part in development and the final production launch.

Excessive turnover among teams building metro stations leads to higher costs and extended project timelines.

Consistency matters

The second crucial factor is the consistency of the constructed elements. Every metro station should look and function similarly. A lack of uniform standards can cause delays in transportation and increase maintenance costs.

When passengers purchase a ticket, they should not waste time deciphering a set of unique rules specific to each station. Very few people are interested in wall murals or changing color schemes and lighting. We enter the metro to easily reach our destination as quickly as possible.

Often, our ambition drives us to make "our" station stand out. However, a lack of consistency in design later leads to transportation delays and increased operational costs.

We should design solutions that are always aligned with other system areas. Avoid unnecessary elements that could negatively impact overall system performance. Every additional line of code can generate significant costs when updating and modifying the system.

Design and implement elements in a way that data flows efficiently throughout the process without disrupting other system operations.

Wagon

In the context of passenger transportation, it is crucial to optimize the use of transport units. Solutions should be designed in a way that allows for easy management of the number of carriages in passenger trains.

Improperly designed processes can lead to system overloads. An excessive number of carriages in a train causes a slowdown in transportation, which results in longer travel times across the entire route. Consequently, passengers experience delays, and the transport organization incurs budgetary losses. In information systems, similar errors can cause bottlenecks in batch processes. Overloading one area negatively affects the entire system. It is important to design processes in a way that allows data to flow smoothly without disrupting other functionalities. Suboptimal code can create a snowball effect, meaning the increase in travel time not only affects that particular line but also extends the travel time for passengers using multiple metro lines. A dissatisfied passenger means losses for Transport for London—not only in terms of reputation but also financially, due to passenger attrition and increased energy consumption for inefficient transport.

We should design systems so that the product's journey within the system is as short as possible, while also providing essential data for controlling price and cost optimization. In systems, the efficient operation of batch processing tasks is of fundamental importance. We should choose the number of carriages in a way that makes the process predictable in terms of determining the start and end of a trip. A large amount of collected data may cause delays in the system when accounting for retail trade reports, which would directly lead to delays or empty runs in the sales settlement area, ultimately preventing the accounting of returns and adjustments.

Lines

What does a metro line represent in the context of a project implementation?

A metro line symbolizes the entire business process, while individual stations represent its constituent elements. Stops, train departures, and passenger boarding and alighting serve as analogies to the various activities carried out within the process. During the construction of a new system, errors often arise from misinterpreting processes. Implementation teams mistakenly perceive their scope of work as independent, leading to a lack of integration between different areas. A holistic approach is necessary, taking into account the connections between processes and their impact on the entire organization.

Translating this to a system, the process could be placing an order with a supplier, all the way to the accounting registration of an invoice and settling the liability with the supplier. The process elements include the physical receipt of goods with a goods receipt note (GRN), payment for the purchased goods, etc. The activities involve receiving the delivery at the warehouse terminal, taking the goods from the ramp, and transporting the pallet to the appropriate warehouse location using a forklift.

How is the process perceived by the implementation team during the construction of a new system? Are there any errors in this area?

The answer to this question is related to the previously discussed description of the stations, which corresponds to the area of expertise. Each team member is responsible for their part of the process, builds solutions, and thus creates the communication artery, i.e., the tracks and stations. A fundamental error during internal meetings is the use of phrases like: “Present your process,” “My process starts at... and ends at...”. However, this is not a process, but rather a part of the process. Incorrect phrasing regarding the completeness of what we do causes us not to consider the impact of our solutions on the work of others in the team. For instance, someone designing solutions in the purchasing or warehouse area does not think about how their work might affect discrepancies between the warehouse and financial areas. Similarly, a person designing the VAT margin invoice in the financial area focuses on the layout of the VAT invoice. They precisely define all elements of the document as required by the Ministry of Finance regulations. After finishing their work, they are satisfied with it and announce that their process is complete.

But is the customer’s business process really safe with this approach?

If we relate this to a metro line, we can talk about the section from the “London City Airport” station to the “Star Lane” station, which includes 4 stops. The designer, with the sense of having completed their work because their process has finished, does not realize that the next station is a transfer station, “West Ham,” where several lines intersect. In process terms, these could be processes responsible for determining warehouse valuation, recalculating, and closing the warehouse. These three processes significantly affect the final outcome and the correctness of the data on the meticulously designed and executed invoice. I warn against errors resulting from an improper approach to defining the process. In our case, the collision of three values: the average weighted warehouse valuation, recalculation and adjustment of the warehouse transaction, and the warehouse closing process can result in fluctuating VAT values. The key to success is the correct definition of the process, the process element, and the activity.

Communication

Effective communication is crucial both at the process level and within the team. If the process definition is too general, implementation teams are unable to predict the consequences of problems arising in their areas. Poorly designed solutions can lead to bottlenecks or even derail the entire system.

If data is not processed correctly at one stage, it can affect all subsequent stages of the implementation. The cost of fixing errors is high, which is why it is crucial to conduct thorough inter-area tests before the system goes live.

If we define a process too superficially, we won’t be able to warn team members about the potential consequences of issues that arise in our area. A poor process definition also leads to a wrong interpretation of the information received from other team members. If I am not aware of the impact of my work on others, it could halt the entire process. The metro between my stations will run smoothly because I have designed "modern and unique" tracks. While the word "modern" may seem harmless at first glance, the word "unique" presents a huge risk. If we focus only on our part of the process and not the entire process, we can cause the process to stop or derail the entire train. In the latter, more drastic case, we will need costly repair tools. In systems, millions of data points are moving every minute. Derailing a train on a certain section of the track by designing tracks that are too narrow or too wide will stop the entire line, several lines, or in extreme cases, the entire metro system.

Remember that if errors appear in the system, we are dealing with two elements: unblocking processes and data repair. The cost of data repair is significant, considering the employment of a specialist or a team knowledgeable in the topology of the deployed system.

To avoid the aforementioned errors, I recommend organizing inter-area tests when delivering functionalities. If we are implementing a new solution in the system, let’s verify that its impact on the data and the functioning of other areas of the same process remains unchanged throughout the entire process. Inter-area testing is an element that guarantees implementation success. I cannot imagine this task not being included in the implementation schedule. Tests of all processes, i.e., all metro lines, should be performed both by the implementing company and the service receiver. Let’s ride every metro line, get off at each station, perform all the tasks, and then board the train heading toward the next station. If our transport takes us to the final station, we can say that the entire process is working correctly. Later, let’s look at the controlling data, analyze the travel time from station "A" to the final station "Z." Let’s conduct a detailed analysis of each element and task within each metro line. If the results are not optimal, let’s make adjustments and then take another trip from station to station. If at this point we are satisfied with the travel conditions and are achieving the goals set in the metro project, then we can confidently announce the go-live date.

Do all implementation companies and service receivers perform inter-area testing?

Unfortunately, no. Moreover, this point is not even included in the offer or schedule, as it significantly increases the time commitment of both parties, which translates into the cost of implementation. Companies usually postpone this point until the production start, testing the process under heightened stress.

The Metro

Is the Project Manager the most important person during the construction of the metro?

No. Their role is to manage the schedule and organize the work. The Project Manager neutralizes all problems that affect the project schedule. If there are material or personnel shortages on a particular line, their task is to fill the identified gaps. The Project Manager works closely with the designer, the architect of the entire metro system. The architect has extensive technical knowledge and is responsible for developing projects for new facilities and for the reconstruction, modernization, and adaptation of existing ones. They must also oversee the execution of projects. No phase of construction should proceed without their approval. They are the technical expert and act as the translator of the project's progress and status for the PM.

In the IT system implementation process, this role is taken by the Solution Architect, who is the most important figure. The Solution Architect has knowledge of the entire system – from finance to logistics, production, and services. Their task is to ensure the coherence of the implementation and supervise compliance with the project assumptions. During the implementation phase, they must monitor the quality of the implementation and eliminate potential issues before they affect the entire process. It is always important to ensure that the implementation team includes a Solution Architect who will be fully available and have the appropriate competencies.

During the prototype presentation, the Solution Architect outlines the vision for the construction of a specified number of metro lines, the optimal number of stations, and transfer nodes. They present how passengers move from the entrance gate to the metro, through stations, transfer nodes, and ending at the exit gates. In the second phase, i.e., the execution and implementation phase, they are responsible for realizing the presented design. They individually monitor the process 24/7, ensuring the coherence of processes. No deviations from the plan should occur without their approval. One of their tasks is to provide technical feedback to the Project Manager based on information from team members and the actual state of the project. They separate irrelevant information from key data needed for the implementation schedule. In simple terms, they are the protector, safeguarding the Project Manager from making erroneous decisions regarding the project. Always check if the Solution Architect is mentioned when introducing the implementation team.

Another critical element to prevent turbulence in the project is verifying the Solution Architect's availability and their competencies. Companies often confuse this role with area leads, leading to a lack of a comprehensive view of the entire system. Insufficient knowledge in this area causes teams to focus on individual elements instead of the entire process. We build stations and segments of the metro lines, but not entire lines. Solution Architects are well-compensated, which is why companies often assign them to multiple projects simultaneously. Some companies even push these limits, adding extra stress to sales tasks, including a Pre-Sales role. The Project Manager then takes on the responsibility of communicating with the construction managers for individual segments and metro lines. This causes a problem because the Project Manager is not technically versed. Without a technical controller, the team may provide inconsistent information, leading to increased costs and schedule changes. We could consider whether someone building metro systems in London, Paris, Prague, and additionally working on sales for a new metro system in Krakow can guarantee us quality.

Timetable

Before launching the metro, it is essential to establish an optimal schedule. In IT projects, this task is handled by the Technical Architect, who collaborates with the Solution Architect, developers, and project managers. The Technical Architect is responsible for the technical implementation of the system and code optimization. Their mistakes can lead to extended testing, increased costs, and delayed production start. Therefore, it is crucial to ensure their full availability and oversight during the implementation phase.

Let’s ensure that during the system implementation phase and the preparation for the production start, we have full control over the quality of the implementation and the stability of the project team. This will help us avoid problems and guarantee the success of the entire venture.

Unfortunately, similar errors are made in projects regarding the Technical Architect, as I previously mentioned with the Solution Architect. Well-compensated Technical Architects are often assigned to various projects simultaneously, causing the technical control of individual construction segments to be neglected. Non-optimal or erroneous code increases the costs of testing and requires repeated fixes. Again, this causes a rise in the project budget or even delays the production start. Let’s ensure that during the second phase of implementation, system preparation, and organizational readiness for production, we have 100% access to both the Solution Architect and the Technical Architect with the necessary competencies for their roles.

In the fifth part of the series "6 Steps from Awareness to Implementation Success," I will discuss how to avoid errors during the system’s production start.