Case Study
Thomson Reuters
Project Revelation
Supplier Management & Services Workstream
Background
Project Revelation is a large programme of work to transform the company's third-party content business. Within the programme, there are various workstreams, one of which is the Supplier Mananagement piece where currenty there are over 1,500 providers of third-party content.
Many contracts contain complex restrictions on how the content can be used and impose various duties and obligations on Thomson Reuters and its customers.
The aim of Revelation is to provide internal teams with the tools, processes and capabilities they need to accurately and reliably manage reference information about supplier contracts, services, content assets, content usage rights and restrictions.
Under-pinning this project is the Revelation Business Information Model, a new data model to capture all this data in a more structured way.
The Task
This case study focuses on the effort to test and validate the proposed data model on the Partnership Managers who are responsible for developing and maintaining supplier relationships inlcuding contract negotiations. They will be the end-users of the new system which will utilise the new data model.
Process
Discovery Phase
User Research was carried out on various Partnership Managers across the globe to understand their current roles and responsibilites, the types of suppliers and contracts they manage and their workflows for their various tasks along with their pain-points on using the current system.
The Data Model
The proposed data model came in the format of an extremely complex Excel spreadsheet, engineered by the Data Architect. In order to test the robustness of the data model, this spreadsheet would provide the basic UI in which the Partnership Managers would enter real contract data including rights and duties into it to generate structured data outputs.
The concern various team members and myself voiced was that an Excel spreadsheet doesn't make for an ideal UI; the Partnership Managers who would be testing the data model via this spreadsheet wouldn't be able to test and validate the data model effectively as they would be critiquing the cumbersome user experience of the form filling in the Excel spreadsheet instead of evaluating the data model itself.
The data model in Excel format
Alternative UI
I proposed an alternative UI based on a HTML form for the input capture of contract data to replace the Spreadsheet version which was warmly received by various team members including the Data Architect but due to concerns by the Project Manager regarding finding appropriate development resources within the time availible before the workshops, this idea was officially abandoned by the team.
However, in my own time, I developed a proof-of-concept HTML-based form to illustrate how much simpler the process would be in validating the data model if the input capture process was made more intuitive, overcoming the limitations of creating a primitive UI in Excel.
After changing the Project Manager's mind with this proof-of-concept HTML form, I worked with the Data Architect to understand the full data model logic and incorporate them into the HTML form as display rules, employing the concept of Progressive Disclosure to hide various form components until the user required them, reducing visual clutter and cognitive load. New rows of questions slide out in response to the user's inputted response, with the animations drawing the user to the new questions in need of attention.
HTML form as UI alternative. View HTML form
Workshops
Four Partner Managers, also known as SMEs (Subject Matter Experts), representing various geographical regions, flew into London to attend a week-long workshop to test and validate the new data model using the Supplier Service Capture form.
1.5 days were spent with the Data Architect educating the project stakeholders and SMEs on the new data model concepts. The remaining time was spent with the Partner Managers testing the data model by inputting details from real supplier contracts.
Each SME had a member of the project team with them as an observer. The SMEs were asked to think-aloud.
Questions and issues the SME encountered were captured along with general observations by the observers including the time taken to complete the task.
5
Day Workshop
4
Partner Managers (1 Americas, 1 Asia Pacific, 2 EMEA)
15
Supplier Agreements
~1.5
Hours to process one contract
Analysing the Results
It was clear that the data model:
- focused on defining rules at the wrong hierarchical level.
This resulted in many duplicate rules having to be cloned at the policy level, rather than just defining the common set of rules at the supplier or service level and having those rules automatically propagate down to the policy levels. - didn't match the users' mental model
in terms of the workflow in inputting the supplier rights and duties data. - didn't offer sufficient granularity in rule definition
to cover complex fee payment structures and general exceptions. - confused users with the terminology used.
The Data Model was designed with the aim that it could be adopted as an industry standard, however some of the terms used mean very different things to the Partner Managers in the context of their job roles. - did not allow users to flag actual financial arrangements where it deviated from the specified details in the supplier contracts.
Due to various operational and technical reasons, this scenario was quite common and capturing the actual financial agreements was vital for the Accounting teams to forecast and report accurate company performance.