I will always shout it from the rooftops that requirements are the lifeblood of the project. And accurate, complete, and detailed definition and documentation of project requirements is absolutely essential in order to ensure that the delivery team is creating the right, usable end solution for the project client.
On to the next concept. Are all requirements created equal? No. Some are ‘absolutes’, some are ‘needed’, and some are the ‘nice-to-haves.’ I like to refer to these as 1’s, 2’s, and 3’s in terms of prioritisation of requirements. Why prioritise? Because inevitably some requirements are or have been scoped into the project that may either end up not being feasible or may end up not being wanted or needed. And cost can always enter into that factor as well. Either in terms of keeping the cost down from the start or in terms of getting the project financials back on track when unforeseen work or a large change order has pushed the project over budget.
There are tools out there to formally prioritise project requirements – some require a decent investment in technology. I think that is unnecessary route to take, as I usually like to keep things simple and most projects don’t require that type of investment in a formal prioritisation process. If you have access to good mind mapping software, you can use it to aid you, your team and your customer in prioritising the requirements you come up with for the final solution as one possible course of action. Of course, the benefits of prioritisation have to exceed the cost of actually doing it, but you’ll usually find it beneficial to have put effort into this process when you reach some of those hard decision points later in the project where an issue arises and you might be forced to discard some functionality.
Most projects can enjoy the benefits of requirement prioritisation by following a simple five-step process:
• Define prioritisation process
• Classify the requirements
• Resolve inconsistencies
• Create a priority-based project schedule
• Maintain the priorities throughout the engagement
Let’s go into each further…
Define the prioritisation process. The key here is to keep the process simple…otherwise you won’t use it properly. A numbering system of 1-2-3 works well for me as I mentioned above. Number the essential, non-negotiable, and urgent requirements with priority 1 – these are the ‘absolutes’. Assign priority 2 to the useful, negotiable, or slightly deferrable requirements – the ‘needed’ requirements. I use priority 3 for the desirable, flexible, or ‘someday’ requirements – the ‘nice-to-haves’. Be sure to properly educate everyone on the project who will be involved in this process – including all stakeholders both internal and external, customers and developers – on the prioritisation scheme.
I led a team of project professionals on what I would refer to as an a-typical project where we analysed all service providers in a specific software niche for the Department of Defense (DoD). Using such a process to weed out which vendors would be able to best meet the DoD’s “1’s” and “2’s” on their requirements list enabled us to evaluate each offering more efficiently and provide a better overall picture to the customer – the DoD – on who could actually deliver what they needed the most.
Prioritise the requirements. Next, ask all stakeholders to classify the requirements by priority, which should be an informal sorting process. Don’t give people time to agonise over the exactness of the classification. The purpose of the prioritisation process is getting a relative sense of each requirement’s priority. A review of the solutions’ use cases or the product’s operational scenarios helps stakeholders classify requirements. Often, it’s easiest to identify 1’s and 3’s first and allow everything else to default to 2.
In Part 2 of this two part series we’ll examine the next three steps of the five-step process in detail.