DSS News
                 D. J. Power, Editor
          April 23, 2006 -- Vol. 7, No. 9

    A Free Bi-Weekly Publication of DSSResources.COM 
         approximately 1,600 Subscribers 

       "Decision Support for Global Enterprises"


* Ask Dan! - What are the rules for building a successful
model-driven DSS?
* DSS Conferences
* DSS News Releases 


   Check the case by Mike Tully, "E-Docs Asset GIS: 
     Washington County, Iowa" at DSSResources.COM


Ask Dan!

by Dan Power
Editor, DSSResources.COM

What are the rules for building a successful model-driven DSS?

It is important to discuss what impacts the success of computerized
Decision Support Systems. My DSS book (2002) discusses 5
recommendations for finding success in building data- and
document-driven DSS (p. 137). In general those recommendations hold
for model-driven DSS as well. My recommendations included 1) identify
an influential project champion, 2) prepare for technology shortfalls,
3) tell everyone as much as you can about the costs of creating and
using the proposed DSS, 4) invest in training, and 5) market and
promote the new DSS.

Other authors have written on this topic in the context of building
model-driven DSS. In a 1978 book, Andrew McCosh and Michael Scott
Morton discussed some rules for building successful decision support
systems. I must confess I didn't read their book until 2004 when I
bought a used copy at I had read material from both
authors, but not this book. Based upon a "quick" read, much of the
material on technology and the examples of DSS are dated, but the
conceptual material still seems useful and relevant. In this column
I'll share, update and supplement McCosh and Scott Morton's rules
(see pages 217-218). 

"The first rule is keep it simple. Attempts to handle problems which
are outside the experience of the people involved are bound to fail
no matter what expertise they bring to bear on them. Attempts to jump
immediately from a very straight forward procedure ... to a
computer-based solution which deals completely with all aspects of
the solution are equally pre-doomed." This rule is similar to the
KISS principle of design that prescribes avoiding unnecessary
complexity, "Keep it Simple, Stupid" or "Keep it Small and Scalable".
But McCosh and Scott Morton emphasize that DSS designers need to have
experience with making the decision and the existing process prior to
designing computerized support.

"The second rule is tackle significant problems. It is vastly more
meritorious to make a simple model that provides a small step toward
solving a problem that is strategically important to the overall
success of the organization than to produce a sophisticated,
mathematically complex model which totally solves a triviality." Some
examples of significant problems for DSS from McCosh and Scott Morton
circa 1978 include a profit planning support system, budgeting,
financial analysis of merger opportunities, and pricing decisions.

McCosh and Scott Morton focused on model-driven DSS and their rules
demonstrate the tension between DSS theorists and Operations Research
and Information Technology professionals. They argue in rules 3 and 4
"don't let the computer people design the model" and "don't let the
operations research staff design the model." The issue is, who should
"design" the model in a model-driven DSS? McCosh and Scott Morton's
rule 5 states "the manager who is responsible for the subject should
be the person who designs the model in its gross form using such help
and specialist guidance as he needs." I agree managers must have a
sense of ownership of any DSS and especially DSS with a prescriptive
model. DSS designers, whether they have been primarily trained in
operations research/management science, computer science or software
engineering need to understand and involve the targeted users of the
proposed DSS in its design.

Rule 6 states "use the staff people to make the model, interacting
continuously with the manager as they go." Rule 7 is to "test the
model and adjust it." Finally, rule 8 is a corollary of rule 1.
McCosh and Scott Morton note "while initial simplicity is essential,
it also implies that the manager will, with experience, want more
complex models built." Rule 8 "regard the replacement of models by
better ones as evidence of vitality, not of earlier errors." After
almost 30 years of DSS development many simple models have probably
been replaced. So where are we today?

Rule 1: Novel, innovative model-driven Decision Support Systems
should be initiated by the managers who would use them.

As technology and circumstances change, we can expect that managers
will have ideas for "new" model-driven DSS. The advent of handheld
computers and wireless technologies are examples of technologies that
managers may choose to adopt for decision support.

Rule 2: Users and technical specialists should periodically review,
evaluate and adjust existing model-driven Decision Support Systems.

Many model-driven DSS are "legacy" applications that potentially
could be upgraded and improved.

Rule 3: Decision Support System projects must meet a need and provide
benefits that justify the ongoing cost of operating, maintaining and
upgrading the system as well as the cost of building them. 

While the most strategically significant DSS projects should still
receive the highest priority, many potential DSS applications are now
feasible that would not have been cost effective in 1978.

