- Getting to Business Value
- Developing a Model of Your Customer Relationship
- Setting Business Goals
- Setting Requirements: Who, Where, What, and Why
- Organizing and Publishing Project Documents
- Prioritizing Requirements
- When Requirements Should Bend
- Knowing Your Boundaries
- Making the Business Case
- Quantifying the Return
- Developing a Straw-Man Schedule
- Avoiding the Big Bang Project
- Outsourcing
- Setting Executive Expectations
- Getting the Right Resources Committed
This chapter is from the book
This chapter is from the book
This chapter is from the book
Outsourcing
Almost inevitably, you will need to use some outsource resources to assist in the project implementation, and you’ll want at least budgetary placeholders for them. There are many tasks that your internal team shouldn’t want to get good at. Even so, you cannot outsource everything—your team must be involved to define business rules, perform data extraction, review prototypes, validate data conversion, do acceptance testing, and, of course, manage the project. One thing to insist upon is a full “technology transfer” from any consultant you use, so that your team becomes self-sufficient in any area of ongoing development or maintenance.
In evaluating and choosing vendors, follow these rules of thumb:
- The product vendor’s consultants will know more about the internal workings of their product than any partner consultant can. They will also have direct access to product engineering, and will have several “back door” tricks that can save time and make their prices a bargain. For internal extensions, customizations, scripting, rule setting, query design, and other “deep dive” projects directly related to their own products, the vendors’ consultants are likely to be the best choice. However, they are less likely to be the right people for external integrations or business process design.
- A specialist system integrator with a practice dedicated to SFDC or other SaaS product is likely to know best how to do “external work” that integrates across applications. However, these individuals’ level of knowledge and skill regarding business processes vary dramatically. In fact, many firms that are fully qualified at the technical level have zero capability when it comes to understanding and optimizing business processes. Check references before you make specific task allocations!
- A technical “coding shop” typically will be very good in its particular domain (for example, enhancing a CMS-driven Web site or an external order-management system), but those employees may not have experience with Web services and high-speed integration using SOAP.9 Even though most SaaS applications use Web services for integration, every vendor uses the core technology a different way. For this reason, it’s important to check the vendor’s experience with SFDC’s APIs and any AppExchange products you’re planning to use. As always, references are more meaningful than vendor claims.
- A consultant who already works with your company has a natural advantage over outsiders. In addition to already being “connected” in your organization, the incumbent consultant is much more likely to know a lot about your technical environment and at least something about your business processes. Check with your IT organization to find out who is already under contract. If you’ve got only a few person-months of work to do, the incumbent’s advantage may be a decisive one.
- Data cleansing and enrichment houses can be very economical (using tools and offshore resources unavailable to you), but this part of the project must be done right and completely to be at all meaningful. Check whether the vendor has done work on your size database in an SFDC project: most have not, and they’ll experience a serious learning curve. Check references to confirm the details, because offshore data cleansing/enrichment operations tend to overstate their capabilities and are very inefficient at learning to do new things.
- Management consultants, sales process consultants, and organizational design specialists understand the human side of your business processes better than any other vendor type. Large organizations will typically need to use these consultants to optimize business processes, redesign sales procedures, and set policies. However, these consultants are rarely in a position to do implementation work, because they don’t understand the inner workings of SFDC and other systems well enough. They also have a tendency to make recommendations that are technically very difficult or even unfeasible to implement. So absolutely include them on your team to design best practices and increase the speed of user adoption—but do not expect them to implement much in SFDC.
No matter which kinds of vendors you use, it is essential that you have a positive, cooperative relationship with them. Adversarial relationships just don’t work—in terms of price, quality, or schedule. That said, it’s essential that you manage each vendor relationship tightly. Although you don’t manage a vendor in the same way you would an employee, vendors are every bit as important to project success and budget as any other team members. Weekly checkpoints and monthly scorecards are essential for all vendors.
Generally speaking, there are several areas that you don’t want to outsource. It typically doesn’t pay to have an outside team learn the peculiarities of your old home-grown systems. An outsourcer should not be making policy and process decisions for your company (they can make recommendations, but you have to own the decision).
Even if a major technology is implemented by outsiders, your internal team needs to have ongoing capability and knowledge. For example, you’ll want to be able to make simple system modifications without calling in a vendor, and it’s a good idea to be able to make minor changes to cope with the inevitable upgrades of external systems or minor updates to business rules. In your resource allocation, think through which of the tasks must be done internally, which should be done through a vendor, and which should be done jointly.