Scope Creep Case Study — LaMarie Bookly Project

Overview

The LaMarie Beauty Bookly integration project is a documented example of scope creep driven by hidden requirements and unclear upfront discovery. What began as a focused Bookly booking plugin implementation expanded to encompass product variants, WooCommerce subscriptions, a full service/product page refresh, and a credit card capture mechanism — none of which were explicitly defined in the original contract.

This article captures the pattern of expansion, the root causes identified, and the resolution path taken, as a reference for future project scoping at Asymmetric.

Client: ^[1]
Meeting source: WooCommerce Booking Flow Review, 2025-11-03
Stakeholders involved: Melissa Cusumano (Asymmetric), Kimberly Gehrmann (client-side PM), Roxana Lopez Tinajero (La Marie Beauty)

Original Scope

The initial Bookly contract covered:

• Installation and configuration of the Bookly plugin for appointment booking
• Staff configuration and service setup
• Basic WooCommerce checkout integration (products only)
• Square inventory sync (already partially in place)

A separate, already-paid filter project had been deferred pending completion of the Bookly work.

How Scope Expanded

The following items emerged during implementation but were not part of the original contract:

As Kimberly noted in the meeting:

"This project seems to have suffered from a lack of requirement definition in the beginning… these variants, and the credit card being required to hold an appointment but not charged in full — as a result of some of these hidden requirements, we've started to balloon the size of the scope."

Root Causes

1. Discovery Handled by a Third Party

Requirements gathering was largely conducted by Lisa Evans (a prior project contact), whose findings were not fully documented or shared with the Asymmetric development team. Key operational details — like the no-show fee credit card requirement — were never formally captured.

2. Design Shown Before Engineering Feasibility Was Confirmed

Miro board mockups were presented to and approved by Lisa before a developer confirmed what was technically achievable. This locked in client expectations against designs that may not have been fully buildable as shown.

3. Chicken-and-Egg Technical Dependencies

Some requirements (e.g., how variants would work in Bookly vs. WooCommerce) genuinely could not be answered until implementation began. However, this ambiguity was not flagged as a risk or documented as a pending decision.

4. Scope Absorbed Informally

Rather than raising a formal change order, some expanded work was absorbed by the Asymmetric team ("we're gonna eat it") without client acknowledgment. This created budget pressure without creating a paper trail or client awareness.

Budget & Billing Impact

Melissa confirmed in the meeting that the original $5,000 website build had already exceeded budget before the Bookly work began. The Bookly project then accumulated additional unbilled complexity. At the time of this meeting, no formal change order or scope amendment had been issued for the expanded work.

Kimberly flagged the risk explicitly:

"I want to make sure there are no surprise bills… miscommunication and expectations and assumptions is where people start to get frustrated."

Resolution Path

Immediate action: Kimberly scheduled a meeting with Lisa to:
1. Clarify what Lisa believes is covered under the existing contract
2. Align on the final defined scope of the Bookly project
3. Surface any budget adjustment needed for out-of-scope work

Melissa's role: Provide Kimberly with relevant contract correspondence and prior email approvals to support the conversation.

The goal was to reach a shared definition of "done" before further development continued, and to avoid delivering a completed project alongside a surprise invoice.

Key Decisions Made at the 2025-11-03 Meeting

• $0 service pricing in WooCommerce adopted as the solution for credit card capture without upfront service charges — mirrors existing Square practice for variable-cost services like Botox. Coupon-based workarounds were explicitly rejected as fragile.
• Roxana to receive direct WordPress access for image uploads, eliminating the Google Drive → Melissa → WordPress handoff bottleneck.
• Fathom recording to be shared with dev team (Eshock, Chris) so they can address booking flow issues (cart display, UI polish, staff filter) without a separate briefing meeting.
• Google Calendar integration to be confirmed with Chris as still needed or deprecated.

Lessons for Future Projects

1. Require a signed requirements document before any design work begins. Designs shown to clients become commitments, regardless of engineering feasibility.

2. Identify payment and billing edge cases in discovery. Questions like "how do you handle no-shows?" and "do you need to store payment methods?" should be standard discovery checklist items for any booking or e-commerce project.

3. Flag scope additions in writing at the moment they are identified, even informally. A Slack message or email saying "this appears to be out of scope — confirming before we proceed" creates a paper trail and prompts a budget conversation before work is done.

4. Do not absorb out-of-scope work silently. It erodes margin, sets a precedent, and deprives the client of the opportunity to make an informed prioritization decision.

5. When a third party handles discovery, require a formal handoff document before development begins. Do not assume verbal summaries are complete.

Related

• ^[2]
• ^[3]
• ^[4]
• ^[5]