Tuesday, February 2, 2010

Specs Change

A couple times, I've worked with contractors on specific projects. I've also been on the other side of the table a few times, as a contractor brought in for a specific project. In these situations, there's often a spec that describes the project. This is intended to be the vehicle describing what the project is supposed to do when it's delivered, and it may be incorporated into a project order or contract and thus become a binding part of the agreement.


Specs change. The spec lifecycle winds up looking something like this:
  • Client provides a spec (email trail, screen mockup, Word document, etc)
  • Developers ask questions, point out holes, etc.
  • Client updates the spec. Contract is signed incorporating the spec.
  • Work begins. Developers work. Client works. Interim drops occur to show progress.
  • Client finds something that just _has_ to change.
  • Developers agree to the change.
  • Launder, rinse, repeat.
Ideally, everyone goes away happy. The client got what they actually wanted. The consulting developers got to build something useful (and hopefully the fees were adjusted appropriately along the way).

There are lots of potential problems with this workflow, but given a good relationship with the client it can work. There are a few things to look out for here:
  • When the first change comes up, that is the time to negotiate how changes will be billed. If it's time and materials, this is simple. If it's fixed fee, consider time and materials for mutually agreed scope changes, or a separate fee. Don't wait until you've delivered changes
  • Don't be rude about unstarted work. If work hasn't started in an area, the change probably won't require substantial rework. It may be scope change, but it might just be a different thing with the same scope. If the latter, there's not really any reason to make a big stink about charging extra for all this work. The work hasn't been started, so it's not like anything's getting thrown away.
  • Don't be rude about started work. If work has started in an area, and the client wants a change, then the client should still have to pay (in time and in money) for whatever part of the old way has been done. If you didn't want it, it shouldn't have been in the spec, so you should have to pay for the bits about which you changed your mind.
  • The spec parts that didn't change still have to be delivered as described. This is probably the biggest one that developers working on the project forget. A spec will have several parts. If a client changes one part but doesn't change another part, you still have to deliver the other part. This is true even if the client doesn't explicitly call out the lack of change.
  • Flexible doesn't mean pushover. Changes should go through your same development process that the rest of the spec did. That means no quickie releases without testing, no cutting corners just because the client really wants to see the change. Changes should as much as possible be slipstreamed into the existing project, and should not cause disruption unnecessarily.
Whether you're the one who's hired the development contractors, or you're the development contractors, going into a project prepared for change will help make sure the end result is something everyone can be proud of.

1 comment:

  1. I like your point for taking client's agreement for changing portion of the project. These sort of working can be useful as well as effective too.