What factors impact decision support project implementation risk?
by Dan Power
Editor, DSSResources.com
Managers should contemplate a wide range of decision support projects. Perhaps an enterprise-wide, data warehouse-based DSS to improve reporting and analysis, a knowledge-driven DSS project to increase staffing fairness and consistency, or a web-based, model-driven decision support tool to reduce stockouts and minimize obsolete inventory. Decision support projects have varying risk levels and differing risk/reward tradeoffs. Managers must assess project risk issues. So what controllable factors impact DSS implementation risk? Project scope and project structure.
In a 2003 DM Review comment, Sid Adelman provided a laundry list of 20 factors in response to "What are the major risk factors in a data warehouse project implementation?" He listed: 1. Unrealistic user expectations, 2. No management commitment, 3. Unrealistic schedules, 4. Budget too small, 5. Untrained staff, 6. Staff not available when you need them, 7. Poor project management, 8. Not properly architected, 9. Exceeding platform capabilities, 10. Inappropriate organization structure, 11. Scope creep, 12. Changing requirements, 13. Changing priorities, 14. Sponsor leaves the project, 15. Database too big, 16. Data cleansing underestimated, 17. Vendors out of control, 18. New technology not understood, 19. Users not available when you need them, and 20. No procedure to settle disputes.
Adelman's factors increase the risk of budget overruns, time delays, and failing to meet objectives for any type of decision support project. If we analyze the 20 factors, we identify two broad, aggregated factors that impact implementation failure risk: 1) project SCOPE and 2) project STRUCTURE (cf., Power, 2002). Scope refers to the breadth of purpose of the DSS, anticipated project budget size, the anticipated number of end users, and the number of organization units impacted. For example, enterprise-wide DSS projects have broader scope than department projects. Structure refers to task clarity and specificity, how well IT staff and managers understand the proposed DSS and how well they have planned the project. For example, clarity of objectives, a realistic project schedule, and the project manager's experience impact project structure.
In general, user expectations, budget, architecture, project requirements, priorities, technology understanding, and database size all impact our assessment of project scope. Management commitment, schedules, staff training, project manager skills, organization structures, and procedures all impact project structure.
DSS projects have various levels of risk associated with them. When DSS projects have ambiguous objectives and low structure, the projects have higher levels of risk of failure because the costs and scope of work of the project are harder to define. Also, because the objectives of the project are ambiguous, it can be difficult to assess the return on the investment. DSS projects with a higher degree of structure and more clearly defined objectives generally are lower risk and more likely to be successfully completed. Also, more detailed planning is possible for projects with specific objectives. The scope of a DSS project in terms of the number of users served and the size of databases developed also impacts the risk of the assessed projects. Small DSS projects in terms of scope or dollar expenditures tend to be lower risk than large projects. Reducing project risk is one reason we use pilot projects. Finally, the sophistication of the technology and the experience of the developers using the technology influences the overall project failure risk. Innovative decision support inherently has moderate to high failure risk.
If project scope and structure are considered in a 2X2 matrix, then low scope and high structure projects have low risk. High scope and low structure projects have high levels of risk. The other two situations generally have more moderate levels of implementation risk. See Figure 1 "Project Implementation Risk Matrix".
1. How much project and project portfolio risk can the organization accept, tolerate and manage?
2. Have targeted users helped define project requirements and scope?
3. Does the project have a strong, committed internal sponsor?
4. Do internal staff understand the proposed technology?
5. Does the budget include contingencies for unanticipated costs, especially infrastructure and process change costs?
6. Is the project plan and schedule understandable and reasonable?
7. Is the project manager experienced with similar scope projects?
8. Has a feasibility study been completed for the project?
Minimizing implementation risks is critical for effective DSS project implementation.
The ultimate decision to invest in a DSS project should not be based solely on project risk. Sometimes, the DSS project that is most likely to result in a competitive advantage is a high risk project (cf., Applegate et al, 1996). If appropriately managed, even high risk DSS projects can be successfully implemented on time, under budget, and with the originally intended scope and functionality.
References
Adelman, S., "What are the major risk factors in a data warehouse project implementation?" DM Review Online, December 9, 2003, URL http://www.dmreview.com/news/7835-1.html .
Applegate, L., F. W. McFarlan and J. L. McKenney. Corporate Information Systems Management. Chicago, IL: Irwin, 1996.
Power, D. Decision Support Systems: Concepts and Resources for Managers, Westport, CT: Quorum/Greenwood, 2002.
Note: Sid Adelman is a principal in Sid Adelman & Associates (http://www.sidadelman.com/), an organization specializing in planning and implementing data warehouses, in data warehouse and BI assessments, and in establishing effective data architectures and strategies. He is a regular speaker at DW conferences.
Last update: 2008-08-15 10:24
Author: Daniel Power
Print this record
Show this as PDF file
You cannot comment on this entry
