Home > Articles > Service Design and Building the IT Service Portfolio

Service Design and Building the IT Service Portfolio

  • Sample Chapter is provided courtesy of Cisco Press.
  • Date: Apr 6, 2018.

Contents

  1. Service Portfolio Overview
  2. Designing IT Services
  3. Designing the Service Portfolio
  4. Summary

Chapter Description

In this sample chapter from IT as a Service (ITaaS) Framework, The: Transform to an End-to-End Services Organization and Operate IT like a Competitive Business, examine the purpose, goals, and value potential of a Service portfolio. You’ll also explore how to design specific elements of the Service portfolio and review various guidelines, best practices, and lessons learned for the successful design of IT Services across the enterprise.

IT Transformation teams now have a clear definition of an IT Service that supports the goals of the Service delivery framework. They also have a multilevel taxonomy providing a structure for the strategic management of the target Services landscape and a complete mapping of technical capabilities required across the enterprise to enable the execution of business processes. With these and other inputs provided in this chapter, transformation teams can now begin the design of IT Services and build the Service portfolio.

Before we begin, however, we should reevaluate the purpose, goals, and value potential of a Service portfolio. The portfolio within the ITaaS framework is no longer a simple listing of IT Services. Instead, the introduction of the Service taxonomy introduces a hierarchy to the portfolio and requires us to designate elements beyond just IT Services; it also enables a number of value capabilities and outcomes for Service delivery. With this in mind, this chapter provides a complete overview of the ITaaS framework’s Service portfolio, including considerations, structure and design, and even the recommended workflow for developing and finalizing.

From there, the focus shifts to designing specific elements of the Service portfolio, dedicating a considerable amount of time to reviewing the various guidelines, best practices, and lessons learned for the successful design of IT Services across the enterprise. We also cover guidance for the design of each Service type, along with the designation of elements at each level of the Service delivery taxonomy. Cisco’s ITaaS framework includes a complete reference portfolio, capable of significantly accelerating this extensive effort, allowing transformation teams to focus on the design of IT Services unique to their enterprise industry and business. The reference portfolio, along with guidance for leveraging it, are included in Appendix A.

Service Portfolio Overview

Service portfolios are far from a novel concept; in fact, IT Service management standards have for years advocated for their use in managing IT Services. Consequently, portfolios can be found in place across most enterprise IT organizations. Cisco’s ITaaS framework also leverages the concept of a Services portfolio, retaining its core intent as an artifact for organizing and managing IT Services while also striving for a more strategic purpose within the framework for IT Service delivery. The following sections ensure that you clearly understand the purpose, goals, and value of the Service portfolio and its impact on Service delivery. Transformation teams should remain conscious of a number of considerations, and they need to carefully review their design approach and general workflow for building the portfolio, which spans gathering all the required inputs to vetting, finalizing, and administering the IT Services portfolio.

Purpose and Value of the Service Portfolio

Many IT Service management standards leverage the portfolio solely as a tool for listing Services. While this basic function will remain the ITaaS framework leverages it as a vehicle for applying the Service taxonomy, allowing for summarization of information at each level of the hierarchy and positioning it as a strategic tool for IT leaders as well. The foremost purpose of the IT Service portfolio then becomes to support planning and execution of strategies at different levels of the Service delivery hierarchy.

As an example of this value potential, say a Service delivery team aligns summarized information for Service costs and performance at the Strategic Service Group level. Recall that Services are aggregated at this level in order to support strategic planning. Simply associating costs and performance with a portfolio listing of over a hundred individual IT Services can provide a valuable reference to specific Service delivery teams but is not conducive to strategic planning. When we summarize Service cost and performance information at higher levels of our hierarchy, however, we effectively create a strategic dashboard for IT leaders. These multilevel dashboards enable quicker assessment and even monitoring over time of strategic segments of the Service landscape, and it is the portfolio that would drive these informational views

