For an upcoming project at TOPP, we’re talking about setting up an optional scope contract [PDF] — where we specify the time, cost and quality, but leave the actual scope of work open. This approach has many advantages, which I’ll just quote from Beck & Cleal’s document:
- Customers can change their minds
- Suppliers aren’t encouraged to sacrifice quality as soon as something goes wrong
- Customers’ and suppliers’ interests are contractually aligned
- The knowledge that both parties gain during the project can influence the finished product.
In my experience so far, it has been much easier to set up agreements like this in the private + nonprofit sectors than in the public sector. Typically, public sector contracts must begin with detailed requirements (beginning with an RFP then a final scope of work), to ensure that the requesting agency doesn’t get screwed over. The problem with this approach, of course, is that you don’t always know what you need at the beginning of a project, or to rephrase, that’s when you know exactly the least about what you’ll be making.
So my question for you, internet, is have you had experience making optional scope contracts work in the public sector?
// thanks Nate for turning me on to this idea at last year’s Nonprofit DevSummit
OpenGeo’s had some success selling contracts that are support-plus-bundled-hours, which is another way of contracting around the same problem, I think. Sometimes, public sector clients have gone for them.
In future rounds of GeoNode work, something we are likely to try out is working one of these support+hours contracts _into_ fixed cost contracts. In theory, this buries the flexibility under a commodity product purchase but leaves that flexibility there so that the client can be enormously appreciative later.
OpenGeo’s had some success selling contracts that are support-plus-bundled-hours, which is another way of contracting around the same problem, I think. Sometimes, public sector clients have gone for them.
In future rounds of GeoNode work, something we are likely to try out is working one of these support+hours contracts _into_ fixed cost contracts. In theory, this buries the flexibility under a commodity product purchase but leaves that flexibility there so that the client can be enormously appreciative later.
Right — I actually came to that same conclusion yesterday writing a proposal. Part 1 = fixed cost, Part 2 = flexible hours. Rather than scope out part 2 now, when you know the least, decide about it midway through the project, once you have a better understanding. I think this approach has potential.
Right — I actually came to that same conclusion yesterday writing a proposal. Part 1 = fixed cost, Part 2 = flexible hours. Rather than scope out part 2 now, when you know the least, decide about it midway through the project, once you have a better understanding. I think this approach has potential.