Keep hubs independent (part 2)

This article is a follow up to: Keep hubs independent

A reader is curious about my statement “Never let local forces spoil your global organization.” He asked, “sounds nice, but how should I avoid that local forces manipulate and direct the hub on their site?”

Take care already at the very beginning, during hub setup:

1. Let a local manager setup the hub; i.e. a manager with long term working experience on the local site. He has a large local network and knows which team members and stakeholders to bring on board to make the hub successful and accepted by the local site. Do the setup with the local manager as project leader; don’t establish a line organization for the hub yet.
2. Once the setup project is over, integrate the hub into the company’s line organization and put a headquarters manager at the helm for a while (e. g. 12 months). With his global background he will convince the team and the local stakeholders to support the global processes. Make sure the headquarters manager is physically delegated to the local site.
3. Finally a local manager can take the leadership of the hub. Meanwhile the global processes are established and not questioned anymore; the local stakeholders will follow the global processes.

Once the hub has reached this stage, the hub’s manager will – and should – also take requirements of the local stakeholders into account. Now it’s no threat for your global organization anymore.

Note: the whole process takes about 12~24 months.

Challenge India Part 2: How to handle specifications?

This article is a follow up to: Challenge India (for western cultures) Part1, section “specifications”

Work packages for external service providers are set down in specifications. A specification document is created by subject matter experts in the client company and passed to the service provider. After implementation the service provider hands over the deliverable to the client, expecting his acceptance.

Unfortunately that’s the way western companies handle their business relation with Indian vendors and even believe it really works this way. Eventually the companies realize that the deliverables are far from what was expected. If the specification was written on abstract level, the service provider team doesn’t know exactly what to do. But without demanding further information they start to work according their own interpretation; needless to say that the deliverable won’t match your expectation.

If the specification is written on a very detailed level, the service provider team follows each instruction without reconsidering if things make sense or not. In most cases the deliverable also won’t match your expectation. So how to write the “perfect” specification?

1) Let the service provider write the specification.
Give a rough guideline of the specification contents and the expected deliverables. Let the service provider write the specification in their own words with their understanding. Accompany the creation of the specification, ask for drafts on regular basis and clarify different views immediately.

2) Use an incremental approach.
If it takes 10 months to implement a deliverable, insist to get provisional results presented on regular basis, e.g. every 4-8 weeks. This ensures that misunderstandings are identified as soon as possible and corrective actions can be taken on the spot. Include the approach of iterative delivery cycles already in the specification document, i.e. what is presented when. Not at any time accept an approach with a single final deliverable only.

For sure, both points take more time in setting up the specification and lead to higher costs in the very beginning. But this additional effort will definitively save costs in subsequent project phases.