https://devsummit.aspirationtech.org/index.php?title=Work_Agreements&feed=atom&action=historyWork Agreements - Revision history2024-03-29T10:17:18ZRevision history for this page on the wikiMediaWiki 1.35.1https://devsummit.aspirationtech.org/index.php?title=Work_Agreements&diff=219&oldid=prevVivian: 1 revision imported2015-05-05T17:21:40Z<p>1 revision imported</p>
<p><b>New page</b></p><div>= Work Agreements =<br />
<br />
Mark: works for WorkerFlows, focus on long-term engagement with non-profits<br />
<br />
== Different kinds of work agreements: ==<br />
<br />
=== The contracts used by WorkerFlows: ===<br />
* Discovery phase work agreement - concrete # of hours<br />
** Counter to traditional RFP process, which doesn’t work<br />
** It’s like an awesome first date, and ensures that there are well thought-out estimates of the time needed for each part<br />
** Sit down for 1 face-to-face meeting<br />
** Go through discovery aspect, figure out the story of what’s happening/what needs to happen<br />
** Go through tools that could work<br />
** Follow-up meeting to make sure they got everything right<br />
** Deliverable is a document<br />
*** 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<br />
*** after the document is done, the contract is done<br />
* Development work agreement - if possible, like to have a contract for each phase of the development process<br />
* Maintenance agreement<br />
** pick a certain number of hours a month that WF will be on retainer<br />
** 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<br />
<br />
== What WorkerFlows finds works well: ==<br />
* phased approach<br />
** How are phases determined?<br />
*** Often separate by feature sets<br />
*** But WF also does an MVP of multiple feature set, if that makes sense<br />
* Contracts done in plain language (~ a paragraph)<br />
* variable scope with budget cap OR fixed scope billed hourly<br />
<br />
== Other peoples’ experience: ==<br />
* Thiago<br />
** is dealing with a client that loves to have ideas in midstream<br />
** don’t have a formal (or good) way to handle this<br />
* Rachel<br />
** lots of fiscal upheaval<br />
** is trying to keep everything they build open<br />
** have subcontractors too<br />
** in conclusion, lots of contracts!<br />
* Josh<br />
** Also does the discover part, and has never had any clients go to someone else.<br />
** Will give time estimate and budget cap.<br />
** Sometimes eats the extra cost.<br />
** 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<br />
* Andrea<br />
** Works for DesignAction<br />
** also have a long discover process - get to know the organization and its goals<br />
** contract has details about the design process, the development process, and a retainer<br />
** clients have the ability to decide whether they want to use extra hours in retainer or go into the next month<br />
** make it VERY clear that success is a collaborative effort<br />
** have all discussions in Basecamp so <br />
* Rebecca<br />
** was tasked with project managing a project with:<br />
*** 12 years of resentment between the partners<br />
*** deliverables declared without input from one of the partners<br />
*** massive miscommunication<br />
<br />
== Healthy practices ==<br />
* Make everything explicit<br />
* Rachel did an RFP where she kept in the clients’ responsibilities - that felt very healthy and upfront<br />
* Tools to show the tradeoffs of priorities<br />
* 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<br />
*** they know their own interests best<br />
* Create a collaborative environment! <br />
** this is a partnership, not a traditional business engagement (i.e. extract all profit)<br />
** That’s why honesty is so important.<br />
** Also making sure there’s no “I told you so.”<br />
* Building in a buffer on every feature set<br />
* Upwell has a list of reasons for choosing projects/dev shops.<br />
** Points of unity help inform how to phrase contracts <br />
<br />
== Unhealthy practices: ==<br />
* Eating hours<br />
** Mark: put the pro bono hours in the invoice<br />
*** but makes it clear to clients that the hours are really at the discretion of the individual developer<br />
** Josh: eats the hours if he mis-estimates the amount of time<br />
** You can’t claim your hours as donations - the IRS does not consider human labor as donate-able<br />
** Rachel wants to know when you work extra hours, because she can often pay more<br />
** on the other hand, small gifts do a lot for the relationship<br />
* Stakeholders who have put a random line in the sand<br />
** it's hard to navigate the emotional issues when individuals in the project are very invested in particular features<br />
** sometimes it's important to just let that person have their thing<br />
* Gatekeepers afraid of their bosses<br />
* Requirements made in a vacuum<br />
** RFPs are horrible<br />
** But they’re also a way of opening up a conversation<br />
** So maybe what we should be looking out for is the Very Specific RFP<br />
* Boilerplate work-for-hire agreements</div>Vivian