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.
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.
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:
Post a Comment