Project
Management
A connected project lifecycle covering four stages — from capacity check before the proposal leaves, to change order billing after scope shifts — with no manual handoffs between them.
The Gap I Found
Four breakpoints.
None of them connected.
Projects were being created, committed to, staffed, and run without any system governing the full lifecycle. Proposals went out without capacity checks — which meant teams were being promised to clients before anyone verified there was room on the calendar. When a project was won, team assignment happened through Slack threads and informal conversations. Nobody was tracking whether the team being assembled was actually available.
Budget overruns appeared on invoices, not in real time. By the time the finance team noticed, the margin was already gone. And when scope changed — as it always does — the process for billing that change was slow enough that most of it got absorbed. Not because anyone decided to write it off. Because following the process felt harder than just doing the extra work.
Each of these gaps existed at a different stage of the lifecycle. None of them were individually catastrophic. Together, they were the reason the business was undercharging, over-committing, and perpetually catching up.
Why It Happens
Each stage was its own process.
Nothing triggered the next one.
Commitment, staffing, delivery, and scope change each existed as a separate manual process with no triggers linking them. The proposal stage had no connection to capacity data. The staffing stage had no connection to the project record. The delivery stage had no live view of budget consumption. The scope change stage had no automated path to billing.
The gaps weren't visible individually because each stage looked functional on its own. They only showed up as margin erosion and delivery strain over time — the kind of slow bleed that doesn't declare itself as a systems problem until someone finally maps the full lifecycle end to end.
What I Designed
A connected lifecycle.
Four stages. One system.
The design starts from a simple principle: every transition in the project lifecycle should trigger the next stage automatically. No proposal should leave without a capacity check. No contract should be signed without a team being assigned. No budget should be consumed without someone being alerted before it runs out. No scope change should be absorbed when there's a system that can bill it.
The four stages below cover the full lifecycle — from the moment an opportunity is being evaluated to the moment a change order updates the invoice schedule.
Systems Involved
What Changed
The lifecycle runs on triggers,
not memory.
Before, over-commitment was discovered at delivery. Teams were assembled through Slack threads. Budget overruns appeared on invoices. Scope changes were absorbed rather than billed — not as a policy, but because the process to bill them was slower than the work itself.
0
Proposals without a capacity check
Over-commitment used to be discovered at delivery. Now the gate runs before the promise is made. Leadership is only flagged when there's still time to decide differently.
→
Team assigned in minutes, not days
Before, teams were assembled through Slack threads. Now the right people are assigned at project creation and the Capacity View updates immediately.
90%
Budget alert threshold — not 100%
The alert fires when 90% of hours are consumed. Project managers have a window to act — a scope conversation, an early change order — before the budget runs out.
↑
Scope changes billed, not absorbed
Before, the process to bill out-of-scope work was slow enough that most of it was written off. Now the change order is routed, approved, and seeded into billing automatically.
Now each stage has a trigger. The project lifecycle runs as a system, not as four separate tasks that somebody has to remember to do in the right order.
How It Connects
Sits at the center
of the delivery system.
The capacity gate at Stage 1 only works if the Capacity View is kept current — which depends on Time Approval & Payroll writing locked hours back to it on every approval cycle. If time entries are delayed, the capacity check is running on stale data. The two workflows are designed to run together.
Project creation at Stage 2 depends on Customer Onboarding having already seeded the Project DB when the contract was signed. And the change order approval at Stage 4 writes directly to the Financial DB invoice schedule, which Invoice & Billing processes downstream. A signed change order becomes a billed line item without any additional steps.