Build a Service Portal and Request Catalog

Building a service portal and request catalog is a marathon rather than a sprint. The first two articles in this series, Creating and Enterprise Service Portal and Design Service Portals for User Adoption, focused on creating a service portal customers would adopt, addressing design tips, content management, and the finer points of designing online requests customers are able to complete easily. This final article in the series addresses the roadmap for the effort. It focuses on laying the foundation and building upon it, moving into an ongoing state that continues to enable management of a request pipeline without losing the momentum gained during the initial implementation stages. Laying the appropriate foundation, along with a good process for managing an ongoing pipeline and development effort, will enable the organization to build the catalog, beginning with IT and ultimately expanding to the enterprise, setting the stage to consolidate multiple request platforms into a single portal.

Building a service portal and request catalog is a marathon rather than a sprint.

Management and customers alike want their service catalog complete quickly so they can move on. Unfortunately, they need to understand that, while a service portal can be designed and implemented fairly quickly, the request catalog portion of the portal cannot. It’s possible to hold release of the catalog until it's "done," but this state will never truly be achieved and should not be a goal of the project's delivery. Impatience to get to more complex requests that require foundational requests to be designed and implemented first can lead to a perception that the value is not going to be realized quickly and can also contribute to an organization's fear of starting the project.

A request catalog is a long-term, evolutionary effort that could take years to complete. Most often, the first catalog starts with creation of forms that help the IT support organization gather information and approvals needed to do business: set up new hires, move personnel, provide access, and equipment provisioning. Other providers begin doing the same thing, and eventually the organization finds itself in a multi-catalog dilemma. When an organization is willing to begin a long-term implementation project and mature to their end state, this transformation and the roadmap that goes along with it help them see when IT will gain value from the catalog and then when the business as a whole will start to realize the value.

Develop Your Roadmap

The key is to put a process in place to manage a request pipeline, grouping the initial requests into logical releases that continue to grow the catalog, while maintaining a sense of completeness along the way. To help you get there, I offer a high-level roadmap along with a description of the activities that will take place along the way.

Establish the Vision

Before you begin to build the service portal and its request catalog, establish the end state vision for the effort: is it to be an IT portal, an enterprise portal? Will it replace a corporate Internet site or become an add-on? Will it integrate to other systems to enable full self-service, and if so, which systems?

This is a strategic effort to define the scope of the overall project and requires engaging organization executives first to set this strategic direction and ensure funding and ongoing support. It's also advisable to include a discussion of when other service providers will enter the portal, even though this will likely change along the way. It will help adoption of the effort if people have an idea of when their needs will be addressed.

Identify Stakeholders

Once you establish the vision, select the full slate of stakeholders who will drive the effort. Aside from a project manager and the product owner, stakeholders should include representatives from the organizations that will be offering requests through the catalog, a few additional members from the communications and marketing groups, and some end users. The end users are critical to the overall effort as they will provide feedback that will ensure the ability to gain adoption for the end-state product.

Not all of the stakeholders will be needed in every workshop, so build a RACI chart (a matrix of activities and who is responsible, accountable, consulted, and informed for each of them). This will help determine who is to be involved at every step of the way.

Build the Communication Strategy

Determine the strategy early to ensure the communication check points and development are handled during the appropriate time throughout the project. The strategy should include a listing of the communications needed and their audience, channel, and timing. It should also assign the drafting and editing of these communications to the people responsible for them. 

Establish Portal Content

Defining the content that will be available within the portal enables the organization to plan for the delivery of the content in an organized and easy-to-find manner. The content piece includes many aspects of portal design, as I describe in Design Service Portals for User Adoption.

Document Request Requirements

Develop a basic set of requirements for request design and workflow before beginning to aid in tool selection. Before beginning, it's worth inviting a few top players in the market to demo their products and talk about their unique features. This effort will establish what is possible and will enable your stakeholders to identify the features and functionality they would like to leverage going forward.