While its use as a strategic tool receives most of our value examination, the Service portfolio serves additional purposes within the ITaaS framework. At its most fundamental level, through the application of the taxonomy it helps organize an otherwise cumbersome list of Services, making the portfolio easier to navigate and administer even for those IT organizations that choose to leverage it strictly as a basic reference for IT Services. In practice, it may exist as a reference artifact for Service delivery that additionally feeds a strategic dashboard. Regardless, it will always exist as a primarily IT internal tool. It will also be used to derive the IT Service catalog, which is leveraged to enable customer request portals, such as corporate e-stores as described in Chapter 11, “Completing the Services Transformation.”

The ITaaS framework’s IT Service portfolio still acts as a valuable reference for Services and related information, but it also acts as the point of execution for the Service taxonomy, allowing the portfolio to be organized and administered more easily. Through the association of carefully designed information sets at each level of the Service delivery hierarchy, the portfolio also becomes a multilevel strategic dashboard for IT leaders.

Service Portfolio Considerations

With the purpose and potential value of the Service portfolio clearly established, IT Transformation teams are likely eager to begin designing Services. Before they begin, however, they should remain conscious of a number of considerations, both general and specific, in the design and development of the Service portfolio.

The first general consideration for the portfolio is that it represents a significant effort. Design of a complete Service portfolio is complex and is also likely to represent the largest task that IT Transformation teams will face in the Services Transformation Program. Development of strategies for Service costing and performance represent significant efforts as well, and have the potential to present as much or more complexity, but the breadth of the portfolio design along with its own complexities mean it will typically represent the most time consuming effort, often far in excess of original timeline estimates of most teams. Remember that the team is not only designing a complete set of IT Services capable of delivering capabilities end-to-end across the enterprise business but is also designating elements at each of the additional levels of the Service taxonomy. Be sure that IT leaders, stakeholders, and the transformation team understand the task and be sure to not overcommit on timelines.

The complexity inherent in the effort is another consideration. There are numerous opportunities for proposed designs to veer from best practices or for teams to take different directions, resulting in discontinuity in the designation of elements within a given level of the portfolio. The length of the effort may lead some team members to fall back on historical approaches to IT Service design that contradict the ITaaS framework’s definition of an IT Service and fail to support future strategies for costing and performance. Change leadership is critical in driving consistency end-to-end and ensuring that proposed Services adhere to the established definition and characteristics of a Service and best practices shared later in this chapter, and that they support the guiding principles for Service delivery.

A key advantage for IT Transformation teams is the ITaaS framework’s inclusion of a reference portfolio, which is shared along with guidance for use in Appendix A. This reference portfolio provides transformation teams with an initial set of Technology Foundation and Enterprise End-Customer Services common to IT organizations across any industry. These Services act as a guide for further Service design and can be easily customized and adopted. Doing so can significantly reduce the level and complexity of the overall effort and allows teams to focus the bulk of their energy on the careful designation of Business Operations Services unique to their industry and enterprise business.

Remember that although the bulk of the effort to design the Service portfolio is carried by the IT Transformation team, it does not represent a task that can be completed solely within the team or even internally to the IT organization. The entirety of the portfolio needs to be vetted across relevant stakeholders and refined based on their feedback. Practices for vetting are detailed later in this chapter, but must leverage value messaging and Service transformation educational material managed by the change leadership function. Review and vetting of the proposed portfolio take place across three primary stakeholder groups: IT leadership, IT internal stakeholders, and business stakeholders.

As IT Transformation teams progress the portfolio and begin to review with stakeholders they should consider tactics for effectively presenting and reviewing the appropriate sections of the portfolio. The most commonly used tools for managing in-development Service portfolios are spreadsheets, which can easily capture and sort relevant data but are not always the most favorable method for reviewing a proposed set of Services for input. Cisco recommends leveraging graphical illustrations of the portfolio—for example, simple block diagrams of a specific segment of the portfolio that can be more easily presented and reviewed. An example is shown in Figure 6-1.

Figure 6-1

Figure 6-1 Sample Service Portfolio Block Diagram

