The problem, of course, will be developer productivity and code maintenance costs. Expect custom coding a feature to be at least an order of magnitude more expensive than configuring the standard functionality.
Solution strategy: To the degree possible, use standard system features and off-the-shelf plug-in products to meet requirements. Bend requirements to fit what’s available. Push coding out of the initial delivery if possible, so coders are working on a stable platform. For items that must be built, push to streamline processes and business rules that can cause combinatorial explosions (e.g., the security model, order configurations, distribution/partner networks).
3. Really nice reports
The original SFDC reporting engine strikes a nice balance between power and ease of use, but it gives spreadsheet-quality output. If you want really clever and beautiful reports, it won’t take long before you run into a wall.
SFDC’s Wave reporting system is both more powerful and prettier, but really leveraging its power means writing query code. For even fancier stuff — with nice formatting, multi-page layouts, and automatic office-document generation — third-party add-ons are needed.
But as I noted in a previous article on design work in CRM projects, if it’s got to be pretty, it’s going to be pretty expensive — both to set up in the first place, and to evolve over time with your needs.
Solution strategy: Thoroughly understand and specify every variant — including formats and user-specific tweaks — of every single report you will need prior to putting the system out to bid. It’s best to discover that you actually require 100+ reports, not the ten you thought. If you have a working report (e.g., from Access or Crystal) that you need the system to emulate, provide the vendor with a sample set of input data and the report’s output, with annotations regarding format and exception conditions.
4. Project management & supervision
This means you, project leaders and executive champions! Things you do will contribute directly to overruns. As I discussed in an article on agile project management, distance and delay are the enemies of efficient and economical projects.
But I need to add some new ‘D’s that are even more deadly: dithering and (unending) discovery. The first of these, dithering (a.k.a. indecisiveness) is bad enough, as it causes delay and erratic direction, which leads directly to rework. But the second, whose hallmarks are discovering that (1) the requirements weren’t really known up front, (2) your assumptions about how things need to work were wrong, and (3) your assumptions about how the new system features will work were wrong, is the root cause of scope creep. I can’t tell you how many large projects discovered more than half of the costly requirements after formal discovery was completed.
Sign up for CIO Asia eNewsletters.