GDPR Compliance: I am not collecting any personal information of any reader of or visitor to this blog. I am using Blogger, provided by Google to host this blog. I understand that Google is using cookies to collect personal information for its Analytics and Adsense applications. I trust that (but has no way to verify) Google has incorporated the necessary data protection features in their applications

30 October 2013

The Failed Project...

No one likes a failure. Especially me when it comes to ERP / Business Solution Implementation. I take justifiable pride in more than 20 odd successful ERP implementations that I have been a part of and a good number of customers who are very happy that I was a part of ERP Implementation in their company. I take pride in my Business Knowledge, my process knowledge and my implementation expertise.  

I could fail in other endeavours (I can give you a number of examples) but when it comes to ERP Implementation, I am good.

That is why my first failure as a Project Manager hurt like crazy. 

I tell you, it hurts. Being a part of a failed project, that is. You personally feel the pain and suffering of the customer users, you feel the stress undergone by people who trusted you and put their faith in your expertise, you feel the hurt of having letdown yourself.

Even if you know that you are not at fault, you feel pain and remorse.

Let me tell you what happened.

This project was to manage the implementation of CRM Solutions for a customer. I had an excellent relation with this customer. My relation had started off as a small engagement and continued on to a bigger engagement. Both these engagements were in the area of ERP, which was my expert area. Both of these projects were very successful and I received 5/5 rating for my effort in both these engagement.

The second engagement was a long term complex engagement. It started off in 2008 and completed in 2010 and like I mentioned above, I got very good rating from the customer.

Based on the work that I had done in the area of ERP, our company received an offer to implement CRM Solutions for this company. CRM is not my area of expertise. However, I already had a work permit to work in this country and a since a work permit is expensive, I was asked to take ownership of this project. Even though I was in the middle of my second engagement, I accepted the challenge to manage this project also.

That was my first mistake.

The second mistake was in not having a good oversight of the work of my team. There are very few CRM implementers in the world. There are many consultants who know the CRM Application. However consultants who conceptually know the marketing functions and who can map the concepts to the application are few and far between.

In addition, CRM implementation is expensive and not a 'Necessary' solution for a customer. Hence many customers do not opt for CRM Solutions. So a consultant has very few opportunities to become a part of a CRM implementation. Many consultants do ‘patch up’ work, creating reports and resolving bugs. This means that a consultant who knows CRM application and who has implemented this in a customer site is even scarcer...

So a typical consultant is having no conceptual knowledge, no implementation experience at an actual customer site and do not have a conceptual understanding of the Sales and Marketing function in an organization, which CRM tries to implement.

Sure recipe for disaster, won't you say?

Just because of their knowledge of CRM Application and because of the high demand of CRM solution for the customers, these consultants will always be in demand. Half baked knowledge coupled with high demand for that knowledge is the sure fire cause of arrogance. Many of the consultants in India (whom I have interacted with) are arrogant, and this adds to the problems for the Project Manager.

This was my team.

It was not that our organization was not aware of the risk. The arrogance of the CRM consultants was known widely in our organization. But, we have to manage with what we have and I had to manage with the hand that I was given.

As the project progressed, it was clear that it was not going fine. There was communication failure among the team. Ours was a small organization and I had joined newly in the Organization. Some of the consultants in my team were known to the CEO of our company and my CEO used to directly communicate with this consultant bypassing me and thereby weakening my role.

Plus, there were all these resignation. Just like a ripe mango falling off a tree, CRM Consultants from my company started leaving in droves. It wasn't that my company was not good. It had a reputation in the market for quality. However, these consultants were in demand and market was ready to pay 100 % premium for some of them.

It was just a coincidence that mine was the only big CRM implementation going on at that time and hence some good people from my team left in the middle of the project. 

In addition there was question of professionalism of our team.

Let me give an example.

The organization (where we were implementing) had two applications running. One was the new CRM Application and the other was the existing ERP application. It was important that the data in both applications should be synchronized on a regular basis. The ERP application was the master application and was the source of the data. There was no automatic process to transfer the updated data in ERP Application to the CRM Application.

This is a common problem in any implementation. You need to develop what is known as ‘Interface Scripts’ which will pull data from a source application and update data in the target application. I called a meeting to discuss this.

Here is meeting  No.1.

Customer (CUS): We update the product data in ERP, it has to get updated in CRM Applications. We are ready to do the work. Tell us how we should proceed?

My Team Lead (MTL): There is no direct integration between ERP and CRM. You have to enter the data manually in CRM.

CUS: That is not possible for two reasons. One, every week we update nearly 200 Products in ERP. We cannot enter all the products manually in CRM. Two, even if we manually enter the data, there could be mismatches. We can pull the data in Excel and you have to design a solution to push the data in CRM

MTL: OK, I will look into this...

End of meeting 1

Now for meeting 2, held two weeks later.

CUS: Last meeting we discussed about an interface to push Product Data into CRM. You were supposed to come back to me. We haven’t received any communication from you.

MTL: There is no direct integration between ERP and CRM. You have to enter the data manually in CRM.

CUS: As we discussed in the last meeting, manual update is not possible for two reasons. One, every week we update nearly 200 Products in ERP. We cannot enter all the products manually in CRM. Two, even if we manually enter the data, there could be mismatches. We can pull the data in Excel and you have to design a solution to push the data in CRM

MTL: OK, I will look into this...

This went on for 4 meetings. After which the customer gave up.

You will ask me as to why I continued with this team even when I knew that the team was not good. Remember the point about expensive and time consuming process to get the Work Permits to work in that country? That acted as an ‘Exit Barrier’ for me to remove this team (specifically this team lead).

Over a period of time, it became very clear that the project was going to fail. Some of it was attributed to the lack of competency of the team, but most of it was related to the fact that the CRM product was not capable of handling the level of detail required by the customer.

Finally, after more than 10 months, the customer called off the project. Our company was forced to pay compensation and the project came to a tumultuous end.

I still cringe when thinking of this failed project.

What is the lesson that I learned out of this?

The most important lesson is that in project, as in life, nothing matters other than decision making. As soon as I saw that the project was not going fine, I should have alerted the stakeholders and should have taken a decision to call off the project. I went on escalating till cows came home, but abdicated the responsibility of taking hard decisions. In retrospect, I should have simply informed my customer that we are not able to execute this project and that we need to call it off.

As soon as I found that my team lead was not performing to expectations, I should have asked him to leave, damn the 'exit barrier'. That is another decision that I did not make.

Nothing else matters in the end. Only the decisions that you make matter... 

No comments: