If you want potential vendors to provide proposals that are highly relevant to your own implementation, it is best to categorise requirements by Urgency, not just Importance.
If you don't do this, you could miss out on important information early on in the project and be working under the wrong assumptions.
It is standard practice to classify your requirements by importance, and business stakeholders are typically used to doing that. Every RFI or RFP includes requirements that are absolutely fundamental to the successful functioning of the new system and delivery of business benefits, and other requirements that are optional, or nice to have.
Commonly, a MoSCoW approach is used during requirements prioritisation to identify which requirements are Must Have, Should Have, Could Have and Won't Have, with the Won't Haves being excluded from the list provided to vendors.
However, many clients don't assess their requirements from an urgency perspective, which risks you not providing vendors with all the information they need to prepare a quality response.
By also classifying requirements by urgency, for example, Phase 1; Phase 2; etc or MVP; Integration 1; Integration 2 etc you provide a sense of the timing required for each component. Simply saying a requirement is Must Have can be misconstrued as meaning it is Must Have Right Now, as opposed to being Must Have (as part of the solution) but could wait to be implemented until Phase 2 or 3.
Understanding urgency helps vendors, as if they understand your view of the sequence in which the system should be deployed, they can advise you of any misalignment early on. There can be very good reasons why a system should be deployed in a certain sequence, and it is good to flush that information out from vendors early in the process, so that you are not working from wrong assumptions until the time the implementation plan has to actually be drawn up.
Implementation of software these days is almost always done in phases, so if you can get an early idea from your stakeholders how quickly certain functionality is required, you can prepare a draft implementation plan earlier in the process. This also sets early expectations that not everything that is required will delivered on day one.
Asking for a draft, typical, implementation plan from your vendors, within their RFP response, can help tie the information together.
Another benefit of advising urgency for each requirement is so that vendors can align your requirements with their product development roadmap. Software is continually being enhanced, and vendors should be able to provide a roadmap showing what functionality they plan to develop in future.
By aligning your implementation plan with the development roadmap for the preferred system, you can make sure you will be able to deliver the eventual solution in a way progressively builds, and that fits with whatever other changes are happening in the business alongside the implementation.
Classifying requirements by Urgency, and not just by Importance, gives you better chance of understanding each proposed solution in more depth, including whether the way it is typically implemented conflicts with organisational priorities.
Add comment
Comments