Reasons for using the MoSCoW approach in project management
- Blog
- Agile
- Communication
- Customer engagement
- Project management
- AgileSHIFT
- PRINCE2
- PRINCE2 Agile
July 30, 2015 |
4 min read
- Blog
- Agile
- Communication
- Customer engagement
- Project management
- AgileSHIFT
- PRINCE2
- PRINCE2 Agile
It’s fashionable to convey confidence in a standpoint or outcome by incorporating the phrase “100 percent”.
If I gave such an absolute level of assurance when managing a project, I suspect my customers would soon become disillusioned with me as I have never delivered 100% of anything. Should I be embarrassed by this admission? Perhaps! But I think I am expressing the reality of the world of uncertainty that is project management.
So, if it is rarely possible to give your customer everything they have asked for, how can you:
- Get them to understand and accept this?
- Agree what you must focus on to make sure they remain happy with the outcome?
One key aspect of getting to this level of shared understanding is clearly comprehending and prioritizing their needs. A useful and generally accepted approach for facilitating this understanding is the MoSCoW prioritization technique.
MoSCoW is a somewhat contrived mnemonic for a simple prioritization technique that can be used in many scenarios including project management. However, whilst the concept may be simple, using it can have huge implications in the way a project is delivered and perceived.
The mnemonic is built up from the following hierarchy:
- Must Have: critical to success
- Should Have: there is a workaround but it will be painful
- Could Have: a nice to have
- Won’t Have: well, not this time, anyway.
The “Must Haves” are sometimes also referred to as the Minimum Usable SubseT as they are the absolute minimum acceptable to the customer. However, the key point here is that the prioritization is from the customer’s perspective and is based on their needs.
There are some schools of thought that the rule of thumb for a balanced, prioritized list is:
This technique has its origins in agile software development, specifically rapid application development (RAD), but has found relevancy in both agile and traditional project management and so is perfect for PRINCE2 Agile™. For diehard traditionalists, take comfort in the fact that the technique is mentioned twice in the current edition of PRINCE2® (on pages 51 and 93)!
In my experience, most people “get” the principles of the MoSCoW technique really easily. However, the main objection to using this technique is, perhaps, more philosophical.
The key premise underlying MoSCoW is that not all the customer wants (this time) is critical to the success of the project; the reality is that a customer would compromise one or more areas to protect another.
I am sure you will have had conversations along the lines of the following:
| Customer: | I want everything on my wish list and I want it on time and to cost! | |
| Project Manager: | OK, what happens if we find any significant problems when we start to understand the problem and the possible solutions better? What is the most critical constraint from your perspective? | |
| Customer: | What do you mean? | |
| PM: | You said at the start of our conversation that time and cost were important. As I am sure you don’t want to compromise the quality of the solution, that only leaves flexibility in the scope. | |
| Customer: | I suppose so, but I also asked for everything on my list! | |
| PM: | Well, if something has to give, we should try to identify what is absolutely vital to the success of this project? Let me tell you about the MoSCoW technique … |
A short time later…
| Customer: | OK, I can see that makes sense but doesn’t that mean I am only going to get 60% of my requirements for my money? Also, what happens to the requirements I don’t get this time? |
The customer can be reassured only with a collaborative, highly visible way of working built on trust leading to a longer term relationship. The effort spent by all parties working on building trust should not be underestimated. The pay-back, however, is potentially significant.
MoSCoW works equally well when customers change their mind:
| Customer: | We have reviewed the business case and we need to change the scope to deliver [an additional requirement]. | |
| PM: | Of course. Assuming this is a new “Must Have”, what are you prepared to demote/add to the “Won’t Have” pile so we can guarantee delivery on time and to cost? |
Change can be handled through:
- The normal request process, or
- Scope tolerances (which is my preference).
If scope is treated as project contingency, non-delivery of “Could Haves” should be ‘in tolerance’, whereas non-delivery of “Should Haves” will have to be managed in the usual way. Non-delivery of “Must Haves” is non-negotiable and will mean invalidation of the business case.
As hopefully this demonstrates, MoSCoW is a great technique for PRINCE2 Agile, but it will require some education of key stakeholders to gain acceptance and leverage its simplistic power.
How do you prioritize workstreams when managing projects? Have you ever used the MoSCoW techniques Phil de Caux describes? Please share your thoughts and experiences in the comments box below.