DevEvents is an internal tool. Below  I've outlined my approach to this project and shared what details are externally approved.

Internal Event Management Tool

Vision
The vision of this project was to build a cross functional tool (UI) for all teams interfacing with external developers at 3rd party and Google hosted events to manage, track and analyze impact of these efforts.
Engineering headcount was secured and product adoption is at 100% of priority teams.

Results

Phase I: Data Consolidation

No engineering headcount had been allocated to the project as it was believed the project objectives could be achieved by consolidated existing trackers and spreadsheets into one master list. Simply consolidating into a master spreadsheet cause several issues. 
  1. The spreadsheet became slow and/or unresponsive due to heavy app scripts and higher data volumes.
  2. Data in the spreadsheet was at risk of being lost due to accidental content deletion and misuse of filters.
  3. Managing the data in a spreadsheet was a poor user experience especially as additional columns were added.

Challenges

Phase I Approach
  1. Secured buy-in to consolidate data tracking spreadsheets from 10 product teams by conducting user interviews and needs assessment surveys.
  2. Created a project brief outlining  the objective, teams involved, anticipated key results & metrics, approximate timeline & action items, as well as a brief list of FAQs.
  3. Phase I complete: Consolidated existing adhoc tracking sheets into one list.
  4. Data clean up entailed standardizing the data structure, removing duplicates, and filling in major gaps in data collection.

Phase II: Product Design & Development

  1. Met with an engineering lead from one of the primary stake holders and presented the above listed challenges.
  2. Met with a volunteer designer to work together to produce high fidelity mocks from initial sketches I created.
  3. Drafted a Product Requirement Doc including the following specifications:
    1. Vision & Goals (above)
    2. Background (Phase I)
    3. In scope & out of scope features
    4. Primary stakeholders
    5. System design,  data schema, & key features
    6. Sketches & high fidelity mocks
    7. Security & access
    8. Timelines & action items
    9. Maintenance
  4. Secured buy-in and headcount to build the tool with few modifications to the v1 feature requests.

Phase II
Approach