Risks for IT Projects

Recently, I agreed to join a small group of organizations to help test a prototype of a reporting system. The contractors/software people hope to develop a web-based program that will meet some very specific requirements...mostly requirements set by a national organization that wants data and reports from local groups from around the country. The actual users, those who will have to input all the data, do get to do user-testing (hence, the small group that I joined). They will have a real say about how easy the program is to use. However, it doesn't seem like we will have much input as to what the program is actually intended to do.

Therefore, reading the Baccarini, Salm, and Love article this week, I started thinking about the risks involved in this project. As I read, a few potential risks really jumped out at me. First of all, under "technology and technical issues," "application software not fit for purpose," seems like a very likely problem (Baccarini, Salm, and Love 2004, 288). From everything I have seen of the proposed software, it *adds* work to the staff at the organizations, without actually adding any value. They will be able to create reports for the national organization, but they will not actually be able to manage their data with this program. Essentially, two databases will have to be maintained--one that lets the program do day-to-day work, such as tracking customer information, progress, etc, and one that is just used to fill out forms to be sent somewhere else. Much of the same information will have to be kept in both places. I would say that this would lead to "low user satisfaction." The program seems really easy to use, just a duplication of effort.

I think this stems from "Incomplete requirements," (Baccarini, Salm, and Love 2004, 288). The authors discuss how getting too little information during the analysis phase can lead to creating a product that doesn't meet objectives. In this case, I think the product is designed to meet the objectives of the bigger organization--I just don't see how they will convince local organizations to use it as it is currently designed. I know that they did have some discussions with the front-line users before putting any software together. However, I get the impression that once they realized the scope of what an organization really needs in order to manage its data, they shied away from that side of things.

Finally, I want to mention "developing wrong software functionality" (Baccarini, Salm, and Love 2004, 288). In this case, I don't think that it is so much a question of software that "may not meet the purpose for which it is intended," (288), but more that it won't meet the purpose for which it is expected by the front-line users. I think users will be told that this program will make reporting so much easier, and they will therefore expect it to make all reporting easier. However, it will really only be useful for the reports required by the one national organizaiton.

I hope that the group can all work together to develop something that really is a value to the local organizations and the national organization. They seem very willing to listen, but, like any project, they are limited by time and money.