What should arts organizations expect when working with web developers?

• Most web developers approach their work in a logic-driven, sequential manner. The structured nature of their work demands this of them. Correspondingly, developers will want to have all of the functionalities for a project locked-in prior to beginning the work. If changes are made after the start of the work, then the logic for the site may change, and the developer may be forced to redo all of his or her work.
• Arts organizations should expect their web developers to deliver the completed project as articulated in the project agreement. Be sure to walk through the project agreement verbally with the developer to make sure that you both have the same understanding of the deliverable.
• After your organization tests the deliverable, the developer should be willing to fix any errors in the code.  These are often referred to as "bugs."

How do you know the difference between a bug and new work?

• When there is an error in the website’s code that prevents it from working, then the site has a bug. Most developers will fix bugs within six months of a project’s completion date. It is good practice to make certain that this is articulated in the development agreement. Since bugs can develop over time, it is also good practice to consider adding maintenance or ongoing support to the development agreement or as a separate annual agreement.
• If the website’s code is functioning properly but you would like for it to do something that wasn’t articulated within the development agreement, then this is likely to be considered “new work.”
• Many clients have difficulty understanding why their developer would charge them more money to make the project do what they want it to do. (And if everything is spelled out in detail, then the developer should not charge extra for making it work.) As mentioned above, making a change once the project has begun may require the developer to redo all of the work that they just completed.
• If you are vague or uncertain about what you want the final deliverable to do or how you want it to function, then you should brainstorm with the developer and hammer out these details prior to signing the agreement.
• If you have already signed an agreement and start asking questions that begin with phrases like “Would it be possible for it to …”, then you are most likely talking about new work.
• General rule of thumb: If it is broken or simply not working, then it is likely to be a bug. If you would like for the site to do something differently, then it is probably new work. This can be very frustrating for visually oriented people who have difficulty mapping everything out theoretically in advance and prefer to give feedback on something once it is “already up and running.” If you know that you will need to be able to give feedback and make changes (within reason) once a project is in the testing phase, then you should probably increase the budget for the project beyond the developer’s estimate by 20-30%.

How do you handle a situation when a developer stands behind the hours allotted to a project vs. standing behind the deliverable?

• Make certain that all of your development agreements are based upon deliverables and not estimated hours spent on the project.
• Pay no more than 50% of the project’s total cost prior to completion. This will give you more leverage in possible negotiations than if you pay for the majority of the work at the outset.
• Be certain that you haven’t changed the scope of work during the course of the project. If you did alter the scope of work, then you need to be flexible about the added burden placed upon the developer.