I was the founding strategic operations hire at Rayse, an early-stage proptech startup. No playbook, no predecessor, no template library. So I built one, and turned it into how the whole team worked. Every project, regardless of who owned it, moved through the same five PMI process groups: initiate, plan, execute, monitor and control, close. The page below is what each phase looked like in practice, with the real artifacts attached.
Whether the project was a partner launch, a masterclass, a product release, or a strategic initiative pulled from the company's priority list, every one moved through the same five PMI process groups. They don't run in a straight line. Tap any row below to jump to that phase.
Monitor and control runs parallel to execution, not after it.
Most projects fail in initiation, not execution. Skip this phase and you build a plan against a fuzzy outcome with no measure of success. So every project at Rayse opened the same way, regardless of whether it was a launch, a masterclass, or a strategic initiative pulled from the company's priority list.
What does done look like? Who's it for? What changes when this ships? Named on day one, not at the end.
The KPI got set at initiation, not retrofitted after launch. That meant the plan was built around the measure, not the other way around.
A launch is not a masterclass is not a product release. Classifying the archetype up front pulled the right template off the shelf and saved hours of generic planning.
Once the archetype was picked, the plan came together fast because the math drove it. Walk backwards from the ship date. Lay the archetype's task template down on the calendar. Bake in buffer where the vendor pattern said we'd need it. The plan revealed which dates were real and which were wishful before we committed them externally.
Backwards from the due date was the starting math. Then the plan had to puzzle-piece with team size and current workload, and since a lot of the work was marketing-led, with the marketing calendar too. Stacking initiatives in the same window pulled attention off each other, so we sequenced them so each one got its own shine. The plan that survived fit all three constraints.
Each archetype had its own task template and timeline shape, refined by every prior project of that type. Pulling the template meant we weren't planning from scratch.
If a vendor consistently ran late, the buffer was already in the plan. Pattern recognition from past projects, not optimism about this one.
Execution is where most ops chaos lives, because most teams don't have a steady rhythm. I ran a three-day cadence: Monday, Wednesday, Friday. Different purpose each day. Same shape every week. The work moved because the rhythm held. If you remember one thing from this page, remember this rhythm.
Open the calendar. Walk the due dates. Get explicit commitments from each person on what they'll close that week. The week starts with names attached to outcomes, not vibes.
Midweek check-in for help requests and red flags. If something's wobbling, this is when it gets named. Catching it Wednesday gives you 48 hours to unblock instead of finding out Friday.
Review what shipped. Name what slipped and why. Carry the residue into Monday with eyes open. No surprise rollovers, no quiet misses.
Monitoring runs in parallel with execution, not after it. The plan tells you what should be happening. Monitoring tells you what actually is. Two practices did the work: the KPIs set at initiation gave us the yardstick, and a tiered escalation pattern kicked in the moment a measurement drifted.
The KPI was named on day one for a reason. For a webinar that meant registrations, day-of attendance, and post-event engagement. For a masterclass, sign-ups and completion. For a partner launch, adoption signals on the partner side. Whatever the project, the measure was set up front and tracked throughout, so when something drifted we caught it as a number, not a feeling.
When something blocked, three levers in order. Direct vendor pressure first. If unresolved, name it in the weekly. If still stuck, executive escalation. Most blocks died in tier one.
When a date slipped or a vendor missed, the conversation was structured: what gives? Scope, time, or quality. The plan made the trade-off explicit so the call didn't get made by default.
Most teams skip this phase, and it's the one that compounds. Most retros produce a doc nobody reads. Mine produced template edits. After every project closed, what worked and what didn't fed back into the project plan templates for that archetype: timelines, deliverables, buffer assumptions. The loop closes here, and the next project of the same shape starts smarter than the last.
The retro is the artifact. The artifact is the template. The template is the next plan.
Two tools held the whole system. Notion was the execution layer. Claude was the design layer. The combination is what let one founding ops hire run all of this.
The day-to-day surface. A high-level project and initiative roadmap, a task board filterable by project and person, multiple views (Kanban, Gantt, Calendar), and weekly client-facing check-in docs that pulled double duty as internal recaps.
This is where the cadence lived. Monday opened a Notion view. Friday closed one.
The design surface. I used Claude to build the backwards-from-due-date planner, draft new project archetypes when something didn't fit the existing ones, analyze retros for patterns I'd missed, and iterate on the templates themselves.
Templates didn't only update at retro time. Every new project tweaked the template it ran on. Claude was where I tested the tweaks, drafted enhancements, and tightened the next version in conversation. The templates compounded with every project, not just every quarter.
Every startup is different. Some of this stays local to Rayse. The rest comes with me.