At the end of every quarter, our leadership team reports that Rocks are ninety percent complete, yet very few are truly across the finish line. What specific definition of done must we institute to stop accepting partially finished Rocks?
In EOS, there is no such thing as an eighty percent or ninety percent complete Rock. A Rock is binary. It is either complete or incomplete. When a leadership team consistently finishes the quarter with mostly done Rocks, it means the Rocks were poorly scoped on day one, or the team is confusing activity with outcomes.
To fix this, establish a ruthless definition of done during your Quarterly Planning session before any Rock is approved. A completed Rock is never a vague effort like improve client onboarding or research ERP systems. It must be written with an objective, verifiable endpoint that any outside observer could confirm without asking questions.
Apply this three-step test to every proposed Rock:
- Define the physical deliverable: What tangible asset exists when this is done, such as a signed contract, a documented standard operating procedure, or an operational software rollout?
- Establish the validation metric: How do we know it works, such as three consecutive client cohorts onboarded with zero manual workarounds?
- Set the completion date: The Rock must be finished before the next quarterly session, not on the morning of the session.
If a Rock owner arrives at the end of the quarter with a draft sitting on their laptop that has not been deployed or tested, that Rock is incomplete. Do not celebrate effort. Mark it incomplete, enter it on the Issues List, and use IDS to identify whether the owner miscalculated capacity, failed to delegate, or lacked true accountability. When you stop giving partial credit, your team will learn how to scope accurately and finish what they start.
Category: EOS Implementation