Too often over my career as a contractor and Federal employee, I’ve noticed that software tools are often purchase without sufficient requirements from all possible organizations who could benefit from it or its output. If requirements were requested, obtain and weighed, the end result would be a better fit for the needs of the organization as a whole, not just the one group that requested it.
The cost savings can be realized in the following scenarios:
1. The requirements process might reveal another tool already purchased that could do the job , thus avoiding the cost of a new tool.
2. The process might also capture the requirements of another group that might have purchased a similar tool, thus avoiding tool duplication.
3. As add-on modules to tool suites are often less costly to purchase and maintain than discrete tools maintained by multiple groups, factoring in that aspect might reduce costs in administration, equipment, and licenses.
4. The requirements analysis might even change the tool’s scope entirely revealing a better match with another tool, thus obtaining more cost benefit for the purchase.
This would need to be done in an efficient, non-time consuming way so as to arrive at a solid set of requirements in a reasonable amount of time. A matter of 1-4 months should be the timeframe for requirements generation.
Additionally, these tool purchases are often done without identified resources that will fully be able to utilize the feature set and maintain the tool once it is in production. This creates an underutilized tool that is perceived to underperform, and worse yet, prompts management to what to buy yet another tool to satisfy the unmet need. Cost savings can be realized by better utilizing purchased tools and thus avoid purchasing other tools to compensate for underutilized and understaffed tools.