Education

Consultant Career: Should you transfer subject matter knowledge to folks inhouse?

If a consultant shows a client how to proceed without her, is she essentially writing herself out of any future business and disclosing a process that has taken her decades to perfect?

IT consultants have career issues that are different from those of the corporate IT pro. In this regular column, we will address those issues that are specific to the consultant. In last week's column, we addressed problems dealing with placement agencies. This week, we discuss how to deal with project direction change.

Scenario

A TechRepublic member presented this scenario: "In my case, I generally get hired because my clients do not have in-house expertise in the area(s) I'm good at. A situation that has occurred several times to me is that after a period of time and exposure to my approach and resulting project plans, a customer may decide they want to do the rest of the project themselves in-house. In the remaining days of the contract the customer wants me to transfer the subject matter knowledge required to proceed with the work to their own internal staff. This presents a problem to me because I had been expecting the contract to last significantly longer. If I show them how to proceed without me, I'm essentially writing myself out of any future business and disclosing a process that has taken me decades to perfect. "

Tips in your inbox
TMake an investment in your career by subscribing to TechRepublic's free IT Career NetNote newsletter.
Automatically sign up today!

Questions

1. Assuming the consultant has signed a standard "customer owns work product" contract, would the consultant be legally obligated to provide his/her methodology?

2. Does anyone have a good alternative to simply saying "No" to the customer?

3. What is your definition of "work product"? Most consultant/employer contracts are written with the results of the work effort is owned by the end customer. This resulting work is often described as "work product" and could include the following:

  • User Surveys
  • Issues Assessment
  • Design Proposals
  • Design Development
  • Style Guides
  • Product Identity
  • Functional Specifications
  • Technical Architectures
  • Prototype Implementations
  • Pilot Projects
  • Full Production Implementations
  • Maintenance and Support Agreements
  • Complete Visualization Design and Development
  • Let's hear from you guys on the subject! Post in the discussion following this article.


About

Toni Bowers is Managing Editor of TechRepublic and is the award-winning blogger of the Career Management blog. She has edited newsletters, books, and web sites pertaining to software, IT career, and IT management issues.

Editor's Picks