Outsourcing Governance model

I am trying to figure out if there are standard (or generally accepted practices) Governance models between the Customer and the Outsourcer. This is, when a new Outsourcing project is to be developed, what should be the relationship model (or governance model) between the customer and the outsourcer? What should be the interfaces between both parties? In a life cycle that goes 1.Presales 2.Transition (migration) 3.Operation 4.WayOut, how should customer and outsourcer interact with each other? Thanks for the answer, Juan

Answer Wiki

Thanks. We'll let you know when a new response is added.


This is wonderfully interesting! I.ve interfaced with over 40 companies and not a single one had a comprehensive policy concerning non-1099 contract work! Just lots of policy in different places addressing most of the little pieces.

Since you.re asking this question, I.ll assume that no more than a few people at your place authorize/monitor out-sourcing. That being the case, I.d start with a set of boilerplate guidelines worked into each and every contract until you find those tenets that .fit. your company and your typical client. After that, you.d have a good base for a policy. But, if out-sourcing will not become a habit for your company, here are some suggestions that might fit your situation:

1. If the OS (out-sourcer) needs on-site time, prepare a .safe. work area restricted from extended contact with personnel not directly and immediately related to the OS.s task at hand and give those cpu.s severely restricted net access, hopefully only to a sacrificial server that merely emulates your data production area. They need to sign in and be seen each and every time they arrive and leave;

1.5 For software and ergonomic designs, the OS will need access to employees performing their duties, but should probably be escorted;

2. Put into the contract who owns the manifestation of creativity (whether code, document or advertizing poster.) A creative manifestation is more easily and finitely argued in your favor than the concept of intellectual property;

3. Put into the contract a time restriction (at least 6 months to a year) of applying related intellectual property of special interest to the benefit of your competitors. This is different than a no-compete clause. If your project results in a nifty way to get something done, protect that nifty way. But you might find it hard to get help later on if you lock the OS from helping any body that might have a process that may possibly benefit from the nifty way even if it.s not used or might be implemented in a niftier way. Just make sure it.s clear what part he may not reproduce, stylistically and/or algorithmically;

NOTE: the above two are in addition to the standard protection of company data (lists, processes, personnel data, etc;)

4. Put into the contract what tools, mentors and sub-contractors may or may not be used;

5. If you.re wanting a partially intangible .creative. product from the OS and can.t clearly define it, very clearly define limits of resources and provide examples of what you know you don.t want. The daily sign-offs mentioned below will keep you from being surprised;

6. For contracts estimated at 60 days or less, require daily communication between the OS and your liaison, verifying the trend of development with the PO (project originator.) Drop this mandatory comm to weekly otherwise, but do not limit it to that. You want the OS to feel both obligated and free to contact you to quickly crystallize a spec or work around a deficiency;

7. Require that this communication be two (redundant) of any standard ways; face to face, email, paper, phone, fax, etc;

8. Require that work in progress and deliverables be presented in two (redundant) types of media to all task sites and meetings;

9. Require that the OS state in writing a reasonable method of either backup (software) or protected storage to keep the project safe;

10. Require that the OS acquire sins & omissions coverage large enough to cover your hypothetical losses or agree to be bonded by you;

11. Arrange for a backup authorizer for the PO, so that any deviation or enhancement may be guided in a timely manner;

12. The OS is not to discuss project internals with anyone not directly authorized and identified by the PO;

13. While on-site, the OS will blend into the host culture regarding food, dress and language (vernecular, slang; not actually the language);

14. In larger, complex ventures, specify the transition process from one liaison to another; passing the dialogue to other phase-appropriate individuals verbally and by a letter of introduction indicating this new contact.s function and position in the company. When the team leader passes on to the implementation or maintenance leader, for example, the same event should occur. The OS should never, ever feel like they don.t know whom to contact or to whom they answer;

15. Require the OS to state how to be contacted in emergency and who they have prepared to deliver any work in progress upon their demise or incapacity;

16. For larger projects, if the OS wants partial payment at various stages which represent milestones of value, you might agree to that for a reduction of overall charges;

17. Assign someone relatively unrelated to the whole thing to gather communiques and specs to keep up an audit trail all through the project.

The details of all this will be found after bartering with the OS and then can be placed with the spec.

Upon re-reading your question several times, I think that you might be the OS here. If so, remember that having all the above spelled out will protect you, too, and ease your conscience about directions to take along the way. Also, if you.re work concerns sofware/hardware or a particular manufacturing machine, have the company document that system.s current level of operation, through-put and, if appropriate, level of mis-function before you start. That way, you can.t be blamed for potential lower performance already experienced. For example: don.t pop open a cpu without first having a company rep turn it on and verify that it at least boots up, or not, to begin with.

** If you.re asking whether there.s a caste system to business agreements, I.d say yes, there is. You can make judgements about the obligations of politeness and formality for your culture and answer your own question based upon whether or not you have the clout to let your ego take over negotiations. But, if you deal with other cultures, I suggest erring on the side of formality and humility until the client shows a warmer side. I heartily recommend that *all* of your front-end people take at least one sensitivity training course *immediately* !! Assuming your group has more intelligent people than not, they have the ability to adapt themselves to the clients’ mannerisms and presentation of personal space and culture. If they don.t, it.s because they won.t; and that.s an issue for your CHRO.

Part of your routine might need to be occaisional cameo appearances by big wigs from your company and the clients’. Kind of like kings bowing to each other at the gala ball. This little dance usually happens after pre-sales and again at the end as the product or service moves into completion or standard production and the big guy wants to show it off and receive comment from your big guy.

Finally, is there an industry standard method of doing this? I don.t know. I.ve seen more companies deal with OS like they were just out buying office supplies for the paper closet. One place treated us (I was OS at that time) like employees, which happened to be quite nice. Four companies that I know have rather complete 1099 contractor policies are IBM, Johnson & Johnson, ManTech International and GTE. They might share them with you, as the policies are printed by the thousands and delivered to temps all over North America.

I do know that if you communicate clearly and politely; agree to, and do, only what you are able; and are discrete that nobody will ever successfully challenge your professionality. There.s a lot of room in that to tailor your business personality. I.d jump up and run away from anyone trying to shame you into a certain business/relational model rather than to lure you with grace and benefit.

🙂 Gene

Discuss This Question: 2  Replies

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • Khilving
    HappyGene offers some good advice in his second paragraph. As you set about making those guidelines I suggest you keep the following in mind. Business objectives drive business requirements. Business requirements drive the outsource objectives, which in turn determine the outsource governance requirements. The next 18 points raised are all situation specific. Keep your governance as simple as possible - if you can't link a specific point directly to an objective and then to its directly linked business requirement, then leave it out. Otherwise, you risk policy parallisis.
    0 pointsBadges:
  • ITSourcerer
    JuanGV is you are still looking for the answer please read my free ebook on the Science of Sourcing Governance. Enjoy the read!

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: