Streamline
Architecting a Multi-Module Internal SaaS - HR, Client, Project & Resource Governance
Data everywhere, ownership nowhere
Projects, clients and people tracked in separate tools, reconciled by hand, with leadership seeing the organisation only after the fact.
The company ran on fragmented systems: one tool for project management, another for client tracking, spreadsheets for resource allocation, and manual reconciliation between all of them.
The result was not missing data. It was duplicated data, conflicting updates, and delayed decisions, with no single place that could be called correct.
Data existed everywhere. Ownership existed nowhere.
Three structural failures
Tool fragmentation
Multiple systems holding overlapping records meant every status question had at least two answers and no way to settle which was current.
Role ambiguity
Team Leads, Tech Leads and Project Managers had overlapping visibility but unclear accountability. Everyone could see a slipping project; nobody owned it.
Data without hierarchy
Senior stakeholders initially wanted all operational data on one screen. That buried the few signals that mattered under everything that did not.
The issue was not missing features. It was missing governance logic.
What I had to design around
An internal tool competing with real work, a leadership brief that asked for the wrong thing, and sixteen months of shifting ground.
Nobody has to use an internal tool
Adoption could not be mandated in practice. If the system was slower than the spreadsheet it replaced, people would quietly keep the spreadsheet.
The brief asked for overload
The explicit request was every metric on one screen. Delivering it literally would have satisfied the stakeholder and failed the organisation.
Sixteen months of moving targets
The company reorganised while the product was being built. Roles, reporting lines and project shapes all changed under the design.
Migration, not greenfield
Live projects, clients and history had to move across without a gap, so every model had to accommodate records that predated it.
Give the data a hierarchy
Consolidate the tools, then decide what belongs at which altitude, and let access define responsibility.
One system of record
I mapped what each existing tool actually held, where records overlapped, and which of them any decision genuinely depended on. Consolidation was a modelling exercise before it was a migration.
What I chose, and what it cost
Three calls that shaped the system, including one where I designed against what leadership asked for.
designing against the briefLayered hierarchy over the single screen that was requested
I split the requested all-in-one dashboard into an executive layer, role panels and drill-down detail.
I had to argue against an explicit stakeholder request and keep arguing while the first version looked emptier than what they imagined. Clarity at the top costs a click on the way down.
Access defines responsibility
Permission and accountability were modelled as one thing, so visibility always implies ownership.
It made permissions a political conversation rather than a configuration detail, because deciding who could see a risk decided who was answerable for it.
Feature discipline over feature requests
I held the roadmap to governance problems and refused additions that would have re-created the fragmentation the system existed to remove.
Some teams waited a long time for things they wanted, and a few kept side spreadsheets in the meantime.
What I'd fix
The outcomes below are qualitative. I did not instrument adoption or time-to-decision, so I can describe what changed but cannot size it, and I would wire that measurement first if I ran this again.
The executive layer earned its keep faster than the operator panels did. If I were sequencing it again I would ship one role's daily surface to completion before polishing the leadership view, because that is where adoption is actually won.
Where it stands
Live, after a sixteen-month evolution, carrying HR, client, project and resource governance in one system.
These are directional, reported by the teams using the system rather than measured by instrumentation. The one I would most want a number against is risk identification, because earlier detection is the whole argument for the layered hierarchy.