I was impressed by a great blog entry about CRM innovation for innovation's sake on the TEC blog. You should have a look and check out some of the other entries. Great insight and information.
Beware of CRM Innovation for Innovation’s Sake
When I first wrote about the upcoming TEC CRM Buyer’s Guide focusing on innovation, I stated that customer relationship management (CRM) vendors can differentiate themselves from their competitors through innovation. But I also mentioned that innovative technology should not be embraced just because it’s new or cool, or seems to bring the answers to your problems.
Innovation is great, but remember that innovative products can also bring challenges that your company might not be ready to deal with. So after all the excitement settles, here are a few things you should consider before adopting innovative technology.
1. New technology and old business logic can be a terrible combination. New programming languages and platforms can be used nowadays to create user-friendly interfaces, dashboards, and widgets to group and display information into a single screen, but this is not very useful if the data is not stored and managed based on business logic and best practices that make it easier to retrieve and analyze.
To avoid falling into the trap of acquiring new technology with old business logic, test it before you buy, and focus on the operations that you perform on a regular basis in your company. Sometimes the new interface is just another way to make the solutions look better, which may make it more user friendly and accessible, but may not help with important business processes and workflows.
2. Innovative technology doesn’t always fit well with your existing tools. If you found a great tool to gather customer feedback using social media, but you need to first export the results manually in order to import them into your CRM system and then analyze them in a separate BI tool, the whole exercise might not be worth the investment.
This pitfall can also be avoided by looking at the tools that the new innovative solution needs to integrate with. And start with the ones that are critical for your daily operations. Try to estimate the resources required for implementing and using innovative technology, as well as their costs, and compare them to the expected output. For instance, using a portal for account receivables may not help if your customers prefer to receive invoices by e-mail.
3. Innovative technology will always cost you something but return on investment (ROI) is always hard to calculate. Even when it’s free, an innovative CRM solution will cost you time and effort to test it, implement and integrate it, maintain it, etc. And it’s almost impossible to calculate ROI for innovative technology, because you don’t know what extra investments it will require in the future; it’s also hard to isolate the effects that innovative technology has on the efficiency of your company.
Adopting innovative technology will always entail risks, but you can limit them by using a phased approach: start by embracing the innovative technology for a few business activities that are important to you and only extend it to others if it proves to be really useful. A good practice is to first have a small team of motivated and enthusiastic people that will pilot such initiatives and then scale them to others if they prove to be efficient. Imposing the innovative technology at the enterprise level right away will most probably create disruptions, which will translate into indirect costs.
4. Innovation isn’t always a commitment for vendors. Your CRM vendor may not have innovation included in its long-term product map. For niche vendors, it gets even more complicated, because they might be acquired by larger companies, which will incorporate the solution into theirs and perhaps decide that future development does not necessarily focus on innovation.
Vendors with a proven history of innovation may be considered safer from this perspective, but the ideal way to address this challenge it to make sure that the solutions you use for CRM are flexible enough to allow you to integrate with others by adding or removing new modules and add-ons, develop new functionality, and keep the changes when your vendor changes its development strategy. Also, make sure you can easily get your data back when you decide to opt out of solutions that seemed innovative but aren’t meeting your expectations.
Embrace innovation, but never for innovation’s sake
A person can afford to spend hundreds of dollars for a new gadget just to be one of the first to have it, but companies cannot afford to invest hundreds of thousands of dollars and a lot of time in innovation without a strong motivation and analysis of the investments required. In other words, impulse purchasing of innovative technology will be much more costly for a company, thus the need for a more level-headed approach to innovation. Unless you are careful, you will end up investing a lot of time and money, not to mention the disruptions you may bring to your relationships with your customers and partners (e.g., some of them may not be ready or willing to adopt the innovative technology you find so great or others may not have the IT infrastructure to use that technology). Not to mention the false hopes that you can give them and the disappointment if you’re not able to deliver (e.g., if you build an online community, make sure someone will manage it, otherwise it can be worse than not having any).
Innovation for CRM, with its advantages and challenges, is described in more detail in the upcoming TEC CRM Buyer’s Guide, where I will be discussing cloud computing, mobile, social, and extended innovative technology for CRM. In the meantime, I welcome your thoughts on the risks of adopting innovative technology and the ways companies can reduce them.
Introduction – Fixed Price vs. Time and Materials
It is an axiom that businesses small and large consider IT projects high risk. Many have instituted policies requiring fixed price contracts, in order to minimize their risks. These same companies often do not realize that this policy creates a situation where engagements with their vendors become losing situations for each.
I contend that many customers and vendors share basic misunderstanding of the concepts of contracts, expecting the best of both fixed price and time and materials contracts. This first blog in a series will talk to some of the reasons why.
Almost every executive has a story of a project which started small and became a sucking black hole of time, resources and money. I have lost count of the number of these stories I have heard personally, on topics ranging from custom application development, to off-the-shelf implementation to web site delivery. While the stories differ in specific detail, the core elements remain the same:
- We thought it was a simple project
- The contractor/IT team/salesman told us it was straightforward
- We did not think that we changed the scope during the project
- We felt taken advantage of both during and after the project, if it ever finished
- We did what we were told
- The person responsible for the project had his/her career negatively impacted
The multiplier effect held true for these stories. For every first person epic I heard, there were tens of second and third person anecdotes. The grapevine is very fast, if not always accurate. How many times have you, the reader, heard the words, “Did you hear about … ?”
Not surprisingly, while companies still understand the need to have these projects done, they have and continue to push their vendors toward fixed price contracts. The ideas are basic and often reflect their own corporate processes. These include:
- Risk aversion and reallocation
- Payment for deliverables rather than effort
- Cost reduction
For some projects, this can be an effective policy. Where customization and configuration is minimal, it can be effective to contract purely on the basis of deliverables. A sample in the IT world might include:
- Computer setup
- Network cabling
- Server setup
The above, with a small number of parameters, are repeatable tasks. Once an image has been created and tested, computer setup effort can be predicted within a relatively accurate range. The same applies to cabling a building or setting up a server. Many companies provide fixed price estimates for these tasks, with constrained scope definitions in their contracts. Usually, these prices include a level of contingency to address the inevitable unexpected issues.
At its core, I propose that companies reason that if a vendor is proposing a solution, they should know exactly what it takes to deliver it. They should be able to estimate it in detail and if their estimate is incorrect, it is their own fault. The experienced and expert vendor should eat the extra risk, not the unwitting client.
Let’s look back at some of the core experiences.
|Client||Vendor / Consultant|
|We thought it was a simple project||We told them, in person and in writing, that there was complexity to this project. They just could not seem to understand. Why hire a consultant when you don’t want to pay for consulting?|
|The contractor/IT team/salesman told us it was straightforward||We gave them a range of samples of our projects from similar industries. They latched onto the smallest effort and cost, though their project was more complex and larger.|
|We did not think that we changed the scope during the project||Every time we talked, the client wanted some additional customization, configuration, additional training or support. By the time we were able to understand what they actually wanted, rather than what they had said they wanted, the project estimate had grown. But they could not understand that what they wanted was not the same as what had been agreed to in the contract.|
|We felt taken advantage of both during and after the project, if it ever finished||We felt taken advantage of during and after the project. They kept asking for more and saying that it was a part of their original expectations. But we were so deep in we could not afford to pull out.|
|We did what we were told||They tried but even the most basic client deliverables required our assistance. The needed iterative discovery and delivery but did not want to pay for it.|
|The person responsible for the project had his/her career negatively impacted||The client was not happy and refused to provide us a reference. In fact, when they talked about the project, they implied that we did not provide what we said and that our service was lacking. The account rep is on thin ice. The PM and the team received smaller bonuses.|
|It is even more vital to require fixed price and to determine processes which make it harder for the vendor to change the project price after the start||How do we deal with them next time? They keep wanting more and making it harder for us to deliver. There does not seem to be any incentive for the customer to manage their own expectations or requests.|
|It seems unfair that we had to pay for change orders where the vendor did not always use all the estimated time.||Amazing. When the effort exceeds the estimate, they want us to cover all the cost. But when it is less, they want to pay less. Don’t these people understand a fixed price contract?|
Another axiom in the project world is that successful small projects require the same processes as successful large projects. Implementing an application or web site requires detailed understanding of business and technical requirements. It is rare when a customer is happy with a completely generic solution which does not account for their specific needs.
It is common for customers who think their projects are small to expect that the vendor will enter the project with an innate understanding of the requirements. After all, they have done similar project before. They often convey their requirements at a very high level or do not truly understand their requirements.
Often, the customer does not actually understand what they want until they have had the chance to see a prototype or beta version. They see the site or the application and suddenly understand that what they really wanted was … something more. And here starts the almost inevitable discussion of requirements and scope. The customer looks at the vendor and says something to the effect of “You should have known what we meant. If you want to get paid, you have to make sure that the deliverable meets our current expectations.” So starts, with a certain inevitability, the arguments over scope, cost, change orders, timelines, expectations, contract terms, payments, escalation and reputation.
Vendors can feel trapped by the customer’s contract requirements. They are forced to include increasing amounts of consulting in the sales process in order to be in a position to engage with the customer. But this effort grows harder to recoup, as most customers are loath to pay for time incurred before the contract is engaged. To recoup their efforts they are required include copious amounts of extra cost which the client will then begin to whittle down. Like all vendors, they fear the other guy coming in to undercut their offer. They go low, expecting to make it back in change orders. And the cycle begins again.
On top of other difficulties, there is a lack of understanding by many clients of the difference between a fixed price contract and T&M with a fixed cap. This will be addressed in future parts. Suffice it to say that there are few worse ways to engage with a client.
There is no complete solution to the issues inherent in projects, fixed price or T&M. However, future installments will discuss:
- Expectations management
- Effective contract writing
- Proactive documentation and reporting
- Contingency estimation
- Vendor differentiation strategies.
Has anyone noticed how trivialized two supposedly critical functions in the IT world have become? I’m talking about project managers and business analysts. I always thought of those two functions as pivotal, as make-or-break activities on any development project. (Forgive me, I thought of them as maybe even more important than the programmers.)