Difference between revisions of "Overthrowing The Consultant/Client Relationship"

From Managing Nonprofit Technology Projects Wiki
Jump to navigation Jump to search
 
(2 intermediate revisions by the same user not shown)
Line 11: Line 11:
 
'''Brainstorm on the nature of client-consultant relationships'''
 
'''Brainstorm on the nature of client-consultant relationships'''
  
Power dynamic -- specialist expertise power vs. financial power
+
*Power dynamic -- specialist expertise power vs. financial power
Contract, payment, transaction, monetary,
+
*Contract, payment, transaction, monetary, Independence, finite scope, interdependence --> can be collaborative or hierarchical --> Not on staff
 
+
*Asymmetry of knowledge -- knowledge about organization vs. specialist-consultant knowledge
Independence, finite scope, interdependence -- can be collaborative or hierarchical
+
*Client-consultant relationship is diff. from vendor-customer relationship
Not on staff
 
Asymmetry of knowledge -- knowledge about organization vs specialist-consultant knowledge
 
 
 
Client-consultant relationship is diff. from vendor-customer relationship
 
  
 
'''Q:
 
'''Q:

Latest revision as of 19:13, 15 January 2016

Description

Do you really want to "buy" a website or database? Or do you want to develop a strategic partnership to continuously develop one? As much as we'd like them to be, a web site isn't like a DVD player that can be purchased based on good research and analysis of needs. How does our transaction approach to technology consulting get in the way of a good relationship? What can we do to overcome that?

Discussion

Overthrowing Client-Consultant Relationships

Brainstorm on the nature of client-consultant relationships

  • Power dynamic -- specialist expertise power vs. financial power
  • Contract, payment, transaction, monetary, Independence, finite scope, interdependence --> can be collaborative or hierarchical --> Not on staff
  • Asymmetry of knowledge -- knowledge about organization vs. specialist-consultant knowledge
  • Client-consultant relationship is diff. from vendor-customer relationship

Q: For tech projects, most non-profits usually choose the client-consultant relationships. Why do we choose the client-consultant relationship over other relationship models for technology projects?

  • Board-staff
  • Constituency
  • Funders
  • Partner orgs
  • Boss/Employee
  • Chapters
  • Colleagues
  • Allies
  • Advisors
  • Enemies
  • Auditors
  • C3-C4
  • Competitors (Frenemies)

A: People tend to think of technology projects as "build it and your done." Risk transference -- "It's the consultant fault the project is a failure." -- not just cost but also strategic responsibility. Core competency may not exist in the organization. You may not need someone full time, but need "on call" availability. Vendor relationship doesn't imply, "on call."


Allies / colleagues vs. client/consultant -- What's the difference?

Project management can wind up being like a therapist Consultant ethos if you do a project, you are building a long term relationship. VS Perception that a website is like a pair of shoes, you'll make it and you're done.


Money changes everything-- or does it?

Timelines and money are a pitfall for inexperienced consultants and those inexperienced using consultants

A lot of mental calculus about how the money effects the relationships. Money can create a sense of competing interests, money can dominate the way we understand our relationships. Money is constantly negotiable with consultants where it's not with employees or therapists. We don't have the same tension of renegotiating with therapists that we have with consultants. Fixed cost projects vs. constantly negotiating can be easier relationships. Some find, fixed price per deliverable makes relationship a lot easier to manage. Others find hourly easier to manage and less stressful. Funders subsidize the supplier, changes the relationship. People sometimes don't value the things they don't pay for. Piece work vs hourly rate -- "it's still factory work." Good communications about what people are paying for broken down up front is helpful to prevent stress around money for both client and consultant. Consistently communicating clients what you are doing makes them feel better about where their money is going.

When a client trusts you actually have the expertise that they are hiring you for, it helps alleviate their anxiety about spending money on you.

No one knows what your expertise is worth until the project is done and everyone is happy.

Humanize money and bring it out in the air-- if you give away hours let the client know you are comping them and let them know why, "We're bringing someone new onto the team. It's going to take them a bit to amp up and you shouldn't have to pay for that."

Comping hours -- ask your accountant or attorney if it's tax deductible.


Proving what we did matches what we get paid

RFP process -- and Proof of Concept Project - and the No Spec Movement -- the agile approach to RFPs


Jamie Story: we can't tell you how much this big project will cost , but you can pay us for one month to implement off the shelf technologies, at the end of the month, we'll have an issue tracker of what hasn't worked out of the box and we'll be able to tell you what it is going to cost to do what you want."


Book Recommendation : The Secrets of Consulting -- some of it's very good


If your technology is successful and your relationship fails, then you have failed. If your technology fails and your relationship is good, there is hope.

British Telecomm found that customers who they'd made mistakes but fixed quickly were more loyal customers than those who they didn't make mistakes with. Relationship is key.