Home > Articles > Information Technology

  • Print
  • + Share This
This chapter is from the book

CRM Implementation

As we discussed at the end of Chapter 7, CRM is usually a corporate program made up of many projects. For CRM point solutions that deliver finite functionality, one well-run project might be enough. Each CRM project should focus on implementing at least one defined requirement. Whatever the complexity, CRM development should be evolutionary and multi-tiered. Figure 9-1 describes a departmental CRM program and its associated requirements.

Figure 9-1 CRM program and requirements

Understanding the complexity of your CRM program is critical to planning your CRM project. For instance, if CRM is an enterprise initiative, there could be dozens or even hundreds of discrete requirements across the corporation, rendering project-planning orders vastly more complex. If, as in Figure 9-1, the program is departmental, each requirement will eventually be deconstructed into a number of different functions, revealing its inherent complexity and the development resources it will require.

Scoping and Prioritizing CRM Projects

Biting off all the requirements listed in Figure 9-1 would not only be dangerous; it could sabotage a company's entire CRM initiative. After you list your CRM requirements and have a good idea of their required functionality, the CRM business sponsor or steering committee can actually cast them into discrete projects.

Surprisingly, many CRM sponsors and project leaders forget this step and move straight toward trying to deliver the sum of all listed requirements in one fell swoop. Without scoping and prioritizing CRM projects, project managers lack overarching direction for prioritizing development activities, and application developers are free to arbitrarily add and change functionality during development. The results are usually disastrous. A scoping activity ensures that CRM projects are defined based on discrete requirements and are circumscribed around delivery expectations.

Requirements can evolve into individual projects based on demand urgency or perceived value or based on implementation complexity.

In the case of demand urgency, the customer support department might be overburdened. Thus the requirements pictured in Figure 9-1 might be prioritized in the following way:

  1. Implement Web-based self-service and FAQs.

  2. Offer Web live-chat service and support.

  3. Support outbound message management.

  4. Automate workforce management to optimize customer support.

  5. Provide CSRs with on-demand customer profiles using existing data.

  6. Provide scripting for CSRs and telesales staff.

If, on the other hand, implementation complexity is an issue, and the company needs a CRM "quick win," the following prioritization might make more sense:

  1. Provide CSRs with on-demand customer profiles using existing data.

  2. Automate workforce management to optimize customer support.

  3. Provide scripting for CSRs and telesales staff.

  4. Implement Web-based self-service and FAQs.

  5. Support outbound message management.

  6. Offer Web live-chat service and support.

Of course, politics figures into the decision on how to prioritize CRM projects. After all, if your customer-support vice president and call-center director are fighting over whether external data is necessary for really understanding customers, you might want to steer clear of providing CSRs with customer profiles until the issue is resolved—no matter how happy it would make the CSRs. Although formally rating the political landmines of every project could be overkill—not to mention highly subjective—knowing the political baggage that accompanies each potential project can serve as a tiebreaker.

When prioritized, a CRM requirement—or specific sets of related requirements—can be defined as an individual CRM project as shown in Figure 9-2.

Figure 9-2 Delineating CRM projects

Notice that in Figure 9-2 the Web-related development has been grouped into one project. This decision was based on practical reasons—specifically, the ongoing challenge of finding available Web-development staff within the company—as well as the estimated development complexity. Projects 1, 2, and 3 are all minimally related and can each leverage existing technologies and skill sets within the company.

Who should scope a CRM project? Ideally, business representatives and development staff should discuss each requirement and estimate its value-to-complexity ratio—the higher the value and the lower the complexity, the better—with the goal of prioritizing delivery on an ongoing basis. Most CRM scoping activities focus on delivering initial applications in order to hand over a "quick win" to the business. Applications with a high value-to-complexity ratio should rise to the top, and others can be prioritized accordingly.

The complexity metrics will vary according to the availability of your company's existing technology and staff resources. For instance, companies that already have robust customer databases won't rate customer profiling to be as complex as those who must start from scratch.

To correctly scope a project, simply rating its functional complexity is not enough. Ideally, you should understand the following:

  • Specific technologies that will be involved in implementation

  • Necessary skills to implement the project

  • Number of staff members projected to work on the project

  • Number of consultants needed to supplement in-house skills

  • Realistic time frame necessary to deliver the first release

  • Organizational boundaries and potential political issues

Scoping a CRM project prior to launching development mitigates the risks. For one thing, it's much easier to develop an accurate project plan that reflects realistic resource requirements, tasks, and time frames. Justifying headcount requests to management based on the project's true scope is also easier. Finally, hiring becomes more straightforward, because the true skills necessary to develop the CRM system are clearer than they would have been if you had simply gone straight to implementation. In fact, failure to thoroughly scope IT projects is one of the principal reasons behind many of their failures.

