Why? When you're trying to optimize a CRM system, you're not getting a pre-existing commodity. You're developing a customized system that helps you achieve your specific business goals. It should leverage (or provide the foundation for) organizational change. In other words, you're not buying a product: you're buying into a process.
I'll even argue that if all do is buy "an implementation," then you're missing half the point of CRM. If all you get is "automation," then you'll just be doing the same old thing at lower cost, instead of growing the top line.
But enough with the polemics.
When the Boss Says, 'Forget Agile; It's Fixed Price!'
For many, the biggest issue with agile projects is not knowing what you're going to get for your money. If you don't trust the project team and the vendor, agile can indeed look like a license to steal.
The best answer to your boss' concerns: Don't even think about starting a project until you find a project team and a vendor that you trust. But that's probably just crazy talk. In my experience, fixed-price CRM projects are more likely to be complete in name only, with unhappy users, than they are to be satisfactory to users, with unhappy budget-holders.
(Full disclosure: I ran fixed-price Department of Defense projects for years, with only one small overrun. Despite the popular perception, Air Force procurement processes are pretty tight.)
In CRM projects, clients tend to demand fixed-price projects without actually preparing for them. In response, vendors often use three strategies for "fixed pricing"-providing only cookie-cutter CRM implementations, selling just a bucket of hours (that is, not signing up to completing the deliverables), or starting engineering change order (ECO) negotiations almost from the outset.
To prevent this from happening, there are a few things to look for in the vendors, as well as a few behaviors you need to follow along the way. Here's a quick rundown of how things ought to work.
Step 1: Before Any CRM Project, Do Your Homework
The RFI, RFP and RFQ drill works well if your team really knows the details of the business and technical requirements. Unfortunately, spec-writing teams tend to make three classic errors:
- They simultaneously under-specify (with too many silent assumptions and incomplete information) and over-specify (with too many product-specific stipulations).
- They're vague (or even silent) about acceptance criteria for features. A spec without a test or a clear go/no-go threshold is a wish-list, not a spec.
- They oscillate between the dweeby features, the business rules, and the overall goals.
Sign up for CIO Asia eNewsletters.