Difference between revisions of "How to consult ethically to nonprofits"

From DevSummit
Jump to navigation Jump to search
m (1 revision imported)
 
(No difference)

Latest revision as of 23:37, 4 May 2015

Ethical Consulting - Wednesday Session 1

  • Thoughts and concerns in the room:
    • Keep things fair for both client and consultant.
    • How do we value labor?
    • How to keep hourly rates fair but sustainable?
    • How to keep expectations reasonable given capacity and budgets.
    • Billing for all the work we do.
    • Long-term health of the project.
    • For clients in the developing world: how to work with them ethically as outsiders, making sure people own their own tools.
    • Avoiding burnout.
    • Wanting to see a client’s work succeed, but running out of budget.
    • Concerns about undercutting other developers.
    • Tech work being overvalued by society, which allows us to set higher rates that we feel we ought to given societal inequity.
    • The fact that these conversations can be difficult.
    • Isolation.
  • Common threads:
    • 1. Rates and billing.
    • 2. Organizational value and contributing to an org’s success (i.e. not just extracting money from an org), and not just extracting from an org.
    • 3. Well-being, and addressing our own needs as humans.
    • 4. Forming community around these issues, and being able to discuss them.

1. Rates

  • How to determine a sliding scale that’s grounded in real needs?
  • Value-based (as opposed to hourly) rates: can cause issues when a project takes longer than expected or scope creep occurs; however, hourly rates cause sticker shock.
  • Billing time for educating yourself on new things.
  • Idea: when “eating” hours, list them on invoice as pro bono to help foster a culture of valuing work.
  • One common issue: Changes in the scope or depth that happens during a project necessarily causes a change in billable hours. The client doesn’t always understand this, and it can be difficult to communicate it.
  • Ways to address it:
    • Padding/contingency hours.
    • Invoicing for project management.
    • Discovery phase as a separate work agreement, with a set of solid deliverables including a better estimate, including how much project management/communication time a client will need.
  • Difficulties estimating projects, when each one is different.
    • Think about how long a project will take, then double it.
    • Charging overage at lower rates.
    • Be upfront about how the estimate might change depending on scope.
    • Limit scope to fit within a fixed budget.
  • Other things to consider:
    • Understanding that the client might not understand how tech works, how long tasks might take, and how seemingly small things might be. https://xkcd.com/1425/
    • Lots of communication about how/when scope is changing. Collaboration with client: “How to we solve this problem together?”
    • Communicating a plan for overage hours ahead of time, like billing overage hours at a lower rate.


  • Agile development: difficult with for NP clients; can work with focusing on what’s important, what’s achievable. Setting realistic expectations, and exceeding them if possible. Starting with significant discovery/kickoff meeting to really understand the scope of the phase/sprint/project.
  • Other issues:
    • Mismatch of pacing and capacity with client and consultant; arranging it such that neither client nor consultant are waiting on each other.
    • When working as a sub-contractor, not knowing how much discovery has been done, what relationship is.


2. Not being an extractive entity.

  • Pre-engagement to find alignment: the value of that stage being paid for, whether explicitly or as padding.
  • Issues caused when we are upfront that discovery takes time, but less ethical other shops might make unrealistic promises.
  • Requirements document/Needs assessment
    • Helps understand what a given budget will realistically allow.
  • The RFP document.
    • Can be unreal if developed in isolation, as opposed to during a collaborative discovery practice. Can result in a product that ultimately doesn’t serve client or consultant.
  • Guarding against doing discovery work on spec.
  • Issues with aging invoices.
    • Understanding that work has value
    • Threatens our future work, our other clients.
    • Deposits and progressive monthly billing can help avoid aging invoices.


3. Community building: continuing the conversation.

  • Aspiration Tech will host a listserv for technical consulting. Also, people can and should have meetups.
  • Web of Change community, which can be problematic.