A CRM Implementation Roadmap

Even with the most straightforward CRM products, there's no such thing as cookie-cutter CRM. Development approaches can differ according to a company's approved development lifecycle, staff expertise, and IT standards.

Despite the possible differences in CRM implementation techniques, the following proven CRM development success metrics should define every CRM development project:

  • Incremental development. Incremental or "building block" development means the company receives a defined amount of new CRM functionality on a regular basis. This is due not only to the inherent complexity of most CRM projects but also to the cultural issues surrounding its deployment (few organizations can absorb multiple major functional and process changes at once). Incremental CRM "releases" create a perception among business stakeholders and management of ongoing value. The alternative to incremental development is the "big-bang" approach of delivering a major new system and accompanying business changes all at once. The big-bang scenario almost always includes unpleasant surprises.

  • Requirements-driven development. This means developers who are creating or customizing CRM functionality have an understanding of the overarching business requirements driving CRM, as well as the necessary functionality. Developing against requirements eliminates the notorious phenomenon of "scope creep" and ensures that users get what they're expecting.

  • Continuous user involvement. Many CRM teams fall into the trap of involving business users at the beginning and end of CRM but rarely in the middle—during its development—where it's often critical. This means end users evaluating proofs of concept, validating data and business rules, weighing in on the contents of CRM training, and reviewing new screens or functionality prior to CRM deployment. It also means establishing regular communications between development, the business stakeholders, and the CRM business sponsor.

  • Implementation process rigor. Even with other CRM best practices in place, such as comprehensive requirements and an enthusiastic business sponsor, CRM development must be planned and executed around a structured development process. This is to ensure that the PMO and project managers can anticipate and accurately scope various development activities. A sound development roadmap also ensures that programmers focus less on the implementation process and more on the actual delivery of valuable CRM functionality.

Figure 9-3 illustrates a CRM development roadmap that applies some of this structure.

Figure 9-3 A CRM implementation roadmap

Within the three main project phases—planning, construction, and deployment—the CRM roadmap features steps that contain a number of fixed and variable tasks:

Business Planning

CRM business planning involves many of the steps we discussed in Chapter 7. The most critical activity at the planning stage is defining CRM's overall objectives—be they at the department or enterprise level—and delineating the requirements of each one. At the enterprise level, CRM business planning can involve the documentation of a corporate CRM strategy and the definition of the corresponding programs within it. At the department level, it can simply mean establishing the boundaries of a new CRM application.

At minimum, the business-planning phase should include the documentation of high-level CRM business goals in the form of a strategy document or business plan. This document will be leveraged at CRM's inception to gain executive consensus and sponsorship. It will be useful as a focal point for requirements-driven development and—after the CRM project has deployed an application—as a way to measure its results.

As Chapter 7 illustrated in the hotel reservation system discussion, part of business planning should identify the critical customer-focused business processes CRM will impact. Where they are straightforward, you might decide to redesign these processes as part of the planning activity. More often than not, companies planning their CRM projects realize that rather than simply automating existing business processes, they are defining those processes for the first time.

Depending on funding and sponsorship requirements, CRM business planning might optionally include ROI estimation or cost-savings projections.

Architecture and Design

The need to plan CRM architecture and to design an implementation strategy is what makes business sponsors and project leaders shudder and go straight to technology selection hoping for a miracle. The architecture and design step is painful, but it's worth it.

This step identifies the business processes the CRM product will support. It involves listing the specific functions that will need to be implemented—and how—ultimately giving you a good idea of CRM's impact on the organization and various technologies.

Inventorying the range of corporate areas CRM will affect, as well as those that will affect CRM, is a critical activity. At the end of this step you should be able to answer the following two questions:

  1. What technologies and processes do we have in place that will be impacted by CRM?

  2. What do we need that we don't have today in order for CRM to work?

Relative to existing technologies, try to project CRM's impact on your current systems. Your IT organization should be willing to do this—and in return it won't be blindsided by CRM after it's been developed. Impact analysis can mean listing current systems—for instance, you might need to know a bit about your company's existing call center operational system before you can understand how candidate CRM technologies will link to it. Indeed, a range of existing technologies, from ERP systems to current marketing automation technologies to handheld computers, are likely to be touched by CRM.

After the system impact of CRM is well understood, an IT architect can draft a CRM architecture illustrating the appropriate linkages. Integrating corporate systems that exchange data—even if the data isn't formatted consistently—is known as enterprise application integration (EAI). It's a truism of business that different corporate systems store and use data in different formats. The term EAI denotes the integration of often disparate corporate systems that routinely exchange or share data. This means moving data between systems, as well as transforming that data so these systems can understand it.

The letter depicted in Figure 9-4 is from an online retailer that is doing neither CRM nor EAI.

