Multinational Software Deployment

Purpose And Scope

Technical Purpose

The technical purpose of software implementation is to complete the installation of the software in as little time as possible without disrupting the business and staying within budget. Another related purpose is that the software correctly reflects the business rules and policies that control the company’s operation in each location. This is a very tall order. Let’s give an example of a policy. In one Southeast Asian country a package was going to be installed. Before installation, the features of the package were presented to the local management. A key capability of the software package was control. Nothing could be shipped to a customer unless there a signed order was received. A local manager indicated that for valuable, long-time customers they shipped based on a telephone call or fax because of the long-standing relationship. The presenters said that this could not be accommodated. Therefore, they would have to change their local policy. The local manager indicated that they would lose business. He was overridden. When the software was installed, customers started to leave; they refused to fit in with the process imposed by the system. Desperate to keep the company going, the local managers reverted to the old process. They then had a clerk input the data after the fact into the ERP. The result worked, but there were no benefits for the local office—only additional work and pain.

Business Purpose

From a business perspective, the goal is to achieve new, effective business processes and standardization through the installation of the software. The thinking is that it is too hard, if not impossible, to manually control work in remote countries overseas. So if they are using the same system for the standard processes, the software will act to enforce standardization.

This is the correct business purpose. However, it often is not achieved because the implementation is ended almost immediately after the software is installed. There is no follow-up or measurement, and insufficient attention to business process change to mesh the local culture and business rules to those expected and imposed by the software.

Political Purpose

Many firms make the mistake of not having any political purpose; they are satisfied with the technical and business purposes outlined above. It is in these situations where the most problems occur. There are a number of useful political goals, including:

Build a better understanding at headquarters about operations out in the field.
Identify clearly the areas where the local rules and factors must be followed. There is some flexibility in that not every local business rule has to be slavishly adopted.
Create a collaborative environment for the project that will increase communications among locations.
Support simplification in business processes across the organization, including headquarters.

Scope

Scope is an interesting subject. This can be narrow or broad. Narrow scope consists of the software itself. Broad scope might include the software, business processes, policies, and organization structure. Something in the middle would delete the organization from the scope. This middle ground is the most successful.

However, there are factors that get in the way and impact the scope as the project progresses. The two key factors are time and money. Tasks take longer to do. People have to perform their normal tasks as well as work on the software implementation. The budget soars as more consultants climb on board. Together these act to narrow the scope to the software.

End Products

The major end product is the software installed, working, and being used effectively as part of improved business processes. Scaled back it might be the software working, but the local business processes are warped and adapted to the software in an ad hoc manner.

Another end product is improved information at headquarters, regions, and countries on a more timely and predictable basis. These are real benefits as well as end products. Why aren’t they commonly achieved? Because no one is dedicated to using the information in a structured manner so that much of it goes unused. Another reason is that IT support is required to gain access and manipulate the information.

Issues

Issue: There Is A Lack Of Sensitivity To The Culture Factors In Specific Countries

This issue was mentioned, but not addressed. A common thread through the book has been the cultural factors among countries and even parts of a country. Here the issue is applied to software implementation.

Impact

Culture anywhere in the world dictates how you do business and make money. It affects how you interact with customers and suppliers. While there has been some common adoption of some “Western” ways, there remain local nuances and mores. Culture affects the business rules. If the business rules of the software package don’t match up or cannot be reconciled, then there are bound to be problems. Something has to give—either the package fails or the business is affected.

Prevention

The best prevention is to understand the culture and business rules in each location at the start. This is a very tall order so let’s simplify it. You should identify about 10–20 critical transactions that would be covered by a new system. Then you should examine how these are carried out in each country in detail using the methods from Chapter 2.

Action

You will begin to detect problems when business rules and exceptions start appearing. People will ask “How will the system handle such-and-such a transaction?” When they get an answer, look at their reaction. If they are quiet and don’t anything else, you know that there is a problem. They won’t discuss it where they are dominated by others. When the problem arises, then you should lower the effort in the software implementation and go back to the transactions and perform analysis.

Issue: The Software Was Purchased; However, It Cannot Handle The Regulatory Requirements In Certain Countries Despite The Vendor Claims

If you are a software provider and you find that you can sell your product in a particular country to several firms, it will be tempting to the marketing staff to indicate that it will work well in the country. However, this may only be for a few industries—not general. Marketing makes the claims that the customer believes and then there are problems.

Impact

Typically, since the software cannot be rebuilt, there are two recourses. One is that you create a workaround using software tables and procedures. Another approach is to create a “shadow system.” This can serve as either a front or back end to the system.

Prevention

You really have to evaluate the software more fully during the evaluation work. The true test is to send specific transactions through the system. If the vendor is unwilling or unable to do this, then you will have to resort to having them explain how the transaction would work.

