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

From Managing Nonprofit Technology Projects Wiki
Jump to navigation Jump to search
m (1 revision imported)
 
 
(2 intermediate revisions by the same user not shown)
Line 2: Line 2:
  
 
Do you really want to "buy" a web site or database? Or do you want to develop
 
Do you really want to "buy" a web site or database? Or do you want to develop
a strategic partnership to continunously develop one? As much as we'd like
+
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
 
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
 
good research and analysis of needs. How does our transaction approach to
Line 13: Line 13:
 
'''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, monetrary,
+
contract, payment, transaction, monetary,
  
 
independence, finite scope, interdependence -- can be collaborative or hierarchical
 
independence, finite scope, interdependence -- can be collaborative or hierarchical
 
not on staff
 
not on staff
asymmetry of knowledge -- knowledge about organization vs specialist-consultant knowledge
+
asymmetry of knowledge -- knowledge about organization vs. specialist-consultant knowledge
  
client-consultant relationship is diff. from vendor-customer relationship
+
client-consultant relationship is different from vendor-customer relationship
  
 
'''Q:
 
'''Q:
Line 26: Line 26:
 
Why do we choose the client-consultant relationship over other relationship models for technology projects?'''
 
Why do we choose the client-consultant relationship over other relationship models for technology projects?'''
  
* board-staff  
+
* Board-staff  
* constituency
+
* Constituency
* funders
+
* Funders
* partner orgs
+
* Partner orgs
* boss/employee
+
* Boss/employee
* chapters
+
* Chapters
* colleagues
+
* Colleagues
* allies
+
* Allies
* advisors
+
* Advisors
* enemies
+
* Enemies
* auditors
+
* Auditors
 
* C3-C4
 
* C3-C4
* competitors (frenemies)
+
* Competitors (Frenemies)
  
 
'''A:'''
 
'''A:'''
Line 48: Line 48:
  
  
'''Allies / colleagues VS client/consultant -- What's the difference?'''
+
'''Allies / colleagues vs. client/consultant -- What's the difference?'''
  
 
Project management can wind up being like a therapist
 
Project management can wind up being like a therapist

Latest revision as of 17:42, 15 January 2016

Description

Do you really want to "buy" a web site 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 different 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.