Figure 9-4 Neither CRM nor EAI

This letter was included in a product delivery and represents a veritable smorgasbord of CRM don'ts. The first one is that the company's online ordering system is obviously not linked to its inventory system. (The fact that the company happens to be a high-profile dot-com with an edgy Web site and slick e-mail marketing campaigns is not evident in its post-sales customer support.) The customer should have been notified of the out-of-stock items at the time of the order, not upon delivery of the remaining items.

The company might believe that, had the customer known that not all of the items she ordered would be in stock, she would not have placed the order at all. Perhaps some of the out-of-stock items the customer wanted were in some way related to the items that showed up on her doorstep. Or perhaps the company intends to link its various operational systems together but hasn't had the time. Either way, this company has successfully achieved these detrimental outcomes:

  • Sending its "valued customer" a form letter and thus not differentiating her

  • Putting the onus on the customer to follow up on the desired items

  • Failing to provide similar levels of sales and service. (Notice the company's customer service hours. If the customer lives on the west coast, she only has around 5 available hours to contact the company by phone—but she can still shop on the Web at any hour!)

  • Losing a "valued" customer

EAI is important to CRM because, no matter how successful a new marketing campaign or how polite the (albeit mass) marketing message, if internal systems cannot share data, vital business knowledge could be lost and customer service undermined. If the company truly had EAI, its inventory system could alert its customer support system when the desired items came back in stock, allowing a CSR to notify the customer and make a sale. It is for this reason that many companies undertake EAI as a preparatory step toward CRM.

For new CRM functionality, you'll also need to understand what data to consider. For each business requirement, one or more data requirements will result. For instance, if survey data is to be incorporated into customer profiles, which specific data elements should be collected? Will you need to collect external data such as third-party householding information or competitive intelligence data? Of the data collected, what should be displayed to CSRs? To marketing staff? And what systems will deliver that data?

A significant part of defining data requirements involves addressing the actual meaning of certain data definitions. Is there consensus across the business that the term "revenue" means booked revenue, or might it imply billed revenue? Does a "new customer" have the same attributes in the sales organization as in customer support? To many in IT, documenting data definitions smacks of cumbersome metadata management and documentation projects. However, it's more about simply gathering consensus and enforcing consistent business terminology, whatever form that takes. If information is indeed a corporate asset, as we discussed in Chapter 7, consistent and sustainable data definitions are essential.

When you've completed an impact analysis, you can begin prioritizing projects according to business requirements and staffing your development projects, as we discussed earlier in this chapter.

Technology Selection

As Chapter 8 explained, CRM technology selection can be as simple as choosing an off-the-shelf product or as complex as a comprehensive evaluation of various CRM systems integrators or ASPs. If you've bitten the bullet during architecture and implementation design, understanding CRM's impact on existing systems and its requirements for new functionality, you should be in good shape to align any candidate CRM product to your existing IT environment.

Development

Development involves the construction and customization of the CRM product, using specific product features. But CRM development is more than programmers assuming center stage and writing code; it involves the integration of business processes with the chosen CRM product.

By this time, you will have already identified the key CRM business processes. Process integration means that CRM technology you've just selected integrates into these business processes. (The converse—merging business processes into the CRM product's features—forces the product to in effect define or change those processes, thereby diluting them until they are no longer optimized.)

Process integration involves ensuring that identified business processes are tested with users to ensure not only that the business processes work, but also that technology features can be leveraged in order to refine them. In other words, technological capabilities should improve, not compromise, customer-focused business processes. For instance, a campaign management product allows segment managers the opportunity to refine a mailing list before the campaign is launched—something they've never been able to do—thus refining the existing process. The same product might also allow a campaign director to monitor a campaign's success rate as it's being executed. If the first thousand prospects have been unresponsive, the manager can cancel the campaign rather than allowing it to proceed, adding another valuable option to the campaign execution process.

Refining business processes during development means iterative prototyping: from time to time programmers demonstrate interim functionality to business users. Thus business users can monitor product development and test CRM functionality during—not after—implementation. End-user feedback about CRM functionality and desired changes can be flagged and incorporated into the CRM deliverable to ensure that resulting functionality conforms to requirements and meets user expectations.

Of course, development mostly involves technical work and thus might also include such tasks as database design, data cleansing and integration, and integration with other corporate systems. The integration step can easily be underestimated, because the CRM system might need to feed data to and pull data from other systems, such as call-routing systems or existing sales force automation (SFA) tools.

Delivery

The delivery step is often overlooked or lumped into development. Basically it means leveraging the corporation's IT infrastructure to dispatch the resulting CRM software to the business users who need it. In the case of a new Web-based sales-force automation tool, the application might be announced via an e-mail message that contains a link to the new CRM Web site. If the CRM system is client-server based, it will need to be installed on individual workstations.

