Ethical Consulting

From DevSummit
Revision as of 01:24, 23 November 2016 by Willowbl00 (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Facilitated by John Kenyon

Session Description

Session details

2:15pm, Monday

Session Notes

This session was based on the Nonprofit Tech Provider Principles Available by logging into NTEN Affinity Groups - link: [1] and searching for the group: NPTech Professional Principles (direct address is here: [2]

See the bottom of this page for the Ten Principles


"How do I deal with a situation where the client's need may not exactly match my expertise?"
When you're a hammer, every problem looks like a nail.
Easy to recommend what you know, rather than what works.
Requires educating yourself so you know better what alternatives there are.
Saturation/overwork helps us say no. If we can't take on more work, it's easy to tell the client "you need a simpler solution!"

"I want to be a super-hero, but I can't!"
Because we're activists ourselves we often fall in love with our clients' projects and work ourselves to death.
Nonprofits are needy. The neediest ones, the ones you want to help most, sometimes are the hardest to help because they lack the infrastructure, the time, the staff & continuity to do a good job.
Can't push the client harder than they're willing to pull for themselves. Must be willing to end the consultancy if the client can't do what's required at their end.
We have to balance work and life.
Like everything else in life - have to set boundaries. Can't take care of anyone unless I take care of myself first.
Keep a good clean client/consultant boundary.
I target the groups I care most about.

"What's different about pro bono projects?"
Pro bono clients tend to be under-resourced.
Pro bono clients may be less worried about wasting your time; may be unprepared or even disrespectful.
It's harder to manage client expectations, therefore more stressful.
We make sure the client identifies whose job it is to accomplish the tasks that client is responsible for. We start them early!
Structure helps. We do a sprint-based model - we're on the site constantly for two days, so the client knows they have to be prepared to work with us for that time.

"Do I have a responsibility to tell the client things they'd rather not hear?"
e.g. "Your problem isn't your email system, it's that the ED deals with communication by sticking her head out the door and screaming at people"
e.g. "You're not using your existing CMS, so why do you think you'll use the new expensive one?"
If the job requires a big organizational change, I won't do the contract unless I talk with the ED or even the full board first, to make sure there's organizational buy-in.

"If a client doesn't pay, what's an ethical response?"
Some have gone so far as to roll back changes in software to last paid work, or withhold passwords - but that just damages your own reputation.
Look for red flags early on - if the client is constantly late and isn't talking to you, it's a bad sign.
Let them know at 31 days if the invoice is late. At a certain point simply stop work until the account cleared up.
Break the jobs and invoices into logical pieces. If the final piece doesn't get paid, just chalk it up to the cost of doing business. If the relationship is good it's very rarely a problem.

"Do we have an ethical responsibility to bring young people/interns into the field of tech consulting for nonprofits?"
We do!
Computer Science grads often get burnt out after a few years, need to take a break before going back in. Doing NPO work would be better than bumming around Costa Rica.
The problem is that internships in the NPO world tend to be unpaid and CS folks are used to being paid - well.
StreetTech had some kind of training program. Are those trainees at work anywhere?

"When our tech nonprofit is funded by [global tech corporation to remain nameless], there's subtle or not-so-subtle pressure for us all to use [that corporation's] products internally, even if they're not the best."
(Sympathy abounds)

PLUG: Highest recommendations for The Gift, a classic book by Lewis Hyde, about graceful ways to manage the intersection of cash economy with a "gift economy" based on relationships and community.


Non-Profit Technology Professional’s Principles/Code of Conduct

We, as technology professionals serving nonprofit organizations, pledge to:

1. Do No Intentional Harm to Data or Devices Containing Data

2. Appreciate, Respect and Adapt Our Approaches Appropriately to an Organization’s Culture, Mission, Context and Resources

3. Focus On Solutions Appropriate in Both the Short and Long Term to an Organization’s Culture, Mission, Context and Resources

4. Explain/Demonstrate Technology Strategies and Tools Using Clear, Non-Technical Language

5. Understand and Communicate the Applicable Excellent Practices, Legal and Technical Requirements Related to Our Work

6. Engage in Continuous Learning Practices to Maintain Our Skills and Knowledge

7. Regularly Participate In and Share Our Knowledge With Our Community

8. Maintain Ethical Practices and Declare Any Conflicts of Interest

9. Provide Recommendations and Not Directives, Communicating the Reasoning Behind those Recommendations, Ensuring the Decision is Always the Clients

10. If We Charge for Our Services, to be Transparent About Product Pricing and/or Project Costs