Learn how to share risk through MoSCoW

A 4 minute read written by Paul March 12, 2015

An illustration of lawn darts.

Imagine playing lawn darts with your neighbour – over the fence. It’s a series of calculated guesses, combined with trusting that your neighbour is paying close attention when it’s your turn to throw. I like to compare this potentially risky game to the strict procurement procedures followed by many public sector organizations we work with.

For instance, a Request For Proposal (RFP) is intended to ensure transparency and fairness through open competition and an auditable system. In reality, RFPs make it very difficult for government organizations to hire innovative and performance-oriented companies.

As the client, you do your best to describe what the end solution should be, while I, the vendor, propose the lowest possible cost approach to doing what I understand the work to be. Typically, a contract based on an RFP is an attempt to push as much of the project risk as possible onto the other party. I try to control the project scope as much as possible, and you attempt to commit me to as many features as possible in the end solution to get the maximum value. It’s a game that actually pushes all the risk onto the project itself, which can hurt both teams.

The work we do benefits people, and when done well it helps newcomers to understand Canadian immigration law, helps the people of BC to get onto buses, or makes it easier to find recreation opportunities in Mississauga. We love this kind of project, so just switching customers isn’t going to work for us. However, procurement processes often place us in the middle of taking on risk or compromising on quality. How do we deliver best-of-breed solutions, ensure the health of our company, and build innovative working relationships so that citizens are getting more than mediocrity?

MoSCoW helps us set priorities together

To address this common contracting problem, we’ve adopted a practice called MoSCoW, which is an acronym:

  • Must Have: These user stories must be delivered for the project to be considered a success.
  • Should Have: These user stories should be delivered for the project to be considered a success, but there is flexibility how they are delivered.
  • Could Have: These user stories could be included in the project, but only if there is sufficient time and budget.
  • Would Have: These user stories would be included if we had time and budget, but we all agree that it’s not feasible to include them in the current project.

Working MoSCoW into your contract

There are a few contractual assumptions in how MoSCoW works:

  1. We agree that we will base the deliverables of a project on user stories. User stories come from agile development practices, and they force us to define deliverables based on how the provide value to the end user of a solution. Here’s how it works: “[User] should be able to [Task] so that [Value statement].” User stories get us all talking about value to citizens and using plain language so that all project stakeholders can participate in decisions.
  2. The MoSCoW list is not created during the contract phase; it is created after our teams have had some time to work together, learn about true user needs, and begin to develop insight into what will provide the best value. We need shared understanding and the ability to collaboratively set priorities in order create a MoSCoW list.
  3. We assume that we will base our working relationship on a technique that we like to call “reasonable conversations.” We believe that both vendor and client want to create the best possible end product.

Most public sector customers assume that they can’t enter into a contract without a fixed set of deliverables. With MoSCoW, there is a fixed set of deliverables, just split into two parts. The first set is attached as an appendix to the contract at time of signing and describes the high level requirements of the final product. This list should be the client’s best guess at his business requirements. The second part is the MoSCoW list, which describes the detailed user stories that fulfill these business requirements. It’s attached to the contract during the project, just like a change request; however, unlike a change request, the MoSCoW list shouldn’t change duration, cost, or quality.

Vendors and clients may wish to add a provision to the exit clauses in your contracts, where both parties can end the contract with reasonable notice if an acceptable MoSCoW list doesn’t prove to be negotiable. If the contract is going to go badly at some point, it’s better to know 25 per cent of the way in, rather than just before you cross the finish line.

This also adds one important new capability for public sector organizations: You have the opportunity to learn that a project is a bad or infeasible idea and stop!

Using MoSCoW helps us do the right things

We recently had an excellent experience with one of our clients, Business Link, a government-funded hub for entrepreneurs. We were successful in its RFP, but due to changes in it funding model, Business Link was in the midst of an organizational change. That meant that at the time of signing no one could tell us what the most important features for the site were.

Together, we learned that the greatest need was not complex functionality. Instead, it was a massive overhaul of the site’s existing content, which required a complete rewrite to support its transformation from a government-style resource library to an entrepreneur-focused consultancy. By prioritizing the Must Haves once we had a shared understanding, we were able to meet Business Link’s contractual requirements and deliver a final product much better suited to its clients’ needs.

We believe that this approach will allow us to participate in public RFPs, build strong relationships with reasonable clients, and deliver higher-quality digital work for people like you. Ready to learn how to share risk with MoSCoW? Contact me to get a free copy of our MoSCoW template and learn more about how we use it.