Action

If you did not take preventive action, you are likely to find out about this problem when you are winding up the project in testing. Then suddenly, the crisis hits. Before starting to fix a problem at a time, the best approach is to do an overall assessment to determine how much of the work and transactions are affected.

Issue: A Large Number Of Key Personnel May Be Tied Up In This Project For Months

Guidelines for personnel and team members were given in Chapter 4. Recall that you want to have junior people who have energy on the project. Here, the point is that you require senior people with detailed knowledge of the business rules. This is true, but you don’t need them all of the time.

Impact

If the critical “king bees” and “queen bees” are taken out of a department, the remaining employees may feel lost. They may not know how to handle certain pieces of work. The employees go to the supervisor or manager who now feels put out that they are coming to her/him. After all, they may not be familiar with that work either. As you can see, the impact can be dramatic and long-lasting. When the senior person returns from the project, he/she is inundated with work. Then back to the project again. They become burned out.

Prevention

The best method for preventing this situation is to involve junior people heavily from the department. Then only pull the senior people in when you require specific business rules. You can measure yourself by seeing the mixture of people and total hours in the project.

Action

If you find that you are becoming overdependent upon senior employees and they are on the project all of the time, then you have to look not at this, but at the reasons why you need the senior employees. What is so arcane and technical? Remember that the package will not be modified. If the senior people are on the project too much, then it is a sign that there may be too much attention to exceptions, workarounds, and shadow systems. Don’t assume that this is real productive work. If you get sucked into these exceptions, you may never get out!

Issue: The Software Does Not Interface Easily With Several Critical Legacy Systems

Software interfaces are a curse of the industry and have been for over 40 years despite all efforts at standardization through EDI (electronic data interchange) and XML (extensible markup language). You could write a whole library of books on this issue. In brief here are some of the problems. Software gets written at different times using slightly different techniques and technology. This makes interfaces more technically difficult. Now programmers come and go so that over 15–20 years (the average life of much of the software out there in operation), the software programs resemble a puzzle—lack of documentation and difficult to understand. Also, hard to make changes. These are just a few of the reasons why interfacing to older, legacy systems is difficult. Why don’t people just replace these systems? They work so if it is not broken, why fix it? Next, some of the packages are as old as the customized programs.

Impact

The interface is normally extremely critical. Often, the legacy system feeds the new software package so that it must have the information. Because of the time required to do the interface, it is often on the critical path of the project. Many times it will be delayed—really impacting the project.

Prevention

There is no way to prevent the interface. It must be started early and must be given a high priority by the senior programmers. Anything that can be done to simplify the interface should be evaluated during the design.

Action

If the interface part of the project is suffering, then you have to consider setting up a more limited interface for selected transactions. Putting more people on the interface work will often actually slow the work down.

Issue: Headquarters Does Not Provide Sufficient Resources Or Money For The Implementation In Remote Locations

This is a classic issue that we have encountered time and time again. Headquarters expects people in the field to just drop what they are doing and support this as another project—not a good idea. The project leaders at headquarters may not have ever managed a similar project before and are clueless about what is required. If they added on the cost of the staff and managers in the field that will have to support the project, the costs might far outweigh the benefits.

Impact

Local managers will quickly ask what additional resources will be provided to them to do the project. They are often met with vague promises and assurances that there will not be much work. As the local people get sucked into the vortex of the software implementation, then there will be more complaints. Their local work may and likely will suffer. Things will slip. The current processes in the company location will deteriorate—just as they are trying to implement better processes.

Prevention

Planning for the project must be realistic. Also, follow the guidelines of Chapter 5 and use a collaborative approach with the people in the field.

Action

When you start to notice the stress and problems, then you have to step back and determine a more reasonable schedule—if there are no more resources. Instead of slowing everything down, try to implement a module or part of the system.

Issue: The Consultant Selected For Supporting The Implementation Of The Software Does Not Have Personnel in Some Company Locations

Many consulting firms make promises about their international presence. However, what this means sometimes is that when they get business in some country where they really don’t operate, they subcontract out to some local firm. These individuals may not be connected at all with the consulting firm. All of the problems mentioned in Chapter 8 come to the foreground.

Impact

The consulting firm either fills in with local people or flies in expensive outside consultants. In both cases, you lose. The costs will be higher. There will be a steep learning curve that wasn’t planned. The work may not be of consistent quality.

Prevention

The best method of preventing this problem is to follow the guidelines of Chapter 8 and find out what capabilities they have in each country. In addition, ascertain how they manage multiple locations and people being spread among multiple clients.

Action

You have to track the initial work that a consultant does in a country very carefully. You seek to build up a pattern of behavior between the local office and the consultants working there. Then you have to monitor the consulting firm to see whom they are sending into your offices.

