What is the process for designing decision support software?
by Dan Power
Recently, I received an email from Michael Brito asking if I "could explain the process for designing decision support software". I have also been following an email thread started by David Trevvett, Senior Director NSIT/Administrative Systems, University of Chicago, on the EDUCAUSE Constituent Group discussion list. David is exploring how to organize for BI. He is "taking advantage of some recent turnover ... to rethink, and maybe redefine and reorganize our data warehouse/business intelligence development and support, and would like to know what others have found to be 'best practices'."
My email answer to Michael was "Actual Decision Support applications are often developed using a development software product using rapid prototyping or 'incremental' design. Large scale data-driven DSS may be developed more systematically using a SDLC approach".
As far as organizing for BI in a University setting, how a DSS task group is organized depends upon the maturity of current data-driven DSS applications and upon how much maintenance they require and the aspirations for developing novel DSS applications in performance monitoring, budgeting or enrollment forecasting. Also, it is important to ask "What is the purpose/mission of the DSS group?" David had some specific questions like "Should the head of this group be at the director or the associate director level?" IMHO if you want DSS/BI to be taken seriously, then the manager/leader should be at the director level. The person needs visibility and control of "significant" resources. "What functions should comprise a DSS/BI unit?" My advice is to unify the DSS/BI design, development and maintenance tasks under one leader including new systems/applications design, data modeling, data warehouse administration, ETL definition and support, metadata development and maintenance, report/query development, Web-based DSS and Web server administration, end user training and end user consulting.
For those interested in DSS/BI in University settings, I recommend reading the case study at DSSResources.com by Peter Barton, Manager, Data Administration, The George Washington University. Barton's case study documents his experience leading a data-driven decision support project in a University environment.
In general, the organization of the DSS/BI group impacts the DSS design process, but the purpose of the proposed DSS has an equally large impact. My DSS book (2002) has a chapter on Designing and Developing Decision Support Systems. The Web-based DSS Hyperbook (2000) at DSSResources.com also addresses this topic.
A good way to learn about DSS design is to work through mini-cases or exercises alone or in a small group. For example, imagine that you have been asked to design a decision support system to assist middle managers and especially senior administrators at a public University in their decision making. They want you to "deliver key performance metrics to targeted end users on-demand and at their desktops".
The task description reads something like: University administrators are increasingly being held accountable for how funds are spent and the results or outcomes for students and other stakeholders. Ideally senior adminstrators should have one or more DSS to help in performance monitoring of key results areas, to generate ad hoc reports, to help in enrollment planning and forecasting, and to assist in budgeting and budget monitoring.
Following the work of Stabell (1983), I recommend using a decision-oriented design approach for building DSS and for analyzing mini-case exercises like this one. Stabell argues that pre-design description and diagnosis of decision-making is the key to securing a decision-oriented approach to DSS development.
So what questions should we ask in designing a DSS? Based upon a number of sources, including Kathryn Laskey's course page at George Mason University, I would recommend the following question list:
1. What decision processes, if any, need to be supported? How is the decision made currently? What information and analyses do decision makers use?
2. Who are the stakeholders of this proposed DSS?
3. How and when will the DSS(s) be used? Who are the targeted users? What is the projected frequency of use? Is a computerized analysis in a special study more appropriate than building a DSS?
4. How would you obtain user requirements and what approach would you use to obtain feedback from targeted users to ensure that the system meets their needs?
5. What is the operational concept or vision for the proposed system (in general terms)? According to a number of sources, the shared vision documents how the proposed system's stakeholders think the system will be "developed, produced, deployed, trained, operated and maintained, and refined to overcome some operational problem and achieve the stakeholders' operational needs and objectives". The operational concept should include a collection of scenarios.
6. What are 2-3 usage scenarios for the DSS? A usage scenario is a brief description (1-2 paragraphs) of a user interacting with the system to perform some task.
7. What are 4-5 major requirements for the proposed system?
8. What functionality should be the first priority to implement? Why?
9. What are the key initial development objectives? Why?
10. Do the current problem definition and operational concept capture the desires, needs and requirements of the targeted users?
11.a. If a data-driven DSS is needed, what data elements are important? What entities need to be represented? What relationships between entities need to be represented? Why? What are the sources for the data you identified?
11.b. If a model-driven DSS is needed, what are the quantitative models that need to be built? What data will be required? Why? What are the sources for the data you identified?
11.c. If a document-driven DSS is needed, what documents are important? Why? What are the sources for the documents you identified?
12. What are the pros and cons of different development environments?
13. How would you evaluate a DSS prototype developed in this situation? What criteria would you use for formative and summative evaluation?
14. What usage scenario would you implement in the first round of an iterative design or spiral design process? Why?
We all know that an organization does not receive any advantage from a great idea for a Decision Support System until the new system is built and successfully implemented and ultimately used by the intended users. Systems development involves three major steps: (1) initiation and diagnosis, (2) acquisition (build or buy), and (3) introduction of the new system. At the end of step 1, a feasibility study should be completed before the project proceeds. The above questions should help in diagnosis and in preparation of a feasibility study.
The development of a Decision Support System is often an undertaking of great complexity. Organizational decision processes are complex and computerizing decision processes sometimes increases that complexity. Using a structured methodology improves the chances that large-scale DSS will be successfully built and deployed. Ask questions and debate and discuss the answers with others before you build a DSS. A "good" DSS/BI/IT group should provide a sophisticated forum for analyzing proposed DSS. Also, a diverse project team that includes some targeted users can also improve the chances that a novel DSS will actually benefit an organization.
As always your comments and suggestions are welcomed.
Barton, P., "The George Washington University Data-Driven Decision Support Project", at DSSResources.COM (2003).
Laskey, Kathryn Blackmond, SYST 442/SYST 542/PUBP 550 Decision Support Systems Engineering course materials, Department of Systems Engineering, George Mason University at http://ite.gmu.edu/~klaskey/SYST542/
Power, D. J. Decision Support Systems: Concepts and Resources for Managers, Westport, CT: Greenwood/Quorum Books, 2002, ISBN: 156720497X.
Stabell, C. B., "A Decision-Oriented Approach to Building DSS," in J. L. Bennett, Building Decision Support Systems, Reading, MA: Addison-Wesley Publishing Company, 1983.
Last update: 2006-10-22 16:55
Author: Daniel Power
You cannot comment on this entry