Database Reference
In-Depth Information
What Are We Building?
Once you have established that the BI solution is beneficial to the client, begin figuring out what is going to be a
part of the solution and what is not. Create a list of all the features that your client requested to be included in the
solution, and then examine existing documentation and reports for inspiration about what else should be added
to the solution. It is common that the interviews with the people involved will not identify all the requirements of
the solution.
When your list is created, prioritize what has to be in this version of the solution. One method of doing this is
to use a technique known as four-quadrant prioritizing . An example of this is shown in Figure 3-2 .
Identify what is the value to your client versus the difficulty and cost of an item. When an item provides
substantial benefit to users at a low to medium cost during the development cycle, you can classify this item as a
Must Have.
If, on the other hand, an item does not provide much benefit to the users and is difficult or costly to
implement, then it should be excluded from the project at this time. It does not mean that in the future it will not
be included; it just means that right now it is a Not Now item.
More
Not Now
Nice to Have
Nice to Have
Must Haves
Less
More
Benefit to Users
Figure 3-2. A four-quadrant prioritizing matrix
If an item provides a lot of benefit to the users but may be costly or difficult, then it is something that will
be considered Nice to Have but may not be absolutely necessary to the solution. As such, evaluate these Nice to
Haves carefully before including them in the current solution. Once again, this does not necessarily mean it will
never be part of the BI solution; it just may not be part of the current version.
Be careful of the final quadrant, in the lower left of Figure 3-2 . The items in this quadrant are very easy to
implement but provide little to no value for the users. This is a very attractive quadrant because these items will
keep you quite busy implementing them and will make you feel as if you are really accomplishing something.
In the end, however, it will not benefit your BI solution much, and most clients find it frivolous. Few will feel it
pertains to their needs; and consider the fact that if they are paying for your work, they do not want to pay for
something for which they did not ask. This particular quadrant is the one that is responsible for the dreaded
demon of developers known as feature creep . As we say in the field, “When in doubt, leave them out!”
Additional Considerations for Determining What You Will Build
Both the interview process and the examination of current reports and documentation should provide you with
a good understanding of what will benefit the users. Identifying the cost involved, however, can be quite a bit
more difficult to determine. For example, you may have to consider the ease of use of the current networking
 
Search WWH ::




Custom Search