Challenges Of Implementing Evidence Based Practice In IT Projects

Significance

Discuss about the Challenges of Implementing Evidence Based Practice.

There has always been a disconnect between what IT systems do and what they were envisaged to do (Lyon, n.d.), (Wrubel, 2014). The customers do not always get the outcomes they desired from IT systems, despite a disproportionately large amounts of time and resources dedicated towards defining user requirements, following of the standard and fitting processes in developing the IT systems, and focusing on the functional characteristics of the IT system (Hillestad et al., 2005), (Kaplan and Norton, 2005). This has prompted a shift among researchers and stakeholders from focusing on the product and its functional capabilities through the process of development to the effects and outcomes of the IT project. This paradigm shift is term evidence based development; where the effects and/ or outcomes of IT projects determine and define the process of their development. Evidence based development (EBD) is a paradigm in which contractual agreements and the interaction between IT system vendors and customers is defined by the effects/ outcomes of the IT projects delivered.

It is a shift from product functionality development of IT projects to a user centered design (UCD) (Dressel and Srivatsav, 2015). UCD (sometimes called UDD (user driven development) is a process framework in which user characteristics, usability goals, tasks, environment, and work-flow of a product, process, or service, is given extensive focus in every stage of the development process (Göransson, Gulliksen and Boivie, 2003). In the context of UCD, this paper reviews and critiques the new paradigm of evidence based development in IT projects as put forth by Hertzum and Simonsen ; it begins by stating the significance of the problem that has necessitated its (EBD) introduction into the mainstream and why it is an important area for research and study. The paper then discusses evidence and arguments to support their position and how convincing these arguments are; the discussion then delves into counter evidence in relation to the authors’ works. The paper then goes on to discuss the implications of the authors’ thesis and position to the software development community, its implications to the author and how the authors sees how the new paradigm can be applied at the workplace; the paper then makes a conclusion.

Vendors and developers usually develop software that have the functionalities that can satisfy the user requirements. This process usually commences with a capturing of customer user requirements before a prototype is developed and the final product developed based on user feedback (Göransson, Gulliksen and Boivie, 2003). As the authors allude, while this process has been used extensively, it has pitfalls because much focus is placed on the product and process rather than the effects of the IT system/ project (Hertzum and Simonsen, n.d). Agile development, for instance, entails capturing of the user requirements both at the high level and piecemeal level just in time to enable each feature to be developed. However, the method is just barely enough (Waters, 2007). however, as the authors further state, there should a shift from product and process based interaction between consumers and vendors in IT projects to a measurable, evidence based UCD for IT projects development and delivery. This is still a new area of research that seeks to provide an alternative approach and view that promises, on the evidence of present research and hypothesis by the article authors, a better approach to IT projects where there is cooperation and UCD and that lower costs and risks for the customer while performing the functions that add value to the customer.

Evidence

The traditionally considered ‘best’ approaches to IT projects/ systems development still have some serious flaws and pitfalls in as far as consumer satisfaction is concerned (Turk, Rumpe and France, 2014), (Brandon, 2008). The proposed method is therefore significant in providing new insights on how IT projects can benefit the consumer more and provide a platform by which tangible effects of IT projects can be measured and used as the basis for payments while also being the loci of the interaction between the consumers and vendor(s); rather than the use of technicals like the development process and the product functionalities. The concept can be likened a car; the consumer and vendor do not have a contract based on technicalities like the development process and its functionalities, instead, focus is placed on what the effects the car has; its acceleration, top speed, fuel consumption, comfort, torque, safety, and reliability, among others. Te concept of EBD in the context of UCD is therefore important in providing a new paradigm and method of IT projects management and development that actually add value to the customer and forces vendors to spend more time on creating value adding effects in IT projects.

The authors (Hertzum and Simonsen, n.d), argue that while vendors follow the laid down procedures during IT projects and place focus on functionality, the customer does not always get what they need. This is evidenced by many cases where customers reject IT project deliveries because it does not provide the envisaged effects and outcomes. They use new paradigms where the same concept has been used, in IT procurement using the case study of the California Franchise Tax Board where performance based procurement was used by a large IT customer to mange their relations with software vendors with the main objective of sharing risks and accomplished through performance based payments. In the case study, the vendor is paid only if the benefits defined in the contract are realized by the customer after the implementation; the benefits include operational savings, cost avoidance, and increased income).  To implement the mode, there is an extensive pre-project phase where effects are defined and documented and form the basis for the contract, all at the vendors’ cost. This ensures the vendor  places the due commitment to the IT project and focus on the effects rather than on the product of process. In a case study lasting a year, the authors review a case of home care providers where they tackle and give evidence that measuring the effects can actually be easy because this has been and continues to be a major concern for IT stakeholders; how do you define and quantify effects/ outcomes?  
For instance, the authors propose measurable effects be formulated for the home care IT project as using percentages to measure effects; for example, documentation of compliance with a certain procedure is 95% of the cases. While presenting their evidence though, the authors remain cognizant of the challenges of operationalizing the concept of EBD in the context of UCD; that while challenges remain, they can be overcome if there is a will among stakeholders, especially vendors.  The points put forth are very convincing; for example, compliance must be 95% with a certain procedure. In everyday life, this is how most transactions occur; that an airplane must, for example, carry a passenger across the Atlantic within 8 hours and land at the scheduled time. However, because software is intangible, defining tangible/ measurable benefits that is accepted by all stakeholders and partners still remains a challenge, based on the findings and arguments of Titler, (2008) and Farley et al., (2009). while the author avers that such an approach is interesting and would help create greater value and synergy between customer and vendor, quantifying effects and outcomes for IT projects can be a challenge; though these challenges can be surmounted.