You have a wide variety of tools to choose from, and the feature set will help drive selection. One decision that is helpful to make early on is whether providers will move their support management into the request tool or use it as a front-end catalog only. This will drive the types of integrations required and the level of effort needed to accomplish them. There's no right or wrong answer here. If providers are adamant about remaining in their current management tool, a product designed as a front-end catalog might provide easier integration than standard service management tools. These types of decisions will ultimately help narrow a very competitive field.

Select the Tool

This point is hotly contested, but it's helpful to know the tool before diving into detailed design. What? Isn't it process before tool? NO: do the process work up front at a high level by understanding the content to be included, the requests, and their fulfillment processes. But select the tool before documenting the detailed requirements needed to begin development. Essentially, follow these steps:

1. Set the overall strategy
2. Define the business and functional requirements
3. Select and source the product to be used
4. Collect detailed technical requirements
5. Design
6. Chart the final effort
7. Go!

Finalize the Request Listing

While it's helpful to envision a list of requests the portal might include early on in the process, this is the point in the project where you need to finalize a full listing of expected requests in order to design the catalog’s organization and prepare for development and the first release.

Prioritize Requests

Once the list is complete, it will be clear that this is not a project that can be completed in just a few months. This is where it becomes important to be able to prioritize requests and slot them into releases (this is a great opportunity to use Agile/Scrum development methodologies as they lend themselves to projects that will be delivered in an ongoing development cycle). The goal with request prioritization is to group requests into logical releases and set a schedule for when providers will join the catalog. In cases where the catalog's back-end tool is replacing a request catalog solution currently in use, it's important to consider timing and make certain that a single category of requests is not broken across more than one tool and that providers’ work management is not split across more than one tool. Thus, you can implement some low priority requests in an early release to avoid splitting functionality.

The prioritization effort will start to refine and secure the roadmap for when providers will begin to see their requests become available. It's worth mentioning that if a provider is resistant to joining the effort, it's fine. Let them be lower in priority until success and adoption are established for other providers.

Establish the Cycle

At this point, the effort is ready to move into an ongoing cycle that will continue to drive momentum and establish the cadence for future releases. The steps will follow this pattern:

1. Define requirements
2. Build 
3. Test and prototype
4. Improve
5. Release
6. Repeat

Once project participants understand that requests will be continually developed and released, they will continue to seek opportunities to expand the catalog, thus the repeating cycle.

The final aspect of the roadmap includes the practice of continually improving the catalog. While including end users in the effort provides an opportunity to gain their feedback on the design of the portal and catalog on an ongoing basis, it's also important to survey users and providers to solicit their feedback. Their recommendations should be reviewed, and improvements should be built into the pipeline for development. As some feedback may correct critical defects (such as workflow issues that cause fulfillment to fail or that create bottlenecks), it may be practical to move into a two-sprint release cadence: the first sprint adds requests, the second fixes defects and enhances requests that are already live. With two-week sprints, you can then count on a monthly release to address design issues promptly over the longer term.

There's far more to building a catalog than I present in this roadmap. But I hope you now have a sense of the activities that result in the rollout for an enterprise service portal and request catalog. This roadmap also sets the stage for an ongoing effort that keeps growing functionality, but that will never be complete.

Phyllis Drucker is an ITIL-certified consultant and information leader at Linium. Phyllis has more than 20 years of experience in the disciplines and frameworks of IT service management, as both a practitioner and consultant. She has served the itSMF USA since 2004 in a variety of capacities including volunteer, board member and operations director. Since 1997, Phyllis has helped to advance the profession of ITSM leaders and practitioners worldwide by providing her experience and insight on a wide variety of ITSM topics through presentations, whitepapers, and articles and now her new book on the service request catalog, Online Service Management: Creating a Successful Service Request Catalogue (International Best Practice, forthcoming 2016). You can read more of her work such as the “What’s in Your Service Catalog” series and her “Self Service, the Cloud and ITSM” articles on Linium’s website. She will share sample designs for a service portal of the future when you sign up for a free portal consult.