What Your Vendors May Not Tell You
If you have any experience implementing enterprise software such as SAP or Oracle, you have most likely worked with an ecosystem of vendors to assist in the implementation. This includes the software vendor, a system integrator and niche vendors. Managing this ecosystem is complex and requires striking a balance between the vendors and your internal staff. Knowing how to best to motivate and manage these vendors will be critical to the success of your implementation.
Know your Vendors Business Model
To effectively manage your vendor, you have to know how they make money. For a software vendor, they make money on licensing, support, enhanced support, and services. For a system integrator, they make money on billing resources to you, but you need to understand how they title and assign bill rates to their staff, know if they have a global P&L or regional P&L, and understand what administrative costs they may layer in. For niche vendors it may be a mix of license, billable time, or fixed services.
Many technology managers don’t spend the necessary time to understand the P&L of their vendors. They may negotiate price points, penalties, or performance payouts to manage the cost and risk of the vendor, but if they don’t understand how the P&L works, they may not realize the gains they thought were negotiated into the contract.Just remember, your vendors will almost always be more savvy at managing the contract than you will be.
To effectively manage your vendor, you have to know how they make money.
Understand the impacts of Change Requests
Part of every contract with a system integrator is the scope that is agreed upon by both parties. Usually as this scope is baselined, contract clauses are written to reward or penalize the vendor on their ability to realize the scope. However, remember that every time you request a change in scope, resources or schedule a change request is written and accepted by both parties. These change requests will treated as addendum’s to your contract and effectively change your baseline. Add scope and budget, the baseline changed and the bar for the reward or penalties in the contract also changed. Swap out a resource for a more experienced resource, the job title may have change, hence the bill rate changes and the budget is increased.
Over the course of any project there could be hundreds of change requests that are processed. You will need to staff resources that can track and manage the contract and all the changes. If you don’t, you may not truly understand where your budget is or more importantly what your vendor is on the hook for.
Consulting Resources
Just accept the fact that the resources that a vendor provides you will not all match your needs. You have to assume that up to 30% of the resources assigned to your project you will have to release and ask for different resources. The reasons will vary from lack of the right skill to poor personality fit with the company culture. What ever the reason, you have to be prepared for the impact that this churn will have on your project. During negotiations with your system integrator or staffing vendors, insist on interviewing key roles, reviewing their backgrounds and potentially naming them in the contract as critical resources. Inquire with your vendors on their bench, ability to quickly swap resources, and how they will bridge gaps in the staffing of your project.
Software Defects, Early Product Releases, and Performance Issues
While we have been talking mainly about consulting services vendors, let’s spend a bit of time on your software vendor. Inevitably you will run into issues with the software you purchased. These issues can run from getting the system installed correctly to performance issues once you hit production.
Understanding what your software contract and more importantly your support contract stipulates will be critical to being able to quickly resolve your issues. These contracts will outline the process to report defects, what the service level agreement is for your vendor to respond, how to classify the severity of the issue, and what hours of operation the vendor has. Your development teams, system integrators, and support teams need to know this information to be able to effectively manage your instance of the software.
Many software vendors will want access to your production system and log files so they can accurately troubleshoot issues. You will need to ensure your security, regulatory, and information protection teams are aware of obligations a contract may stipulate to enable this. The last thing you want is your internal security team to object over access by your software vendor when your system is not performing as intended.
As you report defects, many times a software vendor may dispute your interpretation of the defect. The software could be working as designed in their minds. You will need to be prepared to argue your points and present your case. This can be exhausting if it is a production issue you are working with. Your companies volumes, data sets, integrations, or configurations could be a root cause of how the system performs, but it still may not be a defect.
If you decide to install a beta or early release of a product from your software vendor, you need to understand what enhanced support you will receive in return for taking this risk on. There are many cases where a company is so hungry for a particular feature set of a new release, that they forget that there could be incompatibility or performance issues that have not been fully resolved. Insist that your software vendor have engineers on site during installation and deployment or at a minimum at the ready if an issue arises.
Vendors don’t play well with each other
At the onset of your project, just after all the ink has dried from the contracts with your software, system integrator, and niche vendors you will except them to all play nice together. Don’t be fooled. Most vendors don’t play well with each other. They view each other as a competitor who is taking revenue away from their bottom lines. They will all want to be the favored vendor with you and do whatever they can to have that preferred relationship. In fact, while it should be expected that they won’t play nice with each other, they may not even play nice with your own team. As problems arise, fingers will quickly get pointed. The system integrator will blame the pace of decision making by you the client for schedule delays. The software vendor will blame the system integrator for not adhering to a standard implementation. Niche vendors will complain that they are never “At the Table”, hence they are always two steps behind. Regardless of the issue, you will have to wrangle your vendors and internal teams to get over each other and find a way to forge a working relationship. Be firm in how you expect everyone to operate and don’t tolerate behavior that may undermine that.
Your system integrator will never want to leave. They will constantly be looking for opportunities to sell their services or justify their continued engagement.
Knowledge Transfer
Most companies expect that knowledge transfer will just happen. While much knowledge will be exchanged between your vendors and your teams, it is often organic and not well organized. Often time there is an expectation that documentation is written, classroom training occurs, brown bag lunch and learns are completed, and active/passive shadowing is built in to happen. Unfortunately three things get in the way of knowledge transfer: scope, schedule and budget. As your project hits those natural challenges of getting all the scope done, within the time frame expected and within budget, knowledge transfer somehow just gets pushed aside. Ideally your contract stipulates a base level of knowledge transfer occurs and is measured by validating the competency of your staff prior to final payments. If this approach was not able to be contractually agreed too, know that you will have gaps in knowledge as you go into production and be prepared to leverage your vendor further or deal with the challenges of having your teams learn by drinking from the firehose.
Going it alone
At some point your internal teams will be ready to take on managing or implementing your software without the assistance of a system integrator. Decoupling your system integrator from your organization can be challenging. Your system integrator will never want to leave. They will constantly be looking for opportunities to sell their services or justify their continued engagement. You will have to at some point just cut them off. Just when you think you are ready, your own teams or business partners will object. They can’t possibly lose Christopher or Sally who has all the knowledge of how everything works. Vendors will talk about risk, stability, skillets, or what ever they think will scare you into continuing to use them in your projects or for running and supporting your software. Just remember, your teams for the most part will be hungry to run things on their own.
To accomplish your company’s goals by implementing software to enable key business processes, it is often required to rely on vendors. You need their knowledge, expertise or technology to remain competitive and rationalize your technology. Having employees that are savvy in how to negotiate, manage and motivate your vendors will aid in the successful outcome of your initiative. You can’t just beat up on your vendor nor just assume good intent. You have to forge a mutually beneficial partnership knowing that at some point the benefits will run their course and you will amicably part ways. Your vendors can be one of your most valuable assets, knowing how to get the most out of them is crucial. Spend the time to get to know their operating models, P&L, and the individual consultants you will work with. This investment of your time will pay off.