Template Areas

Area: Planning

There are a number of critical decisions to make at the start:

How will the software be deployed or rolled out?
Do you opt for one package or several packages from different vendors?
How will you motivate the employees to support this?

There are a number of approaches for rollout. One way is to deploy the whole system in one country. Another approach is to deploy one part of the system in every country. A third approach is to implement different parts of the system in different locations. The first two are the most popular with the first being the most common.

For packages the trend has been to rely on one vendor. The argument is that you are guaranteed of interfaces that work. You have a simpler management relationship in which you can apply pressure on them due to the size of the order. And it is sometimes simpler.

Area: Software And Consultant Acquisition

General consulting guidelines were presented in Chapter 8. Here we point out that there are a variety of different types of consultants that may be needed for the project. For one package there are actually nine different types of consultants. The basic guideline is to define the outside support that you need when you select the software. Otherwise, you could have selected the software and find that there are few consultants available—making your software decision look pretty bad.

Area: Software Implementation

Here the main guideline follows from Chapters 2 and 5 in terms of how you organize the project. You do not want to organize it by country. In software installation what you learn in one place can be extremely valuable in another country. To facilitate and promote collaboration, set up the project across countries.

Area: Data Conversion

Data conversion has been a curse for many for years. Data in older systems is often of poor or uneven quality. There may be a lack of completeness and consistency. There may be problems in the timing as to when the data was captured. The problem grows in complexity when there are multiple systems.

The problems get worse when you consider what the new system requires. There are often many new fields of data. But where will this data come from if it is not in the current systems? Will it all have to be entered manually? Will you add the data as you go? Another problem is that a data element may have the same name in both the old and new systems, but have very different meanings. The lesson learned is to pay attention to data conversion early and to create a separate subproject for this area.

Area: Interfaces

Interfaces were mentioned earlier in this chapter. This is another subproject. The topics that have to be included in the plan include:

Timing of the interface;
Frequency of the interface;
How validation of the interface will be accomplished;
Recovery and restart if the interface fails;
Documentation of the interface;
Roll back if the data is passed, but later is found to be problematic.

Area: Training And Cutover

These subjects sound straightforward. After all, the interfaces, data conversion, and other tasks such as testing were handled. However, you would be amazed at what comes up at the last minute. Some users may raise new exceptions and issues—just to delay the implementation. People may have made assumptions about what business rules were—then they found it changed. Keep tracking issues until the very end.

Lessons Learned

The benefits must be defined and made tangible as to which part of the organization bears the cost of the software and which receives the benefits.

Everyone has heard all of the benefits about new systems. They are easier to use, do away with paper, increase productivity and sales, and reduce costs. However, there is a basic problem—a system cannot do this. A process can. The benefits for systems lie in the business processes in which they are embedded.

Determining the benefits takes several steps. First, you have to define a new business process. In comparing the old and new processes, you obtain the benefits. But will the benefits be realized? You have to dig deeper. Now consider the new system. It is supposed to support the new business process. Will it? Better make sure. You should perform additional analysis to determine if the new system will support the new process. Finally, you want to follow up on the recommendations in Chapters 1, 2, and 10 in conducting reviews of the current and new processes to see if the benefits were achieved.

Remember the approach to benefits. You consider negative benefits as well. That is, you answer the question “What will happen if the new software is not obtained? What will be the impact?” If there is a very old legacy system that is falling apart, then you may have no choice.
Place as much weight on operations, marketing, and other areas as compared to accounting and finance.

One of the problems that occur in implementing a large-scale system is that one user group or business area tends to step in and dominate the project. They steer the project to their own ends. This happened in one organization where accounting took control. The general ledger was installed fine, but marketing, sales, and operations got very little. An entire new project had to be started up to address their needs.
Consider hiring a second consultant to watch over the main consultant involved in implementation support of the software package.

You can easily become over-reliant on a large consulting firm. You may even assign project management responsibilities to them. This is not a very good idea. Once you do this you give up not only control, but also a window into what is really going on in the project. A better approach is to hire a second consulting firm on a very limited basis to monitor and assess the first consulting firm. This will promote healthy disagreements and likely uncover unpleasant situations much more earlier—better for you!

Use the implementation as a means to gather more information on how business is done in different locations.

Repeatedly, we have stressed how you want to piggyback on an international project. On this type of project you want to use the project to review and assess how the organization is performing their work.

Summary

As you have seen, the methods apply easily to multinational software implementations. This type of project is of high risk and has many issues because it involves the core business processes in each location where the company either makes or loses money.

Super Business - Project Management Articles

Multinational Software Deployment

Impact

Prevention

Action

Impact

Prevention

Action

Impact

Prevention

Action

Impact

Prevention

Action

Impact

Prevention

Action

Impact

Prevention

Action