Aside from managing the portfolio throughout the design phase, transformation teams should also begin actively considering the requirements and ideal platform for hosting the portfolio in the long term. Remember, the ITaaS framework presents the opportunity to leverage the IT Service portfolio as a multi-level strategic dashboard, but this requires a platform capable of summarizing Service information at different levels for IT leaders. Even if transformation teams opt to initially leverage the portfolio only as a Service reference, they still require a platform that supports remote navigation and administration because the portfolio will not remain static and must be managed over time if it is to evolve with the needs of the business.

Portfolio Design Considerations

Several of the considerations that IT Transformation teams must evaluate are specific to the design and approach to building the Service portfolio. Note that a number of these considerations will echo recommendations highlighted in Chapter 3, “Change Leadership and Ensuring a Successful Transformation.”

Chapter 3 recommended a top-down and end-to-end design of IT Services to ensure complete alignment and the efficient operation of the IT organization. The top-down approach means beginning with Business Operations and Enterprise End-Customer Services types and then designating only those Technology Foundation Services that are required to support them. This approach ensures all of IT’s resources and assets are aligned to justified Services and often leaves IT organizations with opportunities to shuffle or realign those that cannot be, ensuring they are operating efficiently. Portfolio design efforts that begin with Technology Foundation Service types tend to force alignment of IT assets early on and rarely achieve the level of efficiency that a top-down approach does. Separately, the end-to-end design of Services supports the transition to an ITaaSO, allowing for the creation of a parallel view of IT resources, assets, and budgets aligned to Services in a manner that cannot be reflected when only pockets of Services are designated.

The ITaaS framework’s reference portfolio supports this same top-down design approach, allowing teams to focus on Business Operations Services from the beginning. Then, as they transition to Enterprise End-Customer and finally Technology Foundation Services, their work involves aligning the remaining requirements to IT Services listed in the reference portfolio, customizing where needed, omitting where requirements do not exist, and finally designating Services for any capability requirements that have not been accounted for by the reference portfolio.

Portfolio Design Inputs

Before beginning development of the Service portfolio, transformation teams should confirm they have all the relevant inputs available and take time to carefully review each:

  • Service definition

  • Service delivery taxonomy

  • Enterprise Technical Capabilities (ETC) map

  • ITaaS reference portfolio

  • Guiding principles for Service delivery

  • Existing Service management artifacts

While each of these should be familiar to readers, it warrants highlighting the use of existing artifacts for IT Service delivery. The ITaaS framework’s unique and more strategic design of IT Services warrants the development of a new Service portfolio to support the new approach to IT Service delivery. That does not mean that existing Service portfolios, catalogs, and other data and documentation that have been previously leveraged in support of Service delivery are not useful. On the contrary, many of these assets can be leveraged successfully in the design of the new portfolio, often simply mapping to new levels of the taxonomy other than Services. For example, many elements from prior portfolios can often speed the designation of Service Offerings, especially for Technology Foundation and Enterprise End-Customer Service types, or eventually be mapped to IT Service catalog requests as detailed in Chapter 11. The key consideration for transformation teams is knowing what exists and then taking advantage of it whenever possible without sacrificing the guiding principles and future desired outcomes for IT Service delivery.

Portfolio Development Workflow

Following is the general workflow recommended for the development of the IT Service portfolio:

  • Structuring the Portfolio: Transformation teams designate specific data elements for the portfolio, creating an initial information set aligned to each level of the taxonomy.

  • Designing the Services: The Service definition, reference portfolio, and ETC map are leveraged to design a complete initial draft of IT Services end-to-end across the enterprise. Note that Cisco recommends conducting initial Service offering design, capturing potential Service asset information, and documenting likely Service chains during this phase as well.

  • Designing Remaining Portfolio Elements: As the complete set of Services nears completion, the Service taxonomy is leveraged to designate elements for the organizational levels of the portfolio (Service categories and Strategic Service Groups within Cisco’s ITaaS reference taxonomy).

  • Vetting the Portfolio: Transformation teams begin reviewing the initial proposal for the portfolio across each stakeholder group. All feedback should be carefully considered for potential incorporation and refinement of the proposed portfolio.

  • Identifying Service Chains: Teams document all Services participating in Service chains, which inform Service cost modeling and Service performance strategies.

  • Finalizing the Portfolio: IT Transformation teams conduct an end-to-end review of the portfolio, evaluating the design consistency, support of guiding principles for Service delivery, and any remaining requirements to support the IT operating model and enterprise business.

