First published on the miggle blog 21/3/17
In this post I go over how we deal with change requests at miggle. It’s actually an idea that we got from a client, Friday Media Group, for whom we built a multi-site distribution for their cars classified business. Primarily it assesses change requests alongside who should fairly bear the risk.
Ideally in an upfront discovery phase, both client and supplier would identify everything which needs to be done in a web build, which represents the scope. Of course, once a project is underway things can change, especially on projects which last six months or longer. When a change request comes up, it could be argued that perhaps the need for this should have been captured in the discovery phase. That is of course possible, but discovery phases in themselves are often time-limited, meaning that they may not catch everything, or be able to go into the detail required on a feature by feature basis.
When a change request comes up we’ll discuss it with clients using the following three criteria.
- It’s a completely new request, which is clearly out of scope and as such is charged at full rate.
- It’s a partially new request. Client and supplier both agree it’s broadly stated in the schedule of works, but that the amends requested, or the extra level of detail that the feature now requires are something which neither party picked up during discovery, and as such the work is charged at half rate, so that the risk is shared.
- The request exists because we did not fulfill on a clearly stated deliverable, in which case we treat the request as a bug of our own making and do the work to amend it for free.
The hot drinks stand
Here’s an example. A client is putting on an event and they ask us to supply a hot drinks stand. We agree with the event manager that it will sell teas and coffees. When the plan is being reviewed for sign off, the MD asks for us to include hot chocolate as well. That gets written in and we build the stand.
On the day of the event the MD turns up and asks for a can of Coke. “We don’t sell Coke,” we tell him, “and for us to do so would be a full change request because this is a hot drinks stand.” The MD agrees, and by the time of the next event we’ve included cold drinks in the scope, having priced up all the extras we need (a fridge, glasses etc.) to sell these.
At the next event, the MD visits our stand again and asks for a glass of mulled wine. “Sorry, we haven’t got any,” we answer. “But this is a hot drinks stand,” is the reply. Of course the MD is right, but we can fairly point out that while we didn’t uncover the need for mulled wine as an option during discovery, neither did they. Either party could have done. Neither was any distinction made as to whether alcoholic drinks would be supplied. The first event we planned for was during a weekday morning in the spring, so no one was really thinking about booze. Now, this second event is taken place on a winter’s evening, and actually a mulled wine would be quite warming. The changing circumstances have seen the requirements evolve in a way which we didn’t have the time to pick up initially.
Obviously to sell mulled wine might require us to have a licence to sell alcohol. We might need to do age checks too. Even before we get a new urn and a stack of oranges, cloves and cinnamon there is a lot to work out. So much so, that we might start on the basis of this being a full change request. But of course there are many factors at play in a negotiation and this could quite easily be one on which we agree to share the risk and do the work at a reduced rate. It depends how ‘hot drinks stand’ as the requirement is interpreted.
At the third event the MD asks for a tea, and we mistakenly hand over a coffee… that’s one we just have to take a hit on.
If you liked this post, there’s another hot drinks stand example here.
Digital decisions are never a walk in the park, so let me help you find the right way through the technical landscape.
