Four Questions to Ask a Vendor’s Professional Services Team

While professional service teams, or implementers as we like to call them, aren’t out to overcharge customers, asking a few questions up front can avoid embarrassing project delays and cost overruns.  While this list isn’t exhaustive it is a good start.

1.  Is your implementation fee based on a fixed fee or time and materials?

Buying services, buying licenses, buying a car… customers should know what they’re getting, how much it costs, and what factors will increase that cost.  Fixed fee implementations are always the best way for a customer to go, especially if the features and benefits of the software are straightforward.  If you know before buying that customizations to the software are needed, ask the professional services to price out that work, or if included in the price–get it in writing somewhere.  It’s in everyone’s best interest to have a clear description of what’s being built and delivered.  If you can’t clearly define what you need above and beyond the standard implementation, consider holding off on the extras until you’ve implemented the core offering.  You may realize you don’t need it!

2. Will you maintain the same resources throughout the project?

Depending upon the length of your implementation consistent resources can be critical to its success.  Make sure the vendor is willing to commit to the same resources throughout your project, barring any unforeseen or unavoidable situations.   A lot of time and effort is often wasted when customers lose the knowledge and relationships they’ve built up with the project team mid-project, and have to re-explain or indoctrinate a new resource into their environment.

3.  Are multiple environments included, and will you assist in their setup?

Depending upon your company’s IT policies and procedures, multiple environments may be necessary to test before an application can be put into production.  First, make sure you know your own company’s policies and procedures in this area. Secondly, make sure you’re licensed by the vendor to have multiple environments and that the implementation services are included to assist in the implementation of the product in these various environments.  Also, if you have a strict corporate policy governing the change management steps associated with the migration between these environments, let the vendor know about it.  It can only help you in the long run.  Otherwise the vendor will always be fighting against the currents of your IT policy to do it “their” way instead of “your” way.

4.  How long does it normally take to implement, and what can I do to impact that?

Just because you need the project completed by a specific date doesn’t mean it can be done by then.  Ask the vendor what the typical implementation cycle is, and what you can do to impact that if you need to speed up the process.  Also, ask what sort of situations the vendor has encountered that made projects take much longer than originally anticipated.  A vendor, especially one who doesn’t work on a time and materials basis, wants your implementation to go as quickly and as smoothly as you do.  Let their experience help you make that a reality.

Sometimes the most effective way to get answers to these questions, and others, before you run into a problem, is to try to engage the vendor’s professional services team during your software evaluation to understand their methodology, attitudes, etc.  This way you’ve started to form a relationship before the project begins, and there is a connection between the “pre-sales” speak and the post-sales reality that will help make the transition into the implementation phase seamless.

Keeping the Process of Choosing a Solution Simple

Simplicity is underrated.  The best ideas are great precisely because they are simple.  I think the key is to be able to determine the level of complexity that is justified by any given problem. One does not need to build the roman aqueducts to water the garden.  I think this is something that anyone starting or implementing a big software project needs to keep repeating to themselves. It is up to the architect to execute a plan that is streamlined, efficient and sustainable.

There are software vendors out there offering solutions that are too complex for the problem at hand.  They attempt to solve all possible related problems and give themselves all possible functionality and flexibility. Then clients buy into someone selling them a toolkit that says it can do everything, which invariably means that it will do nothing particularly well. Clients devote large teams to the evaluation and implementation of such tools, customizing them to their own purposes. What ends up happening is that over half the allocated budget on such a project often goes to this time consuming planning. People think they are saving something by this approach, saying, “Well this way we only have to deal with one vendor and develop internal expertise in one thing.”  What one needs to keep in mind is that the complexity increases non-linearly with the number of things a tool is expected to do.  

In my experience, the better approach is incremental with well understood and easy to control milestones and functionalities.  Rank your problems, and then solve them individually, and in order.  Buy the best tool for each objective you wish to achieve. Reevaluation after each implementation gives you the chance to solve overlooked and hidden problems and give a superior end result.  For each problem make sure you are not spending more in time and money than the problem is worth.