Internal project management tool

Context

When engagement tracking is spread across spreadsheets, messaging and the memory of a few people, management has no consolidated view, and every progress review means reconstructing the picture. The point of an internal tool is less to model everything than to become the place where information actually gets entered.

The problem

Internal tools nearly always fail for the same reason: they ask for more than they give back.

• Entry that is too heavy, and teams go back to the spreadsheet
• Two needs coexist: daily task tracking and a calendar view of deadlines
• Permissions have to isolate teams without blocking management's overview
• Existing history cannot be abandoned at launch

The solution

An application built around two complementary views of the same data, and entry reduced to the strict minimum.

• Kanban board for daily task tracking
• Timeline of milestones and deadlines, on the same data
• Quick time entry, designed to be filled in at the end of the day
• Per-team permissions, with a consolidated view for management
• Progress and workload dashboards

My role

Design of the data model, the API, the two views and the permission system, plus migration of the existing data and containerised deployment.

Constraints

• Adoption: every additional mandatory field lowers the completion rate
• Two representations of the same data, which have to stay consistent
• Per-team permissions without walling off management
• Migration of existing history at launch
• A growing volume of tasks, with views that have to stay fast

Outcome

A single source for engagement progress, readable as a Kanban board or a timeline depending on the need.

• Management has a consolidated view without manual reconstruction
• Teams work in whichever view suits them, on the same data
• Time entry is light enough to actually be done