In my experience with implementation plans, I have found that there needs to be a fair level of detail in order to ensure project success. The implementation should be divided into phases that detail who will complete each activity, a timeline for each activity’s completion, and when the the activity has been completed. Each activity should be defined using a standard work breakdown structure (WBS) methodology.
I have found that mostly the vendor has a standard WBS with project phases that is adaptable per to each organization. As the vendor knows the software the best (i.e., tech requirements, past successes and failures of implementation), it should be written in to the request for proposal (RFP) that the vendor include the standard implementation documentation along with their response. By reviewing each of the vendors proposed implementation plan, the organization will be better prepared for allocating resources, planning technical purchases, and scheduling the project.
By having a detailed implementation plan in hand prior to the final vendor selection, the organization will be better prepared to know actual costs of the implementation and planning the application launch. Some of the pros and cons of having a detailed implementation plan include:
Pros for Detailed Implementation Planning
1. Detailed planning details individuals. A detailed implementation plan should include the specific activities associated with at each phase of the project. A detailed plan should include the identity of the individual(s) responsible for completing the work. This is an advantage for the project manager, as the project manager will know who to check in with during implementation.
2. Detailed planning facilitates better time management. By compiling a detailed plan of all theproject activities, a more accurate project schedule can be created. As many organizational IS resources, vendor resources, and departmental resources have to be scheduled and budgeted for; the more detail the plan, the more accurate the project schedule.
3. Detailed planning for better project implementation reporting. During the implementation of the project, it is important for the project manager to update the project sponsor as to the progress of the project. By having a detailed plan, reporting project status is easier for the project manager.
4. Detailed planning facilitates better communication. As the project manager will need to keep track of the completed activities of the project, having a list that details who is doing what will be very useful when the project manager when he/she needs to get project updates.
Cons for Detailed Implementation Planning
1. Detailed implementation plans take time to prepare. A standard breakdown of project activities and phases may exist from the vendor, but these will have to be customized for each organization. This type of planning can take a long time and details that address the project resources and schedule can sometimes be hard to accurately estimate.
2. Detailed implementation plans are subject to change. During theimplementation planning phase and the actual implementation, many changes may have occurred, which will be a burden for the project manager to maintain these changes.
3. A detailed plan may not be necessary. For custom-built IT solutions, detailed plans may not be feasible. For IT projects that entail a customized software be built, it may be better to use a Kanban or Agile project methodology that would not require detailed implementation plans.
Developing a taxonomy for choosing which system development methodologies or strategies an organization will use to decide of which information system to implement is much like deciding which equations one might choose to solve an algebra problem. While there are many ways to arrive at a solution, there are many rules to choose from. Many variables must be collected and evaluated before deciding on an optimal methodology or strategy.
According to Whitten & Bentley (2007, p. 92), three considerations need to be analyzed prior to deciding on a system development methodology or strategy. The three considerations are:
- If the methodology is product-driven, is a prototype to be built or is code going to be written?
Organizations using this evaluation method will be better positioned to decide on which system development methodology or strategy to use when implementing an information system. Where this strategy fails is that is does not consider the information system’s return on investment (ROI), employee usability, alignment with corporate culture, or reasoning behind the purchase. It is also important to conduct a thorough investigation of the viability of the information system companies that are under consideration, by evaluating publicly available information.
Whitten & Bentley (2007, pp. 77-78) also suggest conduction the PIECES Problem-Solving Framework Checklist, prior to deciding on a methodology. The PIECES method includes:
Whitten & Bentley (2007, p. 94-104), suggest the following additional methodologies:
System Development Methodologies for a Large Community Hospital
Model-Driven Development Strategy
As a large community hospital is likely to have a host of existing systems, the model-driven development strategy would be a good systems development approach. According to Whitten & Bentley (2007, p. 94), the model-driven development strategy includes more commonly known methods that may make implementation easier than other methods. This method requires a good deal of planning and when implementing a new system, this is a good thing. A model-driven development strategy also allows for more thorough documentation, easier validation and conceptualization as models are visualized, and better built systems as they are more thorough diagrammed the first time compared to other strategies (Whitten & Bentley, 2007, p. 96).
System Development Methodologies for a Private Physician Practice
The Commercial Application Package Implementation Strategy
Regardless of the EHR System a private physician practice decides to implement, in most cases some degree of customization is likely to occur. But for the most part, existing commercial EHR systems will be ready for small practices right out of the box. A CAPIS strategy would be an ideal solution as this allows for the submission of requests for proposal (RFPs) to reviewed by the physician practice (Whitten & Bentley, 2007, p. 101). CAPIS allows for rapid implementation as the heavy programming has already been done by the EHR vendor, requires less “in-house” development knowledge and expertise, and allows for a more cost effective solution as the system can be duplicated to multiple users (Whitten & Bentley, 2007, p. 103).
Agile Method/Spiral Model
EHR Vendors may also benefit from the use of the spiral model to decrease the risks associated with software development (Houston, 2011, p. 45). As prototypes are developed, risk analysis occurs iteratively, so the product develops on an evolving basis (Shelly & Rosenblatt, 2012, p.26). The agile methodology allows for rapid development and testing, and also allows for flexibility and responsiveness by developers (Shelly & Rosenblatt, 2012, p.26). The agile methodology may pose some challenges to EHR Vendors who are not familiar with the methodology. The Project Management Institute (PMI) offers an agile certification through its PMI Agile Certified Practitioner (PMI-ACP) certification (PMI, 2012). EHR vendors that utilize agile methodologies would benefit from acquiring professionals who possess this certification.
Other barriers to effectively implementing an agile methodology include a lack of structure that can introduce greater risk, increased scope creep, and an increased level of communication by all team members (Shelly & Rosenblatt, 2012, p. 26). Houston (2011, p. 45) argues that increased risk is not associated with an agile method/spiral model, as risk analysis can be conducted iteratively (see Figure 5-2).
EHR Vendors would also benefit from incorporating this methodology. As the various objects emerge when planning a new technology, having an O-O methodology will help when breaking down responsibilities to various in-house team members.
Implementing a new technology is a big undertaking for any organization. For some leaders compiling too much data can result in a “decidophobia,” a clinical fear of reaching a decisions (Useen, 2010, p. 514). Leaders that suffer from decidophobia can take advice from the U.S. Marine Corp and adopt a 70 percent solution, which states that if a leader “has 70 percent of the information, has performed 70 percent of the analysis, and feels 70 percent confident, he or she is instructed to decide” (Useen, 2010, p. 514).
Houston, S. M. (2011). The project manager’s guide to health information technology implementation. Chicago, IL: HIMSS.
Project Management Institute. (2012). PMI-Agile Certified Practitioner (PMI-ACP)SM Pilot Program. Retrieved August 22, 2013 from http://www.pmi.org/certification/new-pmi-agile-certification/pmi-agile-certification-pilot-program.aspx
Shelly, G. B., & Rosenblatt, H. J. (2012). System analysis and design (9th ed.). Boston, MA: Course Technology - Cengage Learning.
Useem, M. (2010). Decision making as leadership foundation. In N. Nohria & R. Khurana (Eds.), Handbook of leadership theory and practice (pp. 507-525). Boston, MA: Harvard Business Press.
Whitten, J. L., & Bentley, L. D. (2007). Systems analysis and design methods. (7th ed.). New York, NY: McGraw-Hill/Irwin.
This work is licensed under a Creative Commons Attribution-NonCommercial- ShareAlike 3.0 United States License.
Christopher M. Bell