Rule 4: Model-driven DSS should be built by teams that include
potential users and technical specialists.

Conceptualizing a model in its "gross form" for a model-driven DSS is
not the major issue it once was. We understand various categories of
models much better than we did 30 years ago. Using heuristic models
peculiar to a specific manager is a different matter. If a manager
wants to build such a model, they need to help a model builder
understand the relationships and rules they want to use in making a
specific decision. Such models should then be tested and validated.

Rule 5: In every case, all things being equal, choose the path of
least resistance when building and implementing DSS.

This final rule is troubling to me and I doubt if it is necessarily
true for building successful DSS. I include it to create some
controversy. What do you think?

Perhaps this Ask Dan! will stimulate discussion about factors that
lead to success in building Decision Support Systems of all types. As
always your comments and suggestions are welcomed. Many thanks to
Andrew McCosh and Michael Scott Morton.


McCosh, A. and M. S. Scott Morton, Management Decision Support
Systems, Macmillan Press, 1978 (1980 reprint).

Power, D. Decision Support Systems: Concepts and Resources for
Managers, Westport, CT: Quorum/Greenwood, 2002.


         Purchase Dan Power's DSS FAQ book 
  83 frequently asked questions about computerized DSS 


DSS Conferences 

1. Crystal Ball User Conference, May 1-3, 2006 at the
Westin Tabor Center in Denver, Colorado. Check .

2. ISCRAM2006, the Third International Conference on Information 
Systems for Crisis Response and Management, Newark, New Jersey, USA, 
at the New Jersey Institute of Technology from May 14-17, 2006.
Check .

3. ICKEDS 2006, the Second International Conference on Knowledge
Engineering and Decision Support, Lisbon, Portugal, May 9-12, 2006.
Check .

4. CIDMDS 2006, International Conference on Creativity and
Innovation in Decision Making and Decision Support 
sponsored by IFIP WG 8.3, June 28th - July 1st 2006, London,
UK. Check .

5. DEXA 2006, 17th International Conference on Database 
and Expert Systems Applications, September 4-8, 
2006, Krakow, Poland. Check .

6. ICDSS 2007, 9th International Conference on DSS, Jan. 2-4, 2007, 
Calcutta, India. Theme: Decision Support for Global Enterprises.
Check . Papers due May 10, 2006.


    Visit; Support our advertisers
                   Advertise here!


DSS News Releases - April 9, 2006 to April 22, 2006
Read them at DSSResources.COM and search the DSS News Archive

04/21/2006 Internet2 announces winners of the first annual IDEA

04/19/2006 Oracle delivers unparalleled innovation and functionality
in Oracle(R) CRM On Demand release 10.

04/19/2006 MicroStrategy announces availability of inexpensive
business reporting software.

04/18/2006 Cognos 8 BI named a finalist for 2006 eWEEK Excellence

04/17/2006 New Risk Solver™ engine offers interactive
simulation, making risk analysis as easy as "What If" in Microsoft

04/17/2006 Centennial anniversary of San Francisco quake prompts IT
professionals to prepare for natural disasters.

04/13/2006 New CIO confirms Wal-Mart commitment to RFID; Rollin Ford
pledges to stay the course of his predecessor.

04/13/2006 Fair Isaac SmartForms for Blaze Advisor 6.1 makes Web
Forms more intelligent, easier to use; upgrade integrates AJAX
technology with business rules to streamline processing of
customer-facing decision applications.

04/13/2006 SPSS receives Frost & Sullivan award for Industry
Innovation and Advancement in Predictive Analytics.

04/12/2006 Micro Center selects MicroStrategy for enterprise
reporting and analysis.

04/12/2006 TIBCO delivers new SOA integration, orchestration

04/11/2006 SAIC establishes Emergency Mapping and Analysis Center.

04/10/2006 Business Objects selects OpSource to support on-demand
business intelligence solution.

04/10/2006 Patient Care Technology Systems participates in demo of
wireless locating and tracking at TEPR 2006.

04/10/2006 Business Objects introduces Crystal Reports On Demand; new
on-demand Business Intelligence solution gives small and mid-sized
customers an instant, simple, and secure way to share critical

   Please tell your DSS friends about DSSResources.COM


 DSS News is copyrighted (c) 2006 by D. J. Power. Please send your 
questions to

DSS Home |  About Us |  Contact Us |  Site Index |  Subscribe | What's New
Please Tell 
Your Friends about DSSResources.COM Copyright © 1995-2021 by D. J. Power (see his home page). DSSResources.COMsm was maintained by Daniel J. Power. See disclaimer and privacy statement.