Defining requirements is all about communication between customers, project managers, and developers.  Requirement priorities improve communications between these main parties.  The payoff is not obvious to everyone, however, and you will probably have to sell the concept of prioritization to your stakeholders.







Customer resistance



An external customer is probably the hardest stakeholder of all to sell on the concept of prioritization.  Customers have difficulty with the concept.  Requirement prioritization on the surface may appear to the customer to be of primary benefit to the developer, thus leaving you with a tough selling job on prioritization to the customer.  Many customers initially view a request to prioritize requirements as a backdoor way to reduce the number of requirements and they are very reluctant to do that.  A prioritization effort involving both the customer and the developer perspectives will separate essential from desirable, needs from wants, in a way not possible from only one side’s perspective.  The customer may decide to drop the low-priority “desirables” after such a review.  The customer may actually reach this conclusion on their own and that’s a good thing, though the overall project budget and timeline may need to be changed – elimination of requirements would require a change order or series of change orders.



Sell requirement prioritization in a positive light.  It is not just about preventing development disasters.  If the customer will prioritize requirements early, you may find opportunities to phase the product’s development in a way that improves your customer’s satisfaction.  For example, you might be able to offer a preliminary product incorporating the most important requirements earlier than the customer expects.  Because most customers buy a product or solution to improve their productivity and effectiveness, early delivery of functionality may translate into earlier revenue for the customer.  It is also a great opportunity for the customers to exercise the product on their own terms and turf before completion.



Customers usually want to preserve some flexibility in requirements.  Emphasize how priorities help them select which of the original requirements can be deferred in favor of implementing important latecomers without delaying the scheduled delivery or overrunning the budget.  Point out to the customer insisting that all requirements are Priority 1 that this can only be the case if requirements are missing.  Some requirements always exist that are merely useful or desirable, not critical, which you can defer to a later phase.



Developer resistance



Don’t be surprised if you encounter resistance to prioritization from developers. This is often because priorities may make the implementation job harder.  With prioritized requirements, developers won’t be able to schedule work simply to minimize development effort.  Customer priorities often conflict with the most expeditious implementation planning.  Include the developers in the priority discussion because their voice needs to be heard in the process.  It will help to avoid problems unnecessarily and to also gain their support.