Timeline ranges are not included because they can vary so drastically depending on variables ranging from enterprise size and operational complexity, the inputs leveraged, and the transformation team’s experience and grasp of the ITaaS framework as a whole. As a general rule, the Service design represents the most significant and time-intensive step, with the design of the remaining portfolio elements often completed in one-third or even a quarter of the time. Considering the design activities requirement to span the enterprise end-to-end, even stakeholder availability to engage with transformation teams can have a significant impact on the vetting timeline, but the portfolio can typically be finalized in a matter of weeks.

Although these steps are largely sequential, transformation teams can easily stagger each phase in a waterfall approach, as illustrated in Figure 6-2. The key is to recognize that beginning the next phase in sequence too early before completion of the current phase can both jeopardize the quality of the design and lead to significant rework. As an example, designation of Service categories and Strategic Service Groups often becomes clear after the first rounds of Services are submitted but would represent pure guesswork if begun at the same time as the Service design effort.

Figure 6-2

Figure 6-2 Service Portfolio Development Workflow

Structuring the Service Portfolio

It is important for IT Transformation teams plan the information that will be associated with the Service portfolio, both initially in support of Service design and longer term to support strategic planning. The eventual transition to strategic dashboarding depends on information from Service costing, performance, and other strategies not yet available to the transformation team, but it is important to plan for its eventual adoption into the portfolio.

Following are the most basic data elements for the Service portfolio:

  • Strategic Service Group

    • Service Executive: [Name]

  • Service Category

    • Service Architect: [Name]

  • Service

  • Service Description

  • Service Owner

  • Service Delivery Resources

    • Service Architect: [Name]

    • Service Offering Manager: [Name]

    • Service Executive: [Name]

  • Service Offerings

  • Service Asset References

    • Application Set

    • Product or Device References

    • Resource References

  • Service Performance Information/Link to Dashboard

  • Service TCO Information/Link to Dashboard

  • Technical Capability Set: [Description of capabilities delivered by the Service, or link to ETC map]

At any time transformation teams engage with a stakeholder group to review segments of the portfolio, they should consider what information the meeting could be leveraged to capture and add to the portfolio. For example, a stakeholder may agree to the proposed Service and then provide an initial proposal for Service Offerings associated with the Service that the transformation team can then refine. Capturing Service Offering and Service asset references whenever possible can save future Service Owners time and help them quickly get the newly initiated Service optimized.

Vetting the Portfolio

As the portfolio nears completion, it is important to review and refine segments with specific stakeholder groups. The complete set of proposed Services along with Service categories and Strategic Service Groups should be reviewed with the IT leadership team. Groups of Services and potentially their aggregation should be reviewed with IT internal communities that ultimately support the architectures, processes, and budgets that enable the proposed Services. Remember that Service Owners and other Service delivery roles will likely be established from this same group of stakeholders. Finally, segments of Business Operations Service types should be reviewed with their associated stakeholder groups across the enterprise.

Initial proposals for Service Offerings and Service asset references can also be reviewed, but newly appointed Service Owners should be encouraged to refine them to support the most efficient management of the Service. Review and finalization of the portfolio are primarily focused on Services, and the most effective aggregation of those Services for IT leaders.

It is important for transformation teams to strike a careful balance for actively gathering input and determining how long to allow the vetting processes to proceed. The goal here is to avoid “analysis paralysis,” or scenarios in which teams allow never-ending serial review of a section of the portfolio, enabling competing stakeholder groups to constantly override one another in a never-ending loop. Chapter 3 called out the “80/20” rule as a best practice for supporting a successful transformation program and also highlighted senior commitment to a “Centralized Authority for Transformation” as a critical success factor. These principles were established specifically in support of allowing transformation teams to gauge when sufficient feedback has been presented, qualified, and incorporated wherever possible and that it is now simply time to formalize a decision to move on with the program.

