Relief Pitcher – My experience as an ERP import PM

New and old projects

My last impression of the PM job at my consulting company was as a relief pitcher. Relief pitchers in baseball games are used when the starting pitcher or main pitcher can no longer continue to pitch. No matter whether the current situation is winning or losing, we must find a way not to lose points in the following games and win the game.

In the ERP consulting industry, there are many reasons why the previous PM was unable to continue the current project and needed a relief pitcher. Among the many reasons, there is no reason why I don't want to do this case because I am exhausted mentally and physically. Because every ERP project is an important part of the PM's resume, unless the PM doesn't want to be in this circle anymore, he will still find a way to complete the project no matter how hard it is.

When we encounter more cases where relief pitchers like me are needed, we usually cannot continue to cooperate with the customer, and we usually say that the product is returned. No matter how experienced a PM is, he may be asked by the customer to change PM due to reasons such as ability, incompatibility with the customer, or failure to deliver the project. There are also some cases where the PM is forced to conflict with the customer because he wants to fight for the company's rights and interests when there is a dispute over some vague requirements discussed during the contract signing. In our industry, this is called a sacrifice fight. My rescue case this time is quite special because many system online tests failed to go smoothly and there was no way to go online. The company has replaced three relief pitchers and all have died. I am already the fifth cannon fodder. Because this customer is the benchmark in the industry. The first time I went to a client, the general manager of the company took me there to meet the client.

When I arrived at the client's company, it was the hottest month of August, and the system was not online. Party A (the client) and Party B (our consulting company) had been quarreling for more than two years in order to clarify (pass the buck) responsibilities (project execution usually takes ten months). When the receptionist took the general manager and me into the conference room, I felt that the temperature in a conference room with more than 20 middle- and high-level executives was ten degrees lower than outside. The expression on every senior executive's face is helplessness. "Mom, I have so many things to do. Why do you still need me to attend when the consulting company sent a PM to die?" After I introduced myself enthusiastically, I tried to ask everyone if they had any questions. The supervisors at the venue didn't even turn to look at other people, they just looked at me quietly. At that time, I only had one thought in my mind: "I'm dead."

confidence building

ClientPM

After taking on this project, the first thing I did was to seek support from the client's PM. The client's PM is usually the core person who promotes the project in their company at the beginning, because the project is what she said she would do, so the success or failure of the project is also related to his influence. From a certain perspective, the client PM and I are a community of life. In this project, the client PM is the second person in the IT department, and he is responsible for resource allocation and upward communication. In addition to her, there is also a deputy PM who is responsible for judging project implementation details. Scheduling, issue management, and various reports are what the PM of our consulting company has to do. However, because this deputy PM sister is very familiar with the factory system, she has to judge many technical details.

Because this project has been delayed for too long, the two sisters explained to me the bottlenecks of this project so far in a very structured way. The main problems are unsolved issues of data quality and custom program development. Let’s popularize science here. In fact, any system is an interaction between data and logic. If a set of system data or the operating logic of the data cannot be solved, it cannot be executed. My project is honored to have these two problems at the same time. As an experienced PM, after I got acquainted with my sisters, I also began to ask each project stakeholder about their attitude and personality towards the project. It sounds like gossip, but getting to know everyone involved in the project is the most important job of a PM. Of course, my sisters would also take the initiative to complain to me about all my previous PMs. The conflict between Party A and Party B in this project has not happened overnight. Taiwan's industry was all started by OEM. Everyone is responsible for product quality and does not pay attention to the voice of customers like Japanese companies. The people in Taiwan's consulting companies are all trained in the American system, and they are required to pay attention to the spirit of the contract. However, Taiwan's consulting companies themselves do not write the contracts clearly. So the misunderstanding is getting bigger and bigger. I listened carefully to the complaints of the two sisters. Gaining their trust was the most important step for me to avoid becoming cannon fodder.

Advisory team

After I gained the trust of my sisters. The second thing is to gain the trust of your team. Your team and your customers are equally important. Such a large set of ERP, regardless of the workload and professional skills, is beyond what I can handle as a PM. If the team is willing to work together, I just have to do project management. If the team is unwilling to cooperate or even has internal conflicts, I have to jump in and deal with the technical issues myself. What’s even more terrifying is that if some senior consultants are dissatisfied with the PM, they will spread negative emotions and distrust of the PM like a virus to other team members and even customers (spreading to customers is a professional ethics issue).

In consulting companies, consulting teams are formed on a temporary basis. Kind of like being an airline pilot. As soon as the task is over, everyone is assigned to other projects. Therefore, it stands to reason that the PM cannot evaluate the performance of these consultants.

The advantage of my case is that the team is very united and professional. The disadvantage is that they trust the previous PM. So I have serious doubts about my ability as a newcomer. According to the teachings of some textbooks, the PM should be criticized to establish his own authority. My method is not the same. I mean Xiao Gui and Cao Sui. Since we cooperated well before, we should continue to follow the original communication method.

