The 3 most painful words in web development
(MoneyWatch) I've built a half-dozen websites, with three or four different developers, over the course of my businesses. The projects ended well, but without exception they were over time and over budget. Of course, that's not unusual -- in fact I've never heard of a new website build that wasn't -- and there are many reasons for it. But there is one reason that makes me pull my hair out every time, and it comes in the form of three words:
"Out of scope."
For those who have never done a web development or similarly-structured project with an outside firm, "out of scope" is service provider-language, telling you that a particular request or element of the project was not factored into the original proposal and cost estimate. Sometimes it's little changes that add up (buzzword: "scope creep"), other times it is major alterations to the plan. It may be completely intentional and mutually-acceptable -- the client simply changes his mind and/or wants something bigger, better, different. In that case, the scope of the project has indeed changed, and cost/time will change as well.
But I'm not talking about planned changes. What makes steam come out of my ears is being told something is "out of scope" when I am confident that the project and expectations were very well laid out, discussed and agreed, and I haven't changed a thing during the course of the work. The developer's usual explanation is that they didn't interpret the requirement the way it was outlined, or that they assumed that there was some latitude in the way a requirement could be executed. This often leads to disagreements that can be anything from minor to maddening.
So how do you avoid (or at least minimize) the headaches that these three nasty words can cause?
Plan, plan, and plan some more: It's not possible to spend too much time thinking through and planning out your site. It can be difficult and exhausting, but the time and effort you invest in preparation determines the level of understanding among everyone involved. And the clearer the understanding at the outset, the less likely it is that an "out of scope" discussion will come up later.
Draw it out: Whether it's a flow chart, storyboard, or combination of the two, create a detailed visual reference that everyone can share. Outline what links to what, call out critical visual elements, don't assume anything. Again, the goal is to make sure that there is little or no chance of two people seeing the same thing differently.
Write it down: Any detail that is not explained, clearly understood and agreed-upon in writing is a detail that is subject to misinterpretation of scope. You might envision a feature or function that you think is simple and beyond ambiguity, and thus write a general specification for it, and the developer might understand and execute it differently. You're then arguing interpretation, and since neither party is a mind-reader, you're in nowheresville; and if the issue is significant, the project and relationship can move to a bad place.
Read it all: The developer will take everything you provide and turn it into a proposal -- the Scope of Work (SOW). Read every line. Make sure your descriptions, requests and expectations are clearly reflected at the necessary level of specificity. For example, if you requested that an image magnify when the mouse rolls over it, but the SOW just says "images can be magnified," correct it. What seems like nuance can be a much bigger deal than you might imagine. Reading every line of a major SOW can be as mind-numbing as the initial planning phase, but again, the more attention you pay here, the fewer surprises later. Gloss over the SOW at your own peril.
After all of this is done, review it all with your developer -- every line, every specification, every illustration -- and make sure you are all seeing everything the same way. Revise the documents as needed until you are both comfortable that there is no gray area.
Of course, nailing every single minute detail of a website, or any similarly-complex project, is unrealistic. Things will always get overlooked, issues will come up as the project evolves, and some differences of understanding are inevitable. Most developers will, prudently, build some allowance for that into their quotes (and you should discuss that "fudge factor" openly -- better to put all the cards on the table upfront). But the only way to avoid significant, potentially expensive "out of scope" discussions is to plan, discuss, describe and illustrate everything you can conceivably cover, and make sure your development partner shares your understanding and vision.
Beat the details to death before the project starts, because once the meter starts running, the details can beat you back.
Also read: The worst thing to put on your company website