What We Heard
This was a domain mapping and discovery engagement, so we worked with internal stakeholders rather than end users.
Project leads knew assignment logic. Finance knew billing rules. Team members knew time tracking pain. But nobody had the complete picture.
Stakeholders could describe symptoms—"it's clunky," "it doesn't work right," "we waste hours reconciling"—but couldn't articulate the structural problems.
The fragmentation was accepted as normal. People built workarounds—personal spreadsheets, manual reconciliation processes—instead of questioning why the tools didn't agree.
The Problem
T-Bot worked—past tense feels premature since it still runs—but 'worked' captures something true.
Twisthink built it years ago for resource management. Track projects. Log time. Assign people. For a smaller team, sufficient.
Then they grew. And T-Bot's cracks widened into chasms.
Data lived in silos: TSheets for time tracking, QuickBooks for billing, Bamboo for HR, T-Bot for project management. None agreed. Finance spent hours weekly syncing manually. Ask three people about utilization, get three answers.
Fragmentation breeds distrust. When systems don't agree, people create shadow systems. Excel spreadsheets. Personal tracking methods. Each one a small rebellion against the official tools.
The commercial replacement cost $50K+ annually. So they asked: Rebuild, buy, or suffer?
The Solution
Documentation completed in 6 weeks mapping the complete domain across seven objects.
37 attributes on PROJECT alone revealed the complexity hiding in "simple" resource management.
Relationships documented showing how TIME SHEETS flow through PROJECTS to CLIENTS for billing, explaining why Finance was doing manual reconciliation.
System-of-record designations clarifying which platform (TSheets, QuickBooks, Bamboo, T-Bot) was authoritative for which attributes.
Business rules made explicit—deletion cascades, composition relationships, billing flows—turning tribal knowledge into shared understanding.
A practical blueprint the team could act on, regardless of whether they rebuilt, bought, or optimized existing tools.
The Method
We didn't design screens. We didn't even commit to rebuilding.
We mapped the domain.
This is the part that surprises people. Six weeks of work, zero wireframes. Just objects, attributes, and relationships. Because before you decide what to build, you need to understand what exists.
Seven objects emerged:
PROJECT had 37 attributes. Thirty-seven. Project number, phase name, forecasted vs. actual costs, hours variance, system IDs for TSheets and QuickBooks, additional margins for T&M vs. Fixed Price, client relationships, team assignments. When you see 37 attributes on one object, you're probably conflating concepts. Or the domain is genuinely that messy. Usually both.
TEAM MEMBER had 26. Market rate adjusting yearly. Resource type with different workflows. Billable percentage targets varying by role.
TIME SHEET → TEAM MEMBER is a composition relationship—time sheets can't exist without an owner. Deletion cascades matter. Delete the person, what happens to their time entries?
CLIENT → PROJECT → EXPENSE — everything flows up for billing. That relationship chain is why Finance was doing manual reconciliation.
What looked simple—track time, manage projects—revealed a web of business rules nobody fully understood.
OOUX forced us to make the implicit explicit.
What We Learned
The map itself can be the product. Sometimes understanding is the deliverable. When systems are fragmented, clarity about what exists and how things connect has value even if nothing else changes.