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 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 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.