
Unlocking access to reliable third party ESG data and insights for PwC teams
ESG Data Brokerage
Problem
PwC teams recognised that clients need dependable ESG (Environmental, Social, and Governance) data to comply with regulations and achieve their sustainability goals.
However, the way these teams were getting ESG data was inconsistent and based on immediate needs. There wasn't a unified process for acquiring and managing third-party ESG data within the company.
Brief
To design and pilot an internal service for PwC staff to effectively source, acquire, manage, and analyse ESG data to better meet clients' ESG needs and provide differentiated insights.
Approach
As the scope of the service was extensive, it was split into two parts -
-
Sourcing and acquiring reliable ESG data was designed alongside a trial of ESG data acquisition.
-
Accessing, managing and analysing the above ESG data, was designed based on the needs of PwC teams, identified through user research.
This case study details my role as a service designer in a multidisciplinary team of 4 (including a product manager, ESG data analyst, and technical architect), designing the the end to end service for sourcing, acquiring, managing and analysing third party ESG data within PwC. My responsibilities involved -
Understanding users and their challenges
Defining the service value proposition
Designing the end to end service
Making a case for the service
Understan-
ding users
Even though ESG data was being used by PwC employees to deliver their client engagements, this was being done inconsistently. To understand better these users and their specific challenges pertaining to accessing and managing ESG data, I -
-
Planned, organised and conducted interviews with 10 users (ESG data users) across different parts of the organisation (1.1)
-
Synthesised and analysed the insights to draw out common themes, archetypes and specific need statements
-
Prioritised the needs (1.2) based on how many times they were alluded to in the interviews and how impactful solving for them would be to the user group
As a result, I highlighted that users had 3 main needs - easy access to ESG data, better information about how this data can or cannot be used, and ability to source new ESG data for emerging needs.
1.1 Interview insights

1.2 Prioritisation of needs

Defining
the value proposition
After identifying key user needs, I helped move the team from the problem space to the solution space. Some of my key activities included -
-
Translating the need statements into user stories, detailing ways in which these needs could be met. This helped identify the service requirements (2.1)
-
Validating the user stories for feasibility and viability with business stakeholders - giving them a score of 1-5 to determine if they were to be implemented now or later
-
Using the ratings to help determine the scope of the service for the pilot
-
Formulating the value proposition of the service by putting together the prioritised user needs and scoped service requirements (2.2)
This exercise highlighted that the ability to acquire new ESG data from third parties would influence how users eventually access and use this data.
As no one in the firm had previously acquired ESG data on a large scale and because it was anticipated to require a lot of resources, the team had to design the sourcing and acquiring service alongside an ongoing trial of ESG data acquisition.
2.1 Defining user stories

2.2 Creating the value proposition

Designing
the service
Combining the user stories and a preliminary understanding of the ESG data acquisition trial, I created an initial view of the to-be service (3.1). In order to refine this, I -
-
Planned and organised multiple workshops with key stakeholders who would be involved in delivering the service, subject matter experts, and leaders
-
Ensured every stakeholder was able to build on the existing service view to design a more desirable, feasible and viable service
-
Through various iterations of mapping the to-be service (3.2), I clearly highlighted key considerations and assumptions related to that will need to be tested during the delivery of the pilot.
-
Enabled the product manager to define the requirements for the technical infrastructure that would facilitate this service
As a result, the team was able to build an end to end view of the service that all stakeholders felt confident about and one that was designed to meet the identified user needs.
3.1 Initial view of the to-be service

3.2 To-be service mapping

Making a business case
The to-be service required several resources and technology solutions to be orchestrated together for a pilot. In order to secure the funding to facilitate the pilot, I lead on the following activities, using the to-be service mapping -
-
Formulating the operating model (4.1) - defining key people, capabilities, roles and responsibilities. This enabled the creation of a robust cost structure for the delivery and maintenance of the pilot service
-
Outlining the outstanding key decisions and actions (4.2) needed to enable the delivery of the pilot service
These formed a key part of a strategic business case that secured £2m in initial funding to develop and deliver the pilot service.
4.1 Initial view of the to-be service

4.2 Key decisions and actions
