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 prioritization of requirements. Why prioritize? 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 prioritize 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 prioritization process. If you have access to good mind mapping software, you can use it to aid you, your team and your customer in prioritizing the requirements you come up with for the final solution as one possible course of action. Of course, the benefits of prioritization 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 prioritization by following a simple five-step process:
• Define prioritization 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 prioritization 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 prioritization scheme.
I led a team of project professionals on what I would refer to as an a-typical project where we analyzed 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.
Prioritize 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 agonize over the exactness of the classification. The purpose of the prioritization process is getting a relative sense of each requirement’s priority. A review of the solution’s 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.
Brad Egeland is an IT veteran of 27 years having worked as an application developer, manager, project & program manager, consultant and business strategist and is the author of BradEgeland.com