Vendor management is a demanding part of the entire business software implementation planning process and should be delegated to someone within the organization who understands the overall plan. This person will manage the various parts of the process and those that are responsible for each part. If your organization doesn’t manage the process, you cannot expect the vendor to comply with the many requirements of the organization. Having a written contract with your vendor identifies the legal responsibilities, but it is up to your organization to make sure the daily operations, within the scope of service, are performed properly. This is not a function that can be effectively delegated to the vendor.
During this phase, you should identify who will assist the organization with building databases and data dictionaries. These tools will help make sure all end-users use the same vocabulary or at least understand each other’s vocabulary. Unfortunately, many times I have experienced client organizations during the operational assessment phase that did not know in advance that their end-users had different terminologies for the same processes, forms, or equipment. Knowing these kinds of differences between end-users will be instrumental when configuring the system to accommodate those differences. In those cases where the system cannot accommodate the differences, you will need to invest time in educating your employees in a common terminology. Since a system can only be as good as the information put into it, you need to ensure that information is consistent and correct.
The vendor will usually have a project manager to coordinate and monitor the implementation of their system. It is equally important that your organization have its own project manager to monitor progress with the best interests of your organization in mind. If there is no qualified person within your organization available to perform this function, you can use an external management consultant to manage the project on your behalf. However, this management consultant must have no vested interest in the vendor organization so he/she can manage the implementation objectively.
The project manager will monitor assigned tasks, responsible parties for those tasks, deadlines, timelines, budget, human resource allocation, reports to stake holders, etc. Although the project manager does not have to be part of the executive leadership team, I highly recommend that he/she at least have the authority to ‘move mountains’ on the project and not just the responsibility. The relationship between the vendor project manager and the organization’s project manager will be very instrumental to the success of the implementation.
Some organizations expect the same person to fill the roles of both vendor management and project manager. I personally feel this is a mistake. Both roles are extremely demanding, but require different skill sets. The vendor manager will focus on the human side of the implementation, rallying the troops, interacting with management, and overseeing the relationship with the vendor. On the other hand, the project manager is more concerned with deadlines, progress reports, status meetings, and keeping things moving according to the plan. No one person can do all of that and do it well.
Identify in advance who will be responsible for staff training pre-, during, and post-implementation. I have had clients assume the vendor would be responsible for post-implementation training; not realizing training was an additional expense. I’ve also seen situations in which the executive leadership assumed the internal IT department could handle training. In these cases, I can only think, ‘you get what you pay for.’
Additionally, you should know who will be responsible for database revisions. This is particularly important if system changes are affected by regulatory or accreditation standards. It’s imperative that you identify what support is available post-implementation, as well as the timelines involved. Many organizations will try to cut corners in the support area, but this almost always has a negative impact on daily operations of an organization already stressed over learning a new system.
Identify in advance who will be responsible for documentation, audit trails, and report writing tools. I recently had a healthcare client who did not know in advance that the new electronic health record system would not be able to produce the financial information the county required. To save money, the facility had not purchased the necessary module. Not unexpectedly, the vendor didn’t consider this problem its responsibility. The vendor had provided the hospital exactly what the contract required. As a result, the organization had to contract an external consultant to manage the database and write the required reports. These are situations that should have been addressed by the system selection criteria at the very beginning of the project.