How To Prioritise Requirements With The MoSCoW Technique
By Susanne Madsen
IntroductionOn most projects, we talk about requirements and features that are either in scope or out of scope. But to manage those requirements effectively we also have to prioritise them. And this is where the MoSCoW technique comes in.Let me explain what M, S, C, and W stand for.M is a must-have requirement. Something that’s essential to the project and that’s not negotiable.S is a should-have requirement. Something we need in the project if at all possible.C stands for could-have. Something that’s nice to have in case we have extra time and budget.W is a will not have requirement. Something that’s out of scope, at least this time around.Why to use MoSCoW technique for requirement prioritization?Using the MoSCoW technique gives us a more granular view of what is in or out of scope of the project, and it helps us deliver the most important requirements to the customer first. In other words, it helps you to manage your client’s expectations. And as you will come to see, the MoSCoW technique can also be used to delegate work and to be explicit about what needs to get done and what doesn't need to get done.Whenever I train people in the fundamentals of project management, I always teach them the MoSCoW technique. And without a fail, it ends up being one of the most useful techniques, due to its applicability and simplicity. It can even be used outside of the project space. And, if you still wonder how we arrived at MoSCoW, then we’ve simply added two o’s to turn the four letters into a memorable city name.How to use MoSCoW technique for requirement prioritization?Let us look at an example of how to use the technique in practice. I would like you to imagine that your job is to project manage an upcoming conference. This is a yearly conference where delegates will come to network and to hear industry experts talk about sustainability in project management.M- MustAs you meet with the organisation behind the event, i.e. your client, you ask them what their must-have requirements are for the conference. You are curious to know everything you must deliver to them for them to be satisfied. Your client responds that the event must be held at an indoor venue within five kilometres of the city centre and that it must be within the allocated budget. It must be able to host 150 people and it must have facilities to serve lunch.S- ShouldYou then ask your client what there should be at the event if at all possible. They answer that you should arrange for three speakers in the morning and three speakers in the afternoon. All of them should be recognised within the industry, if at all possible. In addition, you should make time for the delegates to network with each other during lunch, and lunch should, ideally, be a sit down affair with hot food. Finally, each delegate should receive a goodie bag upon arrival.C-CouldYou furthermore enquire with your client what there could be at the event. i.e. what are some nice to have requirements, which you could incorporate? You’re not promising to deliver those requirements but in case you have extra time and budget you can look into it. It turns out that your client would like to have a famous sports or businessperson open the conference. But it’s not essential and only possible if budget allows. They also think that it would be nice with a panel discussion on sustainability at some point after lunch, but it isn’t essential.W- WouldYou finally ask them what there will not be at this event, i.e. which requirements are firmly out of scope. Your client answers that there will not be multiple tracks of speakers and that there will not be any alcohol served at any point during the day. They also specify that this year there won’t be a second day of in depth workshops taking place.Using the MoSCoW technique in this way to categorise all the project’s requirements is a very user-friendly method, which your client will be able to easily understand. Initially your client may say that everything is a must-have requirement, but when you explain that must-have requirements come with a price-tag they will understand that they can’t have everything unless they increase the budget and give you more time to deliver it.When you plan your project, and put together the project plan, only include the must-have and should-have items. This is what you’re promising to deliver. You’re not promising to deliver the could-have items. They can go on a separate wish list. Also take care to properly document the will-not-have requirements. You may think that you can forget about them because they are out of scope. But, it’s necessary to document them as you may have to refer back to them later.An example of using the MoSCoW technique to describe features of a requirementWhat I really like about the MoSCoW technique is that you can also use it at a more detailed level to describe the features of a requirement. Let’s say for example that you have delegated the goodie-bag-task to one of your team members. That’s the little bag each participant will receive when they arrive at the venue and which normally contains a few freebies. It’s the team member’s job to gather the detailed requirements for the goodie-bag and to physically produce it.As you’re delegating the task, the team members would like to know what your expectations are and what they must deliver to you at the end. You should explain them all the information required clearly, such as:The requirements (M):There must be 150 goodie bagsEach bag must contain a copy of the event programme andBag as well as the event programme must be made out of recyclable materialsThe deliverables (S):There should be two free branded items inside, such as a pen and paper, if at all possible.Furthermore, explain that (C):The bag could contain something sweet, like mints, but only if a suitable sponsor is found.The bag could also contain a small bottle of water as a nice to have.Finally specify that (W):The bags will not contain any alcohol and that the combined weight will not be more than one kg.Whose responsibility is to prioritize?Business Analysts are mainly responsible to take up the most complex requirements and break down them into simple tasks that can be implemented by anyone. But, BA alone can’t do the prioritization alone. He/she needs to bring in several stakeholders into the process and get their approval on the requirements priority. It is essential for BA to understand the dependencies between the requirements before prioritizing them.Benefits of using MoSCoW technique for Business AnalystsThe BA can make use of any prioritization techniques to prioritize the requirements thoroughly. But, MoSCoW technique is the effective one to use among all the other prioritization techniques available. Some of the benefits of using MoSCoW technique for Business Analysts is shown in the figure below.ConclusionAs we can see that we can prioritise requirements with MoSCoW technique at a high level but also at a low level to specify the detailed requirements, or features, of a product. When you use it at a low level it also helps you to delegate tasks better to team members and to set expectations. Are you ready to give it a go?
based on 3 customer reviews
The Three Most Fundamental Aspects of Project Management
By Susanne Madsen
Over the years I have found that my most popular blog posts are those that speak to entry-level project managers. They value information which is clear and concise and which helps them understand what tools and techniques to use. Project management is a vast practice area and for somebody who has only recently started managing projects, it can seem overwhelming. It is my observation that there are more entry-level project managers coming into the field. And there is a good reason for that. With more and more changes taking place at a faster rate, we have a need for more people to manage those changes. This can be anything from integrating new technology to streamlining business processes or producing cheaper and better consumer goods. With that being said, let’s look at the three most fundamental project management tools and techniques that will help entry-level project managers get their project off the ground.Project DefinitionProjects need to be defined and scoped before they are planned and executed. That is true for all projects irrespective of the type of methodology they use. Defining the project helps us understand what it is meant to deliver, what the benefits are, what the costs might be and by when it is needed. This may sound like a plan to you, but it’s more like a high-level description of the project without the details having been fleshed out. The main question we ask during project definition is whether the project is worthwhile doing or not. There may be lots of ideas for new projects but not all of them have a good business rationale. Therefore they shouldn't be executed at this moment in time with this particular scope. In the company where you work, I’m sure there are many things you could improve on and many ways in which you could enhance your products or services. But not all of these enhancements will be viable business ideas, perhaps because there is a small market for some of those products or too low a margin.When we define the project, we’re essentially looking at the project’s business case and ascertaining if it provides a strong enough foundation for the project to go ahead. Defining the project can take as little as a couple of days for a very small project and several months for a larger one. You can capture the conclusion of this phase in a Project Definition Document, Project Charter, Terms of Reference or Business Case. Different companies use different terms for this document, but they may essentially contain the same information. What I recommend you to put in the document is: Aims and objectives of the project, high-level deliverables, expected benefits, high-level constraints, assumptions and risks, expected costs, future revenues, expected end date, name of project sponsor, project manager, and core team members.Milestone plan Once the project has been approved, meaning that the Project Definition Document has been signed off, you can move to the next part of the project, which is to plan it. The way you plan a project and lay out its phases, stages, and milestones will look a bit different depending on the methodology your company prefers. If you’re in a more traditional waterfall environment you’d be planning the project in a sequential way, beginning with requirements gathering and detailed statements of scope. You’d then plan for the build or execution phase to take place followed by some testing and final delivery or implantation. And of course, you’d plan for a project review to take place at the end. In more agile environments you’d carry out the above activities (requirements gathering, build, test, deliver, and review) in much shorter intervals or iterations. In addition, you’d deliver something tangible after each phase or iteration instead of all products or features being delivered at the end, which is what we do with a waterfall methodology.No matter how you plan your project, it’s a good practice to plan it collaboratively with the team. Those days are over where the project manager was sitting in isolation behind their desk doing all the planning. That approach simply doesn't create buy-in from the team members. They want to be involved in planning the work that they are expected to carry out.There are several collaborative planning techniques out there that you can make use of. I favour an old-fashioned post-it note-approach where you get people together and brainstorm what the phases, work streams and milestones of the project might look like. You’ll need lots of post-its and a white board or a wall to stick the notes onto. You also need a good facilitator (perhaps your good self) who can guide the team through the process. At the end, you should have a rough idea of which milestones and outputs will be delivered by when. You should also assign ownership to each milestone or deliverable as otherwise, the project manager may end up owning most of the items. Ask the owners to carry out the detailed planning of their individual items and revert at the next meeting with a confirmation of exactly what will be delivered by when. If your team is remote you can make use of virtual post-it-note planning tools.The outcome of your collaborative meetings and planning activities can be captured in a milestone plan. This would be a simple Excel sheet listing the project’s top ten milestones, the owner of each milestone and the expected delivery date. Very simple! As a project moves forward you can also use the spreadsheet to record whether each milestone is on track for delivery and comment on their status. In that way, this simple one-pager overview of milestones becomes a high-level plan and a tracking tool in one. This is an ideal overview sheet to use as a communication tool to your stakeholders so that they can ascertain the status of the project. Your stakeholders don’t need a detailed plan. An overview of the top ten milestones will be sufficient. The detailed plan is reserved for the core team.Risks listBe warned that no matter the size, complexity or methodology of your project, I can assure you that it will be full of risks. That’s because all projects are about creating change, meaning that the project will result in something that hasn’t been done before in that exact setting. In other words, every project is unique and therefore contains a certain element of risk. Project management methodology is essentially there to control risk and to help us execute a project with some level of predictability in spite of its uncertain elements. Defining a project, identifying and analysing user needs and requirements, planning how these requirements will result in outputs and deliveries, clarifying roles and responsibilities and prototyping the solution are all examples of activities we undertake in project management with the aim of driving down risk.Managing risks is a dynamic process as the project’s environment changes on a daily basis. Identifying and mitigating risks is, therefore, something which shouldn’t just be done when the project starts up. It’s an essential project management activity that should be carried out on a regular basis to make sure that new risks are identified and managed and that the existing ones are reviewed. In essence, I suggest that you sit down with your team every couple of weeks to go through the risk list. The collaborative element is important, as the project manager cannot identify all the risks on her own. The team has the knowledge, not only of the things that could go wrong but also in terms of generating ideas for how to overcome potential roadblocks.The outcome of the collaborative risk management meetings is risk list. This is a simple Excel tool, which lists and describes all the risks, the date they were logged, what the potential impact of the risk is and how it can be mitigated. The risk list should also contain information about the probability and likelihood of each risk (high, medium, low) as well as an owner. In many projects, there is a tendency that the project manager ends up owning most of the mitigation strategies. But in many cases, a team member or a stakeholder is the best person to manage a specific risk because they are closer to the detail.In summaryProject management tools and techniques can be difficult to navigate for an entry-level project manager. Three of the most important tools for a project manager to make use of on any project are: a Project Definition Document, a Milestone Plan and a Risk List. Whereas the project manager owns all of these tools, it’s not sufficient to simply fill them in on their own. Irrespective of whether we are running an Agile, Waterfall or a hybrid project, it will be the collective effort of the people involved who will get the project delivered. For that reason, the tools we use must be as collaborative as possible so that we can make the most of our precious team.
based on 1 customer reviews