Project Outsourcing Commandments

Customer is king. Customer decision is final. King's deliverables should be good and on time. There can be many statements validating customers importance. Yes, it is important to drive the point to ensure greater customer satisfaction. But it is equally important for customers to know when and how projects can be turned downside with their own actions/statements.

Few don'ts advice to my customers and prospects will be:

1. Never give a project without internal commitment: Who needs to review, who needs to approve, who needs to be involved, who will pay the invoice, is important to be on board from first time.

2. Never give feedback more than twice on a file: First time, the delivery has all the passion in it. Second time, the feedback on issues seen are considered learning, third time, the moods/mindset and expectations are understood. But from this time on, more feedback will only add to low motivational work. The fixes would be done just to satisfy you, without any passion or brain behind it. If the release is not up to your expectations, send email that you do not consider it as a release at all, and still keep only 2 review cycles.

3. Treat Review cycles with seriousness: Ensure you dedicate time, stop reviews after a optimum batch size(say 25 local issues and/or 5 global issues) in one review cycle, 5-6 localized issues in second review cycle. Period. Validate issues fixed please.

4. Delay the start of the project, but never delay the completion date. The date committed during project start is known to all (senior managers of both companies), but changed dates are hardly communicated unless in case of escalations. The initial buy-in will see to it that projects are on review radar, but past initial deadlines, it is left on excel sheets/Gantt charts within project teams.

5. Escalate without bias: Never escalate only when there is a problem that is discomforting you. Escalate and demand when normal, routine deliverables are missed. Treat escalations for support deliveries as well, like meeting minutes, discussion notes, future commercial implications, tracking requests for fix, changes, etc.

6. Ask for senior management attention, what ever your size be: The seniority can be decided by the vendor. But a non-project senior person is necessary to provide attention and consultation on project from both sides. If this is not there, project teams will tend to do things comfortable to them but not to their respective organizations.

7. Praise the team: US customers do this. We love it. But in India, these are more subtle. A behind the scenes word of mouth is very nice for managers and seniors, but a word of applause is required for project team workers.

8. Accept for delays and contingencies at both ends: You do not need a status report to tell you who is delaying what. Delays are inevitable at both sides. It is important to acknowledge or force an acknowledgement in email, so that they do not become a habit.

9. Provide enough references/source/stories: Well, this sounds like why i need to give the project to you. However think about it differently. Giving a project is no letting go of your commitments. It is to do things smartly and differently. Smart way, is to outline your needs progressively based on vendor thoughts. What you have in mind is validated/invalidated by similar prior experiences available with vendor. What you need is executed differently with added bonuses of giving away the maintenance and support hassles.

References/Source examples/Stories gives better clarity on expectations and aid in realistic schedules and deliverables matching expectations.

10. Prioritize what you need: As a vendor I can be willing to give a "free" lunch. But it is free only for a day. What lies ahead is more investment. Hence prioritize and do not ask for "free" lunches unless there is a need for the same. Example, You ask for a blog engine, I give "content engine" free. To manage, govern and administer the content engine, is really additional investment from your side. Do you really need it ?

11. We work mutually for better appraisals: You may hate me saying this. But at the end of the year, my project and yours too will be evaluated for WIN. Hence WIN-WIN is a must for a serious engagement. When either of our appraisals and more money is in danger of getting lost, we will not be able to get together at any levels - professional or personal. Hence mutual respect is governed by more serious personal money at stake.

Can we strive for a better appraisal partnership please ?

And few more, may be in next posts.

The ever shadowing late night experience

One of the differences that I bring as part of my existence in organization is to ensure that people leave early and leave me time in night to focus on my tasks. Part of it is selfishness since I am a night-person and late riser.

Though, it is a good practice, in IT, any one who has been strict about timelines is not known in my circle yet. Ask my mom and now she has tutored my wife better to poke fun at my management practice whenever the late nights happen.

Today (or yesterday, it is always a confusion), the late night work happenned. The master plans, effective habits all went to a toss. So what makes late night follow you constantly and catch you at the appropriate moment? Would not any IT company have a practice that is so mature and robust that they have good clients and accept only limited work that promises not a single day of extra staying hours ?

Still groping for answers...