Often, new CRM functionality simply supplements an existing operational system and is not considered a new standalone system. For instance, a contact center representative might now see a "screen pop" displaying a customer profile when the customer calls in. In such cases, business users might not even be aware of the new feature before it appears.

In both cases, user training is paramount. Before a salesperson begins using a new SFA package to schedule meetings or a CSR tries interpreting a customer's profile, she should be trained not only in using the new functionality but also in changing the way they work so they can take maximum advantage of it. Often, a customer-facing representative having new or improved customer knowledge can alter the way she interacts with the customer. For this reason, CRM training should incorporate introductions to new business processes as well as new technology.

CRM delivery can also include user guides, job aids, and other documentation, as well as online or Web-based help to encourage users to make the most of the new CRM functionality.

Some companies go so far as having CRM sharing meetings to introduce the business at large to a new or pending system, and CRM business sponsors hold periodic update meetings, filling in various organizations and key staff members on CRM's progress.

Measurement

The measurement step brings the CRM roadmap full-circle as it evaluates CRM usage in order to refine CRM requirements. Many companies forego ongoing CRM measurement; such companies are confident they won't have to answer for their CRM expenditures. But can you truly claim your CRM program is a success if no measurements are in place to prove it?

In most cases management expects regular updates on programs in which they've invested heavily, and CRM is expensive. Savvy business sponsors define CRM success metrics as a result of the initial justification of CRM, and measure the successes after CRM has been deployed. For instance, if your new CRM system automates workflow to communicate widget defects to your R&D department, you might consider tracking the decrease in product defects and a corresponding increase in customer satisfaction for customers who have widgets. This measurement can include value quantification—such as lower support costs due to fewer support requests—and thus prove return on investment.

Another way to measure CRM's success is to evaluate how well it has solved existing business problems. If you established success metrics when you created your CRM business plan, supplement them over time by correlating them to actual results. Documenting success metrics along with their actual measured improvements is a valuable way to track and quantify tangible CRM business benefits, as illustrated in Table 9-4.

Table 9-4: CRM Success Measurement

CRM Success Metric

Desired Improvement

Measured Improvement(6 months)

Measured Improvement(12 months)

Reduction in the time required to generate customer name-and-address lists for targeted mailings.

Campaign list generation to take 1 day or less.

Campaign list generation takes 3–5 hours.

Campaign list generation takes 1–4 hours.

Ability to make product recommendations to customers during support request (online or phone-based).

Recommendations result in cross-selling improvement rates of 8 percent or higher.

Customer support cross-selling increase of 6 percent.

Customer support cross-selling increase of 10 percent.

Electronic distribution of customer sales reports to sales management.

Elimination of sales staff responsibility to produce weekly and monthly reports, generating a productivity increase of 5–10 percent.

11 percent increase in sales productivity and reduction of one full-time administrative position.

12 percent increase in sales productivity.

Reduction in time spent analyzing data to correct contradictory customer data from sales and provisioning systems.

Elimination of need for data correlation by implementing centralized customer database.

None—database pending.

Elimination of data correlation, resulting in redeployment of two full-time data analysts.


Improvement is usually gradual as users become familiar with new technology and business processes. An effective CRM program delivers ongoing improvements as it's adopted more widely throughout the company. The 12-month measured improvement column represents the rate of improvement since the launch of the CRM program and illustrates this incremental gain.

Measurement also includes the incorporation of user feedback to improve CRM usability and business effectiveness. As the CRM implementation roadmap shown in Figure 9-3 illustrates, CRM measurement loops back around to further CRM business planning, allowing the company and its lines of business to continually refine CRM requirements and identify new CRM opportunities at the same time. If you incorporate measurement and feedback into the planning cycle, CRM will deliver new and better functionality, resulting in small victories that add up to improved customer value.

Putting the Projects Together

After you've identified your CRM projects, your PMO or project managers can agree on an overall CRM timeline that will be enhanced and supplemented as the business uses CRM and customers begin experiencing the benefits. The projects identified in Figure 9-2 can become components of an overall CRM program timeline, as shown in Figure 9-5.

The solid boxes at the beginning of each project connote the fixed amount of time allotted for the business-planning phase. This phase includes project scoping; thus project durations might change after business planning is completed. Each project will have its own development-project plan reflecting more specific tasks and resources.

Figure 9-5 CRM program timeline

A visual timeline like the one in Figure 9-5 is not only effective in managing expectations about each project's forecasted delivery time frame; it can also become the basis for a CRM program document in which the project manager or development team leader can include individual project plans, requirements documentation, and specific CRM functions and features, either as a physical document or as part of your company's web-based knowledge management infrastructure. Thus managers and stakeholders can access up-to-date information about current CRM activities.

  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020