The general guidelines for IT Transformation teams engaging stakeholders in this critical activity are as follows:

  • Be Prepared: Transformation teams should have not only a prepared set of material describing the approach to Service and portfolio design but also a firm grasp of the current proposal that is being reviewed, paired with an explanation for how the proposed Service would impact the stakeholder.

  • Be Patient: Beyond the initial effort to review the Service and portfolio design principles with stakeholders and presenting the initial proposals, transformation teams likely need to host multiple rounds of review across different teams and mixes of stakeholders to collect all relevant feedback. Always listen intently to the feedback from every round of review and then make the best decision in support of the Service(s) in question as well as the broader transformation program.

  • Expect Change: Transformation teams should never be personally invested in a proposed design but should be ready and willing to update the proposal based on quality input and qualified feedback. Also always be sure to remember that it will not be the core transformation team but likely the stakeholders in the room who will be responsible for managing aspects of the Service in the future.

  • Remember the 80/20 Rule: Could the current proposal be considered as 80 percent right with the opportunity to optimize the remaining 20 percent in the coming months? If so, then move along and allow the best solution to take shape over time as Service delivery teams put the proposal into practice and refine. Remember that even the best designs have to adapt when put into practice; there will always be opportunity for change over time and continuous improvement. The important point is that the proposal is largely right at the moment rather than perfectly right, which it can be in the future.

  • Leverage the ITaaS Framework’s Reference Portfolio: While the reference portfolio can accelerate the initial set of Services proposed for the portfolio, it can also be leveraged as a valuable comparison. Transformation teams should carefully consider cases in which there is little in common with reference Services.

Identifying Service Chains

As they begin finalizing the Service and portfolio design, IT Transformation teams should work to identify all Service chain requirements. Service chaining is a critical mechanism within Cisco’s ITaaS framework for modeling the total costs of Service delivery and understanding the impact of Service performance to other Services. Documenting the Services participating in Service chains helps transformation teams more quickly complete the Service cost modeling strategy as well as improve strategies for Service performance, and even support Service Owners in early Service delivery.

Finalizing the Portfolio

Whenever we discuss the effort of finalizing the IT Service portfolio, we do not mean to imply that the Service and portfolio design is completed for good. As we established previously, IT Services and other elements of the portfolio must be adapted over time to drive the most value from the Service delivery function and maintain alignment to changing business needs. In fact, IT Transformation teams should expect some degree of changes to be made even prior to completing the transformation program. This is a result of putting the Service delivery framework into practice through early Service pilots and Service delivery roles such as Service Owners slowly growing more accustomed to the ITaaS framework.

IT Transformation teams finalizing the initial proposed Service portfolio should work through each of these steps:

  • Accuracy and completion review

  • End-to-end consistency and quality assurance review

  • Review against guiding principles for Service delivery

  • Review and sign-off by CIO and senior IT leaders

The accuracy and completion review is intended as a “did we miss anything obvious?” opportunity. As extensive as the ETC map and efforts to qualify the portfolio have been to this point, something potentially could have been missed, and often it represents a major focus of the IT organization or even an enterprise business strategy. As an example, consider an IT Service portfolio supporting an enterprise that relies heavily on vendors but failed to include a Service delivering capabilities for vendor management simply because the small number of stakeholders who would have identified requirements for such capabilities happened to not have been engaged. Transformation teams should use this as an opportunity to openly challenge themselves with the question “Have we forgotten anything?”

The initial proposal for the portfolio will be built by multiple groups within the IT Transformation team working to incorporate feedback across a wide range of stakeholders; the purpose of the second review is to ensure that the outcome of the design activities is consistent end-to-end. Quality assurance is also considered here—for example, holding up Service proposals against the definition of a Service and ensuring all the requirements identified by the ETC map have been addressed.

The guiding principles review can be conducted quickly but is an absolute necessity and should not be taken lightly. Here again, transformation teams should have high confidence that the outcome of the Service and the portfolio design activity are completely in line with the guiding principles for Service delivery.

2. Designing IT Services | Next Section

Cisco Press Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from Cisco Press 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 Cisco Press 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@ciscopress.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 Cisco Press. 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.ciscopress.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