ERP cases usually have five major modules: FI, CO, MM, PP, and SD. In principle, there will be five main consultants and deputy consultants to perform the work of their modules. In principle, the five chief consultants will be ranked according to their seniority based on their years of experience in the industry. If the two largest consultants have high seniority, the consultant's speech from the CO module will be more weighty, because the most important purpose of the ERP system is to calculate costs. The two pillars of my project are the FI module and the MM module. So I take the opinions of these two as the main opinions of the team. The technical team's attitude towards "whether to obey the PM" is mainly based on the PM's familiarity with ERP. Although I am a coder, my experience in ERP settings is very weak, so in the team I play myself as a bridge to communicate with customers. As for technical professional judgments, unless they seriously deviate from my logic and common sense, I respect the decisions of consultants. That is democratized project management.

Stakeholders (project stakeholders)

After establishing the consensus of your own internal team, you have to return to rebuild the confidence of the customer team. The client's ERP team was also divided into five according to modules, so I asked my PM sister to help me borrow the large conference room that almost froze to death on the first day. Let these users list the questions. After I finish recording, I will ask for details. Generally speaking, users will find repetitive questions very annoying. "Every time a PM is killed, you have to ask me, why don't you ask those fallen soldiers." But I will ask with my love. I don’t just ask how they are doing their current homework; why they are doing it. I will also ask questions from the bottom of my heart, "You have so many orders every day, when will you get off work?" "So when you have to pay the bill at the end of the month, what will you do with the kindergarten?" "You must hold on before the system is introduced. This company cannot live without you." In these seemingly chat-like conversations, I was able to slowly figure out many political or communication reasons why the project could not be implemented. There are many senior PMs or consultants who are too familiar with the technology, so they don't have any empathy when asking questions. In this way, they can only deal with superficial problems without knowing the actual causes. These seemingly insignificant concerns and chats not only let me know the reasons behind many difficult problems in system development; they also allowed me to gain the trust of these users.

It’s not just in meetings that build trust with your team. I write to all my team members almost every two weeks, almost sixty of them. The purpose is to continue to stimulate these members to pay attention to the project like advertising. Let them see this project every Monday when they open the letter.

Of course, this method doesn't work for everyone. For example, this customer's vice president of business is difficult to deal with. In addition to being dissatisfied with the project team, the vice president also had a problem with the factory. I specially took a day to go to the business office to have a meeting with him. I looked for anything in my report that resonated with the vice president. I tried to use topics such as internationalization, informationization, customer relations, etc., but I couldn't see her sympathetic eyes. Until I was about to give up and when the topic of customization came up, I said inadvertently, "I never believe that the same set of ERP can be applied to any company. If every company can use ERP to execute their business, then every company will be the same as my XXX company, so how can our XXX company still be competitive?" Then I noticed that not only did her eyes melt, but she started pouring out all her thoughts. At that time, I secretly thought that I was probably not the fifth cannon fodder.

Project Resistance

The last thing to deal with is the rebel elements within the IT team. Although there are many users who are interested in the new ERP, IT itself will be the most troublesome. The reason why IT is in conflict is because they rely on the original ERP to dominate the company. Once they switch to a new ERP, they have to learn from scratch like a rookie (this concept is actually wrong, the important thing about ERP is the process rather than the program). With my sister's support, I began to require the IT department to write a data checking program after converting the data, so that the data could be ensured to be clean enough before importing the data into the ERP (the proper term is called data cleansing). The leader of the opposition told me on the spot that this kind of program was difficult to write and that he had no time to accompany me to do this (the contract did not say that I would do this). I didn't wait for my sister to scold them for me. I took their data and spent ten minutes in the conference room to write out the main structure of the sample program. I asked the opposition leader, "Even a recent college graduate can write the rest of the program. Do you want me to accompany everyone to continue writing?"

solve problems

I always believe that the most important key to the success of a project lies in people's hearts. But it does not mean that the project will be successful once a trusting relationship is established. The problems left by previous generations of PMs will not miraculously disappear just because they are determined, they still require practical actions.

Document quality

previous generationPMThe first question they left me with was the quality of the project documents. ERP consultants' hourly wages are very high, so customers will also have high requirements for documents delivered by consulting companies. It is different from ordinary files. ERP specifications and education and training documents will accompany the system for ten or twenty years, and even new employees will use this document in the future. So if a document is misleading or even wrong, those errors will linger with the system for twenty years.

The consultants are all so old. Although it is inevitable to make typos, no one will lose face if others point out such low-level mistakes as typos. "Is the client deliberately trying to find fault with me? I have to confirm typos in a document with several thousand words!"

There are many types of PMs. Some strong and authoritarian PMs will tell consultants, "A typo is a typo. I don't care if your document has thousands of words. It is your responsibility to write the words correctly. Do you know your own value?" But my "democratic PM" style was already established when I took on this case. I can't be tough with the consultant. My only solution was to find another person to help me check the errors in the tens of thousands of words document written by several consultants. But how could the company send me such a little secretary?

