- 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
Knowing Your Boundaries
One of the most important issues in requirements setting is determining the “edges” of the system—that is, the boundaries beyond which users must log in to a different system if they want to do something. All users would like the system to encompass all of the things they need to access for their particular jobs, but it’s impractical to deliver a single system that covers every business function for every employee.
When you first install SFDC, it has the following functional boundaries:
- Order entry: Anything having to do with bookings, invoices, or payments is in your accounting or enterprise resource planning (ERP) system, not SFDC.
- Order management: Anything having to do with shipments, order status, returns, or exchanges will be in the distribution or ERP system, not SFDC.
- Marketing: Leads, contacts, campaigns, and simple email blasts are fine within SFDC. Almost all of the details having to do with emails, marketing events, advertising, or other marketing initiatives, however, will be in your email blasting, marketing automation, or content management system, not SFDC. For example, SFDC tracks the outcomes and history of campaigns, but actual campaign management is external to the system.
- Customer assets, inventory, and licenses: Almost anything having to do with the customer’s order history, shipments, downloads, or licenses will be in your accounting, ERP, or other corporate databases. SFDC has a very limited view of assets.
- Defect reports or bug tracking: Anything having to do with the technical side of customer problems will be in the defect management or bug tracking database; most companies already have an entrenched system for this purpose. SFDC can be configured to integrate with these systems, but out of the box it’s really focused on “cases” or “incidents.”
- Documents: Almost anything in your sales literature, marketing library, Web site content, proposals, customer specifications, or contracts is already stored outside of SFDC, often in a file system or in content management products. SFDC has an add-on product that helps present and organize document libraries in a clever way, but this product will usually be a supplement to existing external systems, rather than a replacement for them.
- Business analytics: Although SFDC provides an excellent set of built-in reports and dashboards, almost any business analyst will need to go beyond these features and use an external database and business analysis tool.
For a detailed view of business systems that touch on SFDC, see Figure 1-3. As shown in the diagram, several add-on products may be tightly integrated with SFDC to improve its functional coverage (see Chapter 7 for a discussion of these products). These extensions and external products are a huge strength of SFDC, because they allow the core system to be simple and easy to use, yet flexible and scalable enough to handle much broader requirements. Further, SFDC has a very open and well-documented set of external interfaces, presented as Web services. These “SOAP APIs” allow programmers to connect, integrate, and extend SFDC to almost anything.
)
Figure 1-3 SFDC and the application landscape (as of spring 2009)
Even though you could integrate SFDC with any external system, it’s easy to overshoot the mark by trying to do too much in the initial implementation. In evaluating and prioritizing requirements, it’s important to identify when a requirement crosses over into an external system. Any such requirement is inherently more complex and risky, so it should be assigned a lower priority than requirements that are entirely within SFDC’s native functionality. Read the section on integration in Chapter 7 before you deal with any requirements for integration.
Thanks to the modularity of the SFDC architecture, almost all internal functions can be turned on in phases at the time of your choosing. For example, turning on the Campaigns or Forecasting function can be done the day you bring up the system or, alternatively, months later without involving significant rework. Many external add-ons act in the same way, allowing a very flexible deployment schedule. However, some of the more sophisticated add-ons (such as Eloqua marketing automation or Intacct accounting) will involve significant changes to your data, the user interface, and user behaviors. Consequently, the timing and sequence of deploying the more complex and expensive add-ons cannot be taken lightly.
As with all requirements, the extension of SFDC via add-ons and integration with other systems should be prioritized with a keen eye toward schedule and risk. Even though basic integration is of the “plug and play” variety, the interaction among systems and databases can cause subtle data corruption problems that won’t discovered for several weeks. Consequently, it is usually a good idea to deploy basic SFDC functionality without external integration, get the users comfortable using it, and get some real data flowing through the system (even if only manually) in the early weeks. Later, new functional add-ons and integrations can be deployed on top of a stable baseline system, and users can gradually become used to the new features as the system expands. External integrations (particularly with complex systems such as accounting, ERP, and marketing automation) should be started early for testing purposes, but not turned on for full two-way data transfer until later phases.
Appendix B provides example requirements for both a small company and a large company. Of course, every company’s needs and priorities will be different, but the examples show the level of detail that you will need (not much at this stage) and the kind of interdepartmental prioritization you’ll need to think about when preparing your company’s list of requirements.
The SFDC system will almost certainly be implemented over several quarters, with only the first two phases as “hard priorities.” Later requirements will be reordered depending on perceived business priority after initial usage; technical issues or needed process changes will be discovered during the project. In addition, perceived business needs may change over the life of the project. It’s important that the executive sponsors understand, however, that each major requirements change will cause some delay and wasted effort. Communicating this point clearly but pleasantly is one of the key challenges for the project leader, because the executives are as vulnerable to “happy ears” as anyone else.