Prioritization Applied to Requirements: Top Pitfalls
0 Comments Published by John Dillard on Wednesday, June 21, 2006 at 7:42 PM.
Recently we had the chance to observe a large IT organization undertake a requirements prioritization process related to a large-scale infrastructure procurement. As most CIOs know, large organizations' spending on infrastructure can account for an enormous portion of the budget, so it's critical to get the decisionmaking process right. Failure to do so can mean half-baked, underfunded projects, spending out of line with corporate priorities, or configuration issues across the enterprise.
We jotted down some of the do's and don'ts from watching this organization work, and compared them to some of my previous client experience with CIOs. The result, a top 10 list of pitfalls in the requirements prioritization process, is listed below for your reading pleasure. What's notable about this list is it doesn't really have much to do with requirements; conversely, it has everything to do with the prioritization process and how the decisions are made.
Top 10 Pitfalls in Prioritizing infrastructure Procurement Requirements
1. The CIO doesn't have authority, or even visibility, into requirements for both infrastructure and applications
2. The criteria for requirements and the prioritization of requirements are done at the same time, allowing the group to change the rules midstream
3. Criteria overlap, degrading the integrity of the prioritization model
4. Criteria don't cover the full range of preferences or characteristics required to evaluate alternatives
5. Choices are made on the basis of perception or gut feeling rather than with real, verified data on cost and performance
6. A clear, coherent process for decisionmaking isn't established at the outset
7. Requirements are ambiguous, ill-defined, or otherwise difficult to understand quickly
8. The decisionmaking group is a cabal of like-minded leaders from the same organization with the same agenda, also known as an ivory tower
9. Priorities are set in the absence of a clear and coherent vision for the enterprise architecture
10. Requirements are funded based on an arbitrary cutoff line, rather than on the basis of comparative analysis of different portfolios or groups of requirements
Those are the 10 that jumped out at me; there are far more. In future posts we'll write more on the implications of some of these pitfalls, and more on the intricacies of requirements themselves.
We jotted down some of the do's and don'ts from watching this organization work, and compared them to some of my previous client experience with CIOs. The result, a top 10 list of pitfalls in the requirements prioritization process, is listed below for your reading pleasure. What's notable about this list is it doesn't really have much to do with requirements; conversely, it has everything to do with the prioritization process and how the decisions are made.
Top 10 Pitfalls in Prioritizing infrastructure Procurement Requirements
1. The CIO doesn't have authority, or even visibility, into requirements for both infrastructure and applications
2. The criteria for requirements and the prioritization of requirements are done at the same time, allowing the group to change the rules midstream
3. Criteria overlap, degrading the integrity of the prioritization model
4. Criteria don't cover the full range of preferences or characteristics required to evaluate alternatives
5. Choices are made on the basis of perception or gut feeling rather than with real, verified data on cost and performance
6. A clear, coherent process for decisionmaking isn't established at the outset
7. Requirements are ambiguous, ill-defined, or otherwise difficult to understand quickly
8. The decisionmaking group is a cabal of like-minded leaders from the same organization with the same agenda, also known as an ivory tower
9. Priorities are set in the absence of a clear and coherent vision for the enterprise architecture
10. Requirements are funded based on an arbitrary cutoff line, rather than on the basis of comparative analysis of different portfolios or groups of requirements
Those are the 10 that jumped out at me; there are far more. In future posts we'll write more on the implications of some of these pitfalls, and more on the intricacies of requirements themselves.
0 Responses to “Prioritization Applied to Requirements: Top Pitfalls”
Post a CommentLinks to this post
Create a Link