Implications for Software Development

This paper has no doubt stirred the ‘hornets nest’; on the one hand, the customers will see it as a panacea to a long held practice in which their contract with the vendors is based on technicalities and process while the software development community will see it as a  largely impractical approach to interaction with customers.  The software development community will be likely jolted from long held beliefs and traditions where they defined how they interact with consumers through technicalities and knowhow to a new truly UCD where payments are paid for benefits rather than processes and technicals. Development. For the author, this paper provides a refreshing and highly inventive approach to risk sharing, UCD, and what I believe is the right and fair process for software development that will truly add value to consumers. It provides me with a new way of thinking and new knowledge that is not only empowering (from the customer point of view), but also sweetly challenging to software development where customers needs are actually met rather than offering customers functionalities and processes that ‘can’ meet their needs but in most cases, usually does not. My views as a result have greatly changed and challenged at the same time; that vendors have been the greatest beneficiaries in IT projects while the customer has received the short end of the stick. It has also changed my views about cooperation and synergy that will eventually benefit the vendors and consumers in a symbiotic way and will add value to IT projects and allow more equitable risk sharing between vendors and customers. I will apply these principles at the workplace or organization where payment is made for benefits and outcomes rather than for technicals, processes, and functionalities, that in many a case do not add value at all.

Conclusion

Customers usually do not receive what they want or what adds value to their organizations in IT projects, as evidenced by many rejected IT project deliveries. The authors provide a new paradigm on the best way to share risks and ensure customers get what they want; what adds value to them through the use of evidence based development. Using examples of the  California Franchise Tax Board and using a case study, provide real life and viable examples of where the concept can be applied. However, the authors are cognizant of the possible challenges, including how to quantify effects and if all stakeholders will accept them. The new paradigm is likely to throw vendors into a spin initially, but eventually their will embrace it and customers will quickly embrace the concept due to the risk sharing and its cost-effectiveness. Personally, I think its a fresh new concept that deserves a chance and that I am ready to apply in my organization.

References

Brandon, D. (2008). Software engineering for modern Web applications. 1st ed. Hershey, Pa.: IGI Global (701 E. Chocolate Avenue, Hershey, Pennsylvania, 17033, USA).

Dressel, C. and Srivatsav, N. (2015). Evidence-Based Design: an approach to better projects and  happier teams. [online] Medium. Available at:    https://medium.com/@impossible_labs/evidence-based-design-an-approach-to-better-    projects-and-happier-teams-40532e6ed425 [Accessed 6 Apr. 2017].

Farley, A., Feaster, D., Sar, B., Oak, S., Bruce, L., D’Ambrosio, J. and Schapmire, T. (2009). The     Challenges of Implementing Evidence Based Practice: Ethical Considerations in Practice,     Education, Policy, and Research. [online] Socwork.net. Available at:     https://www.socwork.net/sws/article/view/76/335Conceptually [Accessed 6 Apr. 2017].

Göransson, B., Gulliksen, J. and Boivie, I. (2003). The usability design process – integrating user-    centered systems design in the software development process. Software Process:     Improvement and Practice, 8(2), pp.111-131.

Hillestad, R., Bigelow, J., Bower, A., Girosi, F., Meili, R., Scoville, R. and Taylor, R. (2005). Can     Electronic Medical Record Systems Transform Health Care? Potential Health Benefits,     Savings, And Costs. Health Affairs, 24(5), pp.1103-1117.

Kaplan, R. and Norton, D. (2005). The Office of Strategy Management. [online] Harvard Business     Review. Available at: https://hbr.org/2005/10/the-office-of-strategy-management [Accessed     6 Apr. 2017].

Lyon, B. (n.d.). How to Ensure Strong Customer Service and Customer Satisfaction. [online]     Managementhelp.org. Available at: https://managementhelp.org/customers/service.htm     [Accessed 6 Apr. 2017].

Titler, M. (2008). Patient safety and quality: Chapter 7The Evidence for Evidence-Based Practice     Implementation. 1st ed. Rockville, MD: Agency for Healthcare Research and Quality.

Turk, D., Rumpe, B. and France, R. (2014). Limitations of Agile Software Processes. Third     International Conference on Extreme Programming and Flexible Processes in Software     Engineering, 3(1), pp.26-30.

Waters, K. (2007). Agile Principle 4: Agile Requirements Are Barely Sufficient | All About Agile.     [online] Allaboutagile.com. Available at: https://www.allaboutagile.com/agile-principle-4-    agile-requirements-are-barely-sufficient/ [Accessed 6 Apr. 2017].

Wrubel, E. (2014). Agile Software Teams: How they Engage with Systems Engineering on     Department of Defense Acquisition Programs. [online] Insights.sei.cmu.edu. Available at:     https://insights.sei.cmu.edu/sei_blog/2014/11/agile-software-teams-how-they-engage-with-    systems-engineering-on-department-of-defense-acquisition-p.html [Accessed 6 Apr. 2017].