There is no small secretary, but virtual secretary is not impossible. There are two types of documentation mistakes I've observed consultants make. One is caused by Chinese typos, especially bugs in the computer pinyin input method; the other is the proper nouns of the same system, because they are all in English at the beginning, so everyone's translation of the same word will be different.

After identifying them, establish a 'typographical error and synonym dictionary,' and together with consultants define what constitutes typographical errors and translated words from English. Then let computer programs scan those tens-of-thousand-word files using this dictionary, telling me which files have problematic characters or words in which locations. In this way, what was originally a political issue of file quality between parties A and B becomes a technical problem that I can solve with information technology.

Data Quality

If file quality issues are small obstacles hindering project progress, then the data and customized program problems mentioned later are large mountains obstructing project advancement.

Data is one of the core elements determining project success or failure, and the responsibility for data is clearly stated in contracts as belonging to clients. Therefore, whenever something related to data arises, consultant companies will set up firewalls. Consultant companies treat client data like radioactive materials: clients place their data in designated positions provided by consultant companies, then consultant companies carefully deliver the data into systems. The result is positive if you tell them you failed; negative if they congratulate you. They absolutely never care how clients do it; what methods; or what feelings clients have when creating that data. Consultant companies assume clients provide perfect data as expected in contracts under normal circumstances. If not perfect, clients must take responsibility themselves. This is what consultant companies call 'contract spirit'.

Actually, the concept and technology of Data cleansing existed thirty years ago already, and was also a mandatory course in university information departments. If clients don't understand this set of technologies, just spend some time teaching them this concept. Consultant companies don't necessarily need to really help them write programs themselves. But consultant companies, to ensure no loopholes exist in the 'data responsibility belongs to client' contract clause firewall, won't even want to say such simple knowledge.

I'm not actually trying to avoid becoming another padding/buffer by teaching clients this concept; I only do it because that contract's firewall is hard to hide inside my mind. I genuinely believe if sharing knowledge can solve the current problem, then together with clients we can make projects successful. So I don't just teach them how to write. I also personally help implement some data checking program demonstrations.

In this way, due to significant improvement in data quality, data conversion time was simplified from over one month previously to only needing one and a half days. This solved my first major problem.

Customized Programs

Next comes customized programs. Mainly because there were too many customized programs for this case, with absolutely no budget available to complete the customized programs required by the project.

Generally, packaged ERP programs mainly hope clients use as much of ERP's original functions as possible, not modifying ERP functions due to past habits. But things like client order formats, or report forms required by accounting companies, or automatic posting transactions are difficult because system changes cannot be changed easily. ERP projects find it hard to know beforehand what customized programs clients need before project starts; only after fully understanding client needs can they provide customized pricing for clients. To make clients confident that consultant companies won't suddenly open wide doors for customized programs after project begins, business consultants will also provide hourly quotes from software development engineers (this quote is similar to other industry programming). However, at the end of the blueprint phase, our consultant company's customized program quotes are still far higher than client expectations. One reason is: 'So-called quotes are single price multiplied by hours; I just inflate the hour count.'

Customized programs are also one of consultant companies' important revenues. Our company's ERP uses a computer language different from external ones, so programming development time cannot be compared with other languages used externally (such as Python, Java). Taiwan is such a small island that only other similar-type consultant companies can write in this special computer language. And other similar-type consultant companies are unwilling to accept competitors' customized program development projects. In other words, from the moment of signing this project with my home consultant company, how much money for custom programs is decided by my home consultant company. This is reality.

Two PM colleagues simply couldn't digest this reality, stubbornly using external system development company prices to compare with ERP's development costs. In this way, this contradiction persisted for over one year. Finally, the previous generation of PMs tactfully placed this enterprise collaboration structural problem on my hands.

Unlike data technical problems, this is a cognitive difference issue between parties A and B. To break this deadlock, I need a third-party neutral person to let party A know that ERP program development costs are higher than other programs. I also need to let party B (my own company) know that clients have the capability to choose other methods to solve problems.

The solution lies in another special domain of the industry called 'freelancer'. Translated into Chinese as 'free workers/independent contractors.' These people don't belong to any consultant company. They find programming cases independently through networking to earn profits; generally, they take on cases that are after a few years when clients want to add functions following system implementation (they also don't want to offend consultant companies). But in this case, they can serve as my third-party neutral party.

Of course, consultant companies cannot allow any consultants (especially PMs) to independently find freelancers. From one perspective, if PMs don't let their own company earn profits, that's eating into the company; if Freelancer prices are truly lower, what happens to this lost profit? But a PM's primary duty is to make projects successful; if I fail again, the company also won't receive the original project money.

So, I found freelancers recognized in Taiwan and mainland China. After making greetings, in certain cases I 'accidentally' dropped these freelancers' contact information on the table, where colleagues would 'pick them up.' Colleagues would actively contact these people. Finally, it was indeed proven that our consultant company's prices were still too high. Although I don't particularly welcome external third-party groups collaborating with the company (design and development always have many conflicts), for the project this is a necessary sacrifice.