I designed the gear box for this vehicle

Knowing your customer’s business.

I drive around in a Mahindra Scorpio shown here. It gives me unfair advantage on the roads in Bangalore where the right of way is based on the size of the vehicle! Lest you think so, this blog is not about the comforts of Scorpio or the horror called Bangalore traffic.

It so happened, some days back I rode in this SUV with my friend who is a mechanical engineer. As he got down, he looked back at the vehicle for a moment and said “Tell you what, my team designed the gear box for this SUV. Mahindra chose the design from a couple of prototypes we had made. Today, all the Scorpios in the country run on my gear box design.” Otherwise very restrained, my friend had to struggle to hide his sense of pride when he said that.

As you would have guessed, my friend does not work for Mahindra but his organization provides services to them, typically as projects.

This conversation set me into thinking. How many of us in our projects appreciate why the customer has entrusted us with the project? Or how many of us know where the project fits into the proverbial larger picture?

If you ask me, my answer would be “Not many”. Some if not most of, projects run on the classical iron triangle of scope, schedule and cost. The team gets the project with the requirements. It is executed hopefully in schedule and within costs and delivered back to the customer. Then you return to your home team and get reallocated to the next project in line. Taking further liberty, I would like to say that the PM is worried about on-time delivery and the team about sale-ability of the skills acquired through the project. And the twain sometime does not meet.

The basic question is should the project manager and the team know the customer’s business? Is this a nice to know or badly needed piece of information? Probably, the later.

Let me paint a few scenarios.

Is your project a part of mature well proven product? If yes, you can expect clear requirements but the customer would expect quick turn-around time.

Or, may be your project is a part of a brand new product/platform. You can expect uncertainty in requirements. (I am sure my friend in the above story would have faced a lot of this.) Don’t fret over frequent requirement changes.

Or is the customer meeting some legal compliance through your project. Expect very clear requirements but don’t get frustrated by thorough verification with a magnifying glass, almost nitpicking.

So, knowing the larger picture does help you in managing your project better.

If you become invisible and get into some of the project meetings, you will get to hear a lot “we and they” talk (or should I say “us versus them”, anyway). Like “They always change requirements”, “They do not know what they want”, “We are already overworked” etc. If you know the customer’s business, you will have less reason for the “we and they” talk.

I want to end this blog on a philosophical note. Inherent in the human heart is the desire to be of some use to somebody and to leave a legacy behind. Knowing the customer’s business fulfills this desire. Like “thousands of vehicles ply on the bridge that I worked on” or “every time you talk on this phone, my compression software kicks in”.  How do these statements compare with “we completed the project within 10% schedule variance but got beaten on cost escalation of 50%”?

Need I say more.  As usual, eager to hear your views and experiences. You could also vote at http://polls.linkedin.com/poll-results/95180/gamah.