Work Agreements

From DevSummit
Revision as of 17:21, 5 May 2015 by Vivian (talk | contribs) (1 revision imported)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Work Agreements

Mark: works for WorkerFlows, focus on long-term engagement with non-profits

Different kinds of work agreements:

The contracts used by WorkerFlows:

  • Discovery phase work agreement - concrete # of hours
    • Counter to traditional RFP process, which doesn’t work
    • It’s like an awesome first date, and ensures that there are well thought-out estimates of the time needed for each part
    • Sit down for 1 face-to-face meeting
    • Go through discovery aspect, figure out the story of what’s happening/what needs to happen
    • Go through tools that could work
    • Follow-up meeting to make sure they got everything right
    • Deliverable is a document
      • can differ depending on audience: if WF is doing the project, can be straight-forward; if the report is going to funders, will make it pretty
      • after the document is done, the contract is done
  • Development work agreement - if possible, like to have a contract for each phase of the development process
  • Maintenance agreement
    • pick a certain number of hours a month that WF will be on retainer
    • client pays for all hours, even if WF doesn’t use it - the extra hours are used to make sure there’s someone trained on the project

What WorkerFlows finds works well:

  • phased approach
    • How are phases determined?
      • Often separate by feature sets
      • But WF also does an MVP of multiple feature set, if that makes sense
  • Contracts done in plain language (~ a paragraph)
  • variable scope with budget cap OR fixed scope billed hourly

Other peoples’ experience:

  • Thiago
    • is dealing with a client that loves to have ideas in midstream
    • don’t have a formal (or good) way to handle this
  • Rachel
    • lots of fiscal upheaval
    • is trying to keep everything they build open
    • have subcontractors too
    • in conclusion, lots of contracts!
  • Josh
    • Also does the discover part, and has never had any clients go to someone else.
    • Will give time estimate and budget cap.
    • Sometimes eats the extra cost.
    • Uses a detailed statement of work, but does sometime get clients who realize half-way through that they’re getting something different than what they thought
  • Andrea
    • Works for DesignAction
    • also have a long discover process - get to know the organization and its goals
    • contract has details about the design process, the development process, and a retainer
    • clients have the ability to decide whether they want to use extra hours in retainer or go into the next month
    • make it VERY clear that success is a collaborative effort
    • have all discussions in Basecamp so
  • Rebecca
    • was tasked with project managing a project with:
      • 12 years of resentment between the partners
      • deliverables declared without input from one of the partners
      • massive miscommunication

Healthy practices

  • Make everything explicit
  • Rachel did an RFP where she kept in the clients’ responsibilities - that felt very healthy and upfront
  • Tools to show the tradeoffs of priorities
  • If the client wants something you don’t think is a good idea, give clients all the information (including your opinion) but trust clients to make their own decision
      • they know their own interests best
  • Create a collaborative environment!
    • this is a partnership, not a traditional business engagement (i.e. extract all profit)
    • That’s why honesty is so important.
    • Also making sure there’s no “I told you so.”
  • Building in a buffer on every feature set
  • Upwell has a list of reasons for choosing projects/dev shops.
    • Points of unity help inform how to phrase contracts

Unhealthy practices:

  • Eating hours
    • Mark: put the pro bono hours in the invoice
      • but makes it clear to clients that the hours are really at the discretion of the individual developer
    • Josh: eats the hours if he mis-estimates the amount of time
    • You can’t claim your hours as donations - the IRS does not consider human labor as donate-able
    • Rachel wants to know when you work extra hours, because she can often pay more
    • on the other hand, small gifts do a lot for the relationship
  • Stakeholders who have put a random line in the sand
    • it's hard to navigate the emotional issues when individuals in the project are very invested in particular features
    • sometimes it's important to just let that person have their thing
  • Gatekeepers afraid of their bosses
  • Requirements made in a vacuum
    • RFPs are horrible
    • But they’re also a way of opening up a conversation
    • So maybe what we should be looking out for is the Very Specific RFP
  • Boilerplate work-for-hire agreements