We struggle with Rock execution because leadership team members write multi-step projects as Rocks without intermediate milestones, leading to last-minute failure. How do we structure Rock milestones so they reliably finish on time?

Question

Tyler Smith · Accepted Answer

A Rock fails when an owner treats it like a single giant task instead of a ninety-day operational sprint with distinct hurdles. When someone takes ownership of a Rock, they often spend the first thirty days researching, the next thirty days debating, and the final thirty days scrambling to build the deliverable. That approach guarantees an incomplete Rock or a shoddy outcome.

To ensure quarterly Rocks finish reliably, force every Rock owner to present three intermediate milestones within seven days of setting the Rock:

- Day 30 Milestone: Research, vendor selection, or system architecture complete.
- Day 60 Milestone: Testing, initial build, or pilot phase deployed.
- Day 90 Milestone: The project is operational, documented, and fully integrated into weekly operations.

During the weekly Level 10 Meeting, when the Integrator reads off the Rock, the owner reports on or off track based on those specific milestones. If a Day 30 milestone is missed, the Rock is immediately called off track and moved to the Issues List for IDS. You do not wait until week nine to realize that the person has not started.

Furthermore, every Rock must have a clear, measurable definition of done established on day one. A vague goal like improve client onboarding will fail. A clear Rock like new client onboarding SOP written, approved, and tested on three new accounts has a definitive finish line. Milestone architecture turns ninety days of vague intentions into three thirty-day execution sprints.