>_~/projects/resource-allocation-tool
internal tooling / proposal / 2024
planning dashboard / internal tooling / resource allocation / role-based access

Resource Allocation Tool

A proposal to replace an Excel-based employee time-allocation tracker with a multi-user web application so managers could clearly see team capacity, allocation levels, and whether there was room to take on additional project work.

>> _

Why Replace Excel

The proposal focused on the limits of using Excel for employee time-allocation tracking once multiple stakeholders needed reliable visibility into team capacity and future project load.

Phased Delivery

The rollout was split into three implementation phases so the manager dashboard, operational features, and project-specific planning views could be introduced in a controlled way.

Governed Access

Role-based access control and user management were treated as first-class requirements so the tool could support both stakeholders and broader team usage safely.

Project Context

The original tool was an Excel-based tracker used to manage employee time allocation so managers could visually understand who had available capacity and whether the team could absorb more projects. As the workflow grew, the spreadsheet approach became harder to manage reliably.

The proposed solution was to turn that spreadsheet workflow into a web-based Resource Allocation Tool with management dashboards, upload workflows, employee and project planning views, and role-based access controls while leaving room for phased expansion.

The project was cancelled after phase one delivery when management changed and the organization no longer saw a need to continue tool development.

Metadata
Type:
Internal Web Application Proposal
Primary Goal:
Replace Excel-based planning workflow
Frontend:
Next.js
Backend:
Flask
Database:
PostgreSQL
Hosting:
Docker
Rollout Phases

Phase 1

Establish the initial system foundation: login, database design, dataset uploads, and a management dashboard for employee utilization, project planning, and hours allocation overview.

bootstrap auth + uploads + management dashboard

Phase 2

Expand the operational surface with employee pages, project and employee creation, user management, RBAC, and profile editing so the tool supports broader team usage.

add planning workflows + user management + RBAC

Phase 3

Introduce a project-specific planning dashboard so planning can be explored from the project perspective, not only through management or employee views.

add project-specific dashboard and planning views
Proposed Stack

Next.js Frontend

Selected for faster page loads and a cleaner dashboard experience through server-side rendering and modern app structure.

Flask Backend

Used as a lightweight Python backend to keep implementation fast while still supporting authentication, upload flows, and dashboard APIs.

PostgreSQL + Docker

PostgreSQL handled structured planning data, while Docker isolated each service for a cleaner deployment and operations story.

Conclusion

The proposal framed the migration as a usability, governance, and scalability improvement rather than just a technology refresh, with each rollout phase tied to a concrete planning workflow. In practice, the work stopped after phase one because a management change removed the business need to continue the tool.

Final Thoughts

Even though the project did not continue beyond phase one, it still reflects a solid internal-tooling approach: identify the workflow pain, scope the rollout in manageable phases, and align the stack and access model with how the team actually operates.