While Federal agencies have historically struggled to find shared services that meet their needs, OMB’s focus on Quality Service Management Offices (QSMOs) is making effective changes. Efforts to establish more robust shared service marketplaces with clearly identified options for customers, rigorous standards, and strong governance structures are helping overcome past barriers to shared service adoption. With eager customers able to better access and understand the benefits of their offerings, shared service providers (SSPs) must pivot from making great services used by a few close partners to fully comprehending the challenges of delivering value to multiple partners and developing strategies to address those challenges. TCG’s work with six major federal shared services over 26 years shows that this is a matter of partner management and customer service, and that these practices are central to SSP’s managing the process of scaling up.
Agencies surveyed for a July 2019 GAO report on working with shared service providers for data submissions stated that the teams providing technical support were too small to effectively assist all the partner agencies. This created bottlenecks, particularly at busy times of the fiscal year, and led to problems with timeliness and data quality in reporting. In other words, customer service levels meant agencies had difficulty in achieving one of their key business goals. Due to funding restrictions, providers were not able to add staff to increase the available support. In addition, the report mentioned a lack of senior project management to coordinate efforts to resolve issues and document progress and key decisions. Issues with resources like these may be caused by many factors but, in our experience, are fundamentally problems of managing scaling.
SSPs are naturally driven to grow their offerings. The economies of scale achieved through delivering standardized and proven processes and tools to an increasing number of customers is fundamental to an SSP’s value. While increasing the number of partners can provide funds to improve a service offering, the quality of the offering will suffer unless growth is skillfully managed. SSPs need to resist the imperative to grow beyond the near-term scalability of their tools and technologies to avoid stretching resources beyond their ability to provide a quality offering. But scaling is still necessary. So how can successful SSPs manage it?
Practice 1: Focus on Customer Experience
Collecting quality data on a current service offering from existing partners is key to assessing the potential for adding new capabilities. Feedback needs to be understood in relation to how different partners are responding to the same features or processes. In other words, data from multiple partners needs to be correlated. SSPs need mechanisms to focus on stakeholder management by developing customer outreach strategies that incorporate:
- monthly meetings to gather requirements,
- discussions of proposed new features (product roadmap),
- demos of new features about to be implemented,
- challenges of key features presented by partner agencies, and
- meetings for internal and external user groups to design and approve end products.
These mechanisms ensure that service development occurs with the needs and requirements of partner agencies as the priority: customer experience should rule all.
SSPs should leverage available tools and technologies to conduct surveys and obtain feedback, using service level agreements or MOUs as the basis for the surveys. We recommend assessing customer sentiment via additional questions that are akin to the CPARs ratings areas including:
- Quality
- Cost Control
- Schedule
- Time Management
These offer some standard areas around which customers can begin to provide feedback.
Another method to obtain quick, actionable feedback is to use Net Promoter Score (NPS) to ask end users one question in a non-intrusive, immediate fashion. NPS is commonly used in private industry but it has not been as fully leveraged in the federal government. NPS results in fast metrics indicating which end users (and, hence, agencies) are “promoters” of the shared service and those who are not. By focusing on what’s working, and understanding who is less satisfied, SSPs can rapidly resource response teams to build on the good and address the less good.
Practice 2: Financial Analysis is an Ongoing Practice
SSPs have to manage and analyze financial data to align funding with service delivery. SSPs’ default position is to make sure that current levels of funding received can deliver the capability promised without a negative impact on everyone’s financial situation. Working capital becomes a key constraint; customer agencies don’t want to lose funding to the SSP’s R&D but nor do they want the service to degrade over time. Growth of the customer base can address this dynamic, but if improvements are undertaken without expanding the existing customer base, then this will mean increased costs to existing partners. On the flip side, SSPs must ensure that they expend all funds obligated to run their service, if a Working Capital Fund (WCF) is otherwise unavailable, and utilize all funds within their allowed limits.
So whether concerned about budget shortfalls or overages, SSPs need to be capable of high-level financial analysis to determine areas of advantageous investment. This analysis needs to be built on collecting quality performance and budgetary data from around the product, so it is in part built on the feedback that SSPs receive from partners (Practice 1). It is essential to balance this feedback and understand the applicability of any new feature or capability for the entire community. This isn’t to suggest that features demanded by few partners should be ignored, only that their funding model needs to reflect that fact. If a more niche functionality is demanded by a partner, that partner may need to invest in that for the entire community’s potential use—and only the SSP can have enough data and insight to appropriately make that case.
Practice 3: Leverage Technology and Proven Development Standards
As SSPs often acknowledge, migrating to a shared service has a lot in common with a traditional migration or modernization project. According to the Administrative Resource Center (ARC) at the Department of the Treasury, “Both implementations require strong project management, knowledgeable subject matter experts (SMEs), and a thorough understanding of your agency’s business processes and data.” But unlike implementing a traditional migration, SSPs may need to rethink what constitutes the best value in terms of technology.
For instance, if resources for deployment and support will be managed by a small team, then choosing or developing a tool that can be deployed and updated easily would be a distinct advantage that may be worth prioritizing over other features. TCG’s work on the Budget Line of Business Apportionment Manager is a good example of this. To serve the budget community’s apportionment requirements, the team used Atlassian’s Jira product and a specially designed plug-in to simplify the tool for non technical users and improve workflow, data collection, and reporting capabilities. The Budget LoB is a small team without extensive resources but the tools allow any team member—from project managers to business analysts—to build out a basic configuration file to the components needed by community members. Non-developers can work on a new system and updates, and avoid using outside support team to manage the platform and the plug-ins. With greater control over the tool, the team better serves its partners in the budget community. Cost/savings analysis for the Apportionment work shows the initial implementation was approximately $500k cheaper than a traditional acquisition activity could provide, and was fielded in less than half the time—an estimated $1M saving for each agency. One Budget LoB Partner Agency reported that this tool brought the Apportionment processing time down from 30 days to about 13 days.
More generally, any SSP or potential SSP needs to assess its own capabilities in software development and systems engineering. TCG’s approach is to leverage Agile development to ensure proper communication and evaluation of new features, from business owners to the development team and outward to users. From the perspective of the different members of a scrum team, using Agile in a shared service environment is not very different from other development projects. However, a more diverse set of user requirements may add a different wrinkle to things like product refinement sessions. Expertise and certification in the Scaled Agile Framework (SAFe) can help ensure Agile practices can be scaled to the enterprise level. Refinement sessions of requirements in the Product Backlog are used to assess the value of a feature and the effort required to implement it. From the assessment, the development team can collaborate on prioritizing items in the Backlog. Incremental and periodic implementation of value-added features and capabilities enable users of the shared service to further assess the new features.
Summing Up
Robert I. Sutton is a professor of management science and engineering at Stanford University. In his book he and his co-author Huggy Rao, who holds an endowed chair at Stanford for organizational behavior, note that, “scaling requires addition and subtraction.” Growth for growth’s sake is not sustainable. Data gathered through customer feedback, financial analysis, and maturity assessments may lead to the conclusion that growing certain capabilities or maintaining others may not make sense for either the SSP or the shared service community.
Assuming scaling does make sense—something on which OMB, GSA, the QSMO leads, and many SSP customer agencies already agree—we must acknowledge what Sutton and Rao conclude: “Scaling challenges nearly always come down to the same problem: the difficulty of spreading something good from those who have it to those that don’t—or at least don’t yet. It is always, in other words, the problem of more.”
For shared services, this means more customers and more capabilities, which inevitably lead to more challenges. To take a quality service offering that originated as an internal solution for a single agency and share it with other organizations demands concentrating on customer experience, rigorous financial analysis, and assessing one’s own maturity level in software development and systems engineering. Scaling and quality customer service go hand-in-hand.