Data Management Application
Background + Problem
Project Development within the context of carbon credit generation, is the process of identifying and mitigating areas where carbon can be reduced. Project development involves a series of steps including implementing the project, monitoring & evaluating the project, and reporting/documenting progress in order to certify credits. A large, and important part of this complex process is data management.
Data management plays an important part: from identification, to credit certification. Under the umbrella of data management, are sub-processes like data generation, collection, analysis, sharing, governance, and storage. These activities are often best handled by technology, but yet they are not. A non-tech approach can lead to issues with data provenance, quality, auditing, and efficiency.
This project had two phases: 1) product build and 2) policy development. During the first phase, our aim was to focus on the problems above through a product-build assumption as the name suggests. As the vision changed, we moved into a second phase where current development would remain as-is and instead policy would be put into place.
Approach
At a high-level my approach was based on the project phase.
Phase 1 Product build: Nine months
My goal was to better understand the problem space from both the view point of the project sponsors (those who interact with project developers), sponsor leadership and the project developers themselves. During this phase, however, I had little access to project developers, and communicated this as a risk throughout the project.
I used in-depth-interviews when eliciting information, as I was seeking deep, qualitative information. I interviewed approximately 30 participants (project developers, carbon trading experts, project developer management, stakeholder leadership).
I also used co-development sessions with stakeholders, where together we constructed structural diagrams for an application in FigJam. These were combined and provided to a UI Designer for prototype development.
Phase 2 Policy development: Six months
My goal during this phase was to understand how each side of the coin (stakeholders + project developers) conceptualized the key capabilities of a system.
To give findings more structure after the fact, I developed workshops applying Design Thinking to a an X-Y framework: X = Business Architecture Principles, Y = project value chain.
I ran five workshops with 15 participants.
Team structure
On this project I was the lead and sole Researcher. My principal contacts were with the Product Owner (PO) and Product Manager. I also interacted with a (UI) Designer, Business Analyst, Solution Architect, Engineer, and Data Architect. I presented to leadership levels above the PO up to the General Management.
Findings
Research uncovered more fully the logistical issues and impact around the assumed problem areas (data quality, auditing, efficiency). An example of this is a project developer who uses three different tools to conduct their work with none of them interacting with each other. This results in a lot of manual data migration work. Aside from inefficiency, this cause traceability issues which affects audits. My work also led to a product prototype and backlog, should the product had been picked up by the Sponsor.
As the project transformed, so did my Research. My findings in the second phase include project developers (partners). Findings demonstrated how the Sponsor and partners conceptualized key system capabilities similarly and differently.
Impact
Direct product/service impact: Research led to prototype development in phase 1 and policy development in phase 2.
Strategic impact: Research advocacy led to inclusion of those closer to the problem (project developers) in phase 2. This inclusion was not temporary and also signaled a noticeable shift in language within this small group, that end users must be included from the start.
Discussion guide
Final report, developed in Figma + PPT
Policy guide low-fi prototype