Every week, I'm asked by customers to collaborate with them to choose new applications.
Here's how we do it.
1. First, we take an enterprise view of each application request, since we would much rather consolidate applications and reduce the number of vendors than provide a new niche application for every evolving departmental need. If an existing enterprise application cannot meet the user's requirements, we then survey the marketplace.
2. We do not believe in Requests for Proposals (RFP). RFP means Request for Prevarication, since most vendors do their best to answer RFPs with as many positive responses as possible. Instead, we review the marketplace, often via the web and and by reviewing summary evaluations from KLAS reports. We pick the three or four applications which seem to best meet our stakeholder functionality requirements.
3. Once we have a small number of applications identified, we evaluate them for their suitability in our infrastructure environments using a formal process. In 2003, we created a Change Control Board to orient the infrastructure team to new applications that are being proposed. The forum meets weekly and has broad representation, including help desk, desktop, servers, storage, networking and security staff. The checklist of issues we review is here. Note that this screening sheet evolves as technologies evolve. Two years ago, we would not have asked about compatibility with VMWare/Virtualization technologies. Also, this list is expanded to address those issues arising from bad experiences, so we do not repeat them.
4. Once an application is approved for suitability in our infrastructure environment, application teams then work collaboratively with our customers to
a. Manage all vendor relationships including scripted demonstrations, contract negotiation, installation/training and life cycle maintenance of the application.
b. Manage integration with our existing applications. Typically this is done via our eGate messaging engine or via web services, since we have widely deployed a service oriented architecture.
c. Define service levels, a disaster recovery strategy, an escalation plan for issues, and division of labor for support of the application. Typically, IS manages the infrastructure and keeps the application running smoothly. Power users in the department document workflow and ensure the application's functionality is optimized to support that workflow.
Over the past ten years, we've found that this collaborative approach with IT, rather than having each department select its own applications, ensures stability, maintainability and scalability. At this point, most departmental IT systems and staff at BIDMC have been replaced by services from the central IT organization. It's a win/win for everyone, since costs decrease, quality increases, and the frustration of choosing an application which does not work in our infrastructure has been eliminated.
John,
ReplyDeleteThanks for sharing your application evaluation criteria. One gap though is that it will fit only when you are evaluating a pre-packaged product. in a custom development scenario i believe you will have to move towards a defined RFP and follow it up with a proof of concept/value if you will. it may be that you and team have completely ruled out custom building/enhancements of existing applications and i would be very interested to know the reasons if this is the case.
Thanks, Maloy
Hi John,
ReplyDeleteI admire the move you guys have made to a centralized IT service as I've seen how messy the alternative is. But how quickly can the central team address the needs of a small department while handling the needs of thousands of other users?
Thanks!
Bill
Great comments.
ReplyDeleteRegarding Maloy's comments, we build and buy, but when we build, we do it ourselves. If we were to outsource building, then we would need a detailed specification which would approximate an RFP. I agree that pilots/proof of concepts are important for externally built software.
Regardingg William's comments, I believe we've achieved a reasonable balance between central and local by ensuring local experts in departments prioritize central IT work via our governance processes. By keeping a staff of analysts centrally which do work prioritized locally, customer satisfaction is maintained.
As a SMB health care CIO, I appreciate your perspective and need to think about including my infrastructure people more in our application decision making process. Thanks for sharing. -Kevin
ReplyDeleteHi John,
ReplyDeleteSub: Selecting applications
Thanks for such great article / blog on application selection. I had several question in relation with application selection criteria. I hope and respect your time and will be glad if you can answer them.
My Scenario goes as below:
My present company is doing its business in Islamic banking and finance. Hence forth we have very limited choice in application selection. The present core banking solution which is home grown has become far old to cater those requests.
My question is how you select applications when available options in the market do not adhere with complete functional requirements of the project against time + resource.
Many times vendor proposes application which does not adhere to complete functional requirement. And if they do lucrative presentation to the functional owners and promise all the delivery, users fall trap to their ploy and often selects those applications.
We had come across several issues in post implementation support. How you cater this kind of practical problems. How you can manage these issues when application selection is being done?
Thanks