Saturday, May 9, 2009

Project Separation

Similar to how things are in many cases in the industry right now, our company, which is a captive center, lost another account. The client account, an insurance company based out of Singapore, which recently was sold out of the parent corporate company, decided to get its systems supported from another company in Beijing.

Though a lot of reasons are attributed towards this decision, which was so suddenly announced, I can surely tell one thing with a lot of confidence – the decision was not based on any poor performance from our side. There were no loose ends in any delivery or in quality and the managers and stakeholders were clearly pleased and satisfied with the services.

There were corporate political reasons beyond the control of the managers at the client side and the shift happened. Now came the phase – project separation. This was a new experience for me. As an individual many times, I have moved around different projects and twice totally different companies. But never have I been a part of an account getting shifted. So after having been done with wo9rrying about what was coming next, a part of me was just curious and excited to see how this whole separation thing goes through; and it sure had a lot of comical moments.

Our delivery manager called upon a meeting to announce this to much of all our surprise.
MOM and takeaways after the meeting:
1. Singapore client is gone. (What the …? Really?)
2. They are shifting their projects to a company in Beijing, China (Yeah, All I care…)
3. We would need to do a knowledge transfer to this Chinese firm (Oh shit!)
4. The shift is only due to the corporate decision at the client end, not us. (Hmmm…)
5. And don’t worry, there are some projects in the pipeline, so you will all be settled soon (Lets see about that)

We came out talking to each other, as usual, making jokes to hide our surprise. In a subsequent meeting, the plan was revealed:

1. People from the Chinese vendor are already at the Singapore office and are receiving KT.
2. The coming week they would be at our office and would require us to do an extensive knowledge transfer and training session for 2 weeks.
3. During this 2 weeks, any production issue, would be primarily supported by us and the new vendor would be secondary support
4. The 2 weeks after that, we would go to secondary support mode and they would be providing primary support.

The plan looked okay to us, given the fact that we were never given any training on the systems and had to work our way up. Also, I strongly believe that any team with some decent technical background can easily support the current client applications.

We were now preparing for the KT. The stakeholders from the client end had prepared a reasonable schedule and we reviewed it. After highlighting a few points we accepted that. Things looked fine till now, but soon turned around.

A couple days before the scheduled arrival of the team from the new vendor, we were called upon and instructed NOT to give a good KT. We were advised to even misguide them. It appeared so stupid to me and a few others. Why should we do such a thing? And when we asked, the answer given was that this is a waste of time. If we were training a resource within our company then it makes sense, but why should we train someone else?

That was OUR next question, why should we?, if we are not going to do a good job? After all we are still going to be in the same business aren’t we? There are very good chances for us to cross path in the future. It is sheer foolishness to burn bridges.

While this was going through, there came another instruction to be extremely pessimistic in our estimations. While it makes sense to give out estimates with some extra buffer, there was one really simple task that was estimated at 20 man days! It would have hardly taken a developer 4 hrs to complete the work. All right, I agree that we have to be cautious; maybe we could add some buffer for that. But even then, how can one explain the 20 man days thing? 

And when I asked the manager, who proposed this oversized estimate about this, he simply kept telling that this is a task that could cause a lot of other impacts and hence needs a lot of analysis. What the hell? I wonder what these sudden impacts would be which pops up just now and not till just the day before until when we had taken up similar tasks and completed even without sending an estimate.

I just could not avoid arguing with him on this one until I got a convincing answer. Now come on – I am not an all innocent, never utter a lie kind of prick; but certainly I would need myself to be able to defend the situation. And when we send such an estimate to a client whom, btw, we have meticulously trained on getting his ass kissed with each project, shit is bound to hit the ceiling, for sure!

And on top of all this, if we tell him the reason for the high estimate, which is as flimsy as a wet toilet paper, it certainly is not going to be taken well. The counter argument is that after all he is a client whom we have already lost, what is there to gain, why should we impress? 
I don’t want to please or impress him, but what about our dignity of work? Okay, forget the dignity shit, what if we get to a point where we may need to work with him again?

After all this gawky behaviour by my immediate manager and some people above him, I realized that such client separations are not new just to me, it was totally new to them too.

I really hate it when managers take some instructions too wrongly into their heads and overdo and overreact. Maybe I am wrong in my thoughts, maybe I should learn to be as dumb and unreasonable as this moronic manager I am working with. I am curious to know how such project closures are handled elsewhere...

No comments: