Work Agreements

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

Different kinds of work agreements:

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

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

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

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

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