NECLA Externally Funded Project Tracking Platform

Current planning dashboard prototype used for stakeholder feedback.

Overview

This project focuses on centralizing the planning process for externally funded research projects at NEC Laboratories America. These projects involve proposal pricing, funding allocation, labor planning, incremental spend, invoicing, and reporting.

I worked with Rob from Operations to understand how project information currently moves across pricing files, bills of materials, project tracking spreadsheets, invoice reports, and proposal-related documents. From there, I designed and built a full-stack MVP that turns the existing spreadsheet-based workflow into a more structured planning system.

Problem

Externally funded project tracking was spread across multiple Excel workbooks and proposal folders. Rob had to manually pull information from different files to answer project-level and portfolio-level questions.

• Project summary, pricing, labor, invoice, and actual cost data lived in separate files.
• Reporting often required manually copying and reconciling values across spreadsheets.
• Labor planning depended on upstream calculations like total funding, incremental spend, and remaining net funding.
• Planned costs and actual costs were tracked separately, making it harder to compare them side by side.
• Ad hoc leadership questions required rebuilding custom views from manually maintained tracking sheets.

Understanding the Workflow

Before designing the application, I spent time mapping how Rob thinks through externally funded projects. The workflow begins before a project is awarded and continues through proposal development, contract negotiation, project deployment, invoicing, and reporting.

One important insight was that labor planning does not start with labor. It starts with total funding. Rob first estimates incremental spend, including equipment, travel, and shipping. The remaining funding determines how much is available for researcher labor.

Initial MVP and Rapid Iteration

I first built an initial MVP to validate the project structure, data model, and planning workflow. This made the operations problem more concrete and gave Rob something to react to during planning sessions.

As the requirements became clearer, I used Replit to accelerate prototyping and iterate more quickly on new workflows. This helped shorten the feedback loop while the project scope was still changing.

Building the Planning Platform

The project creation flow captures the fields Rob actually uses when tracking externally funded projects, including project status, contracted customer, end customer, total funding, cost share, department, lead researcher, duration, and notes.

This creates a structured starting point for each project instead of requiring project information to be maintained across separate tracking files.

Create project workflow for entering project details, funding, duration, department, lead researcher, and notes.

Labor Planning

Labor planning became the central workflow of the MVP. Rob needs to know how many researcher hours can be allocated without exceeding the available labor budget.

The platform uses total funding, project duration, researcher rates, and incremental spend to calculate remaining labor budget and monthly researcher-hour allocations.

• Calculate total incremental spend.
• Derive remaining funding available for labor.
• Convert labor budget into available researcher hours.
• Distribute planned hours across researchers and project months.
• Show whether the current plan is under or over the available labor budget.

Labor planning table with researchers as rows and project months as columns.

Incremental Spend Planning

Equipment, travel, and shipping are treated as incremental spend. These categories matter because they reduce the amount of funding available for labor.

The planning views make that relationship visible in one place, so Rob can see how non-labor costs affect the remaining labor budget without moving between separate worksheets.

Equipment planning view, representing one incremental spend category that feeds into labor budget calculations.

Portfolio-Level View

The portfolio view gives Rob a way to see externally funded projects together instead of opening individual proposal folders and tracking files.

The long-term goal is to use centralized project data to support cumulative reports across projects, including funding, incremental spend, cost share, invoice forecasts, and planned vs. actual project financials.

Portfolio overview for managing externally funded projects across the organization.

Initial MVP Data Model

One of the first design decisions was creating a data model that captured the core planning workflow without recreating every spreadsheet Rob used. The initial MVP focused on validating the planning process rather than modeling every aspect of the project lifecycle.

The schema separates planned and actual labor and incremental costs, providing a foundation for comparing forecasts against project execution while keeping the planning workflow simple enough to iterate on with stakeholders.

Initial PostgreSQL schema used to validate the planning workflow. As the platform evolved through stakeholder feedback, the data model expanded to support additional planning stages, reporting, and portfolio-level functionality.

Backend Implementation

The backend was built with FastAPI, SQLAlchemy, and PostgreSQL. One challenge was persisting editable planning tables while allowing users to revisit and continue planning over multiple sessions.

This required update logic that checks whether a row already exists for a given project, researcher, and month, updating existing records or inserting new ones as needed.

Current Progress

The current MVP focuses on project planning and funding allocation. Future work will extend the platform to support planned vs. actual tracking, invoice forecasting, and portfolio-level reporting using the same underlying project data model.

• Project creation and portfolio view.
• Project summary management.
• Researcher assignment to projects.
• Editable monthly labor planning tables.
• Persistent researcher-hour planning data.
• Funding-based labor budget calculations.
• Equipment, travel, and shipping planning sections.
• Foundation for planned vs. actual tracking.
• Foundation for invoice forecasting and project reporting.

What I Learned

This project helped me understand how much software design depends on understanding the underlying workflow. The hard part was not just building a form or table. It was figuring out what information Rob actually needed, how the calculations depended on each other, and which parts of the spreadsheet workflow were still useful.

I also learned how useful rapid prototyping can be when requirements are still changing. Early versions of the platform made it easier to discuss the workflow, identify missing fields, and decide which parts of the planning process should be modeled first.

The project gave me more experience translating an ambiguous operations process into a structured full-stack application with a real backend, persistent data, and stakeholder-driven design.