The myth of the well-scoped project
There's a widespread belief in the digital world: prepare a good enough brief, pick the right agency, define the scope precisely enough — and your project will run exactly as planned.
That belief is false. Not because agencies are incompetent or clients are difficult — but because complex digital projects contain, by nature, an unavoidable share of unknowns that only surface once work is under way. The real question isn't "how do we avoid the unexpected" but "how do we absorb it without blowing the budget".
"70% of digital transformation projects overrun their initial budget. 17% fail outright. The leading cause isn't technical — it's organisational."
— McKinsey Global Institute, report on digital transformation, 2025Reason #1 — The functional scope isn't locked down before kickoff
The leading cause of budget overrun isn't technical — it's a fuzzy definition of "what the site is supposed to do". Phrases like "something modern", "a smooth experience", "in the style of Apple" aren't specifications. They're intentions.
The problem: everyone agrees on the intentions. Disagreements surface on precise features, edge cases and exceptions — and those disagreements only appear once development is under way, when it's too late to renegotiate the budget without friction.
What we do differently: a mandatory functional scoping workshop before any quote is issued. This workshop produces an exhaustive specifications document, validated and signed by every party. Each feature is described with its standard case, its edge cases and its acceptance conditions. That document is the project's real contract — not the purchase order.
Reason #2 — Technical dependencies get underestimated
Your new site has to connect to your legacy CRM, your ERP, your payment system, your inventory management tool. Each of these integrations looks simple on paper. In practice, each one hides an unpleasant discovery: an undocumented API, an inconsistent data format, obsolete authentication, or a rate limit that forces a rework of the architecture.
These discoveries aren't professional failings — they're part of the reality of integration work. What turns them into a budget problem is their appearing unannounced inside a tight schedule.
— The integration rule
- Always multiply the estimated time for any integration with an existing system by 2.5
- Ask for the full API documentation before signing — not after
- Identify who, in your organisation, can unblock technical access if something goes wrong
- Build in a week's buffer per critical integration in the schedule
Reason #3 — Hidden design debt
Your brand has evolved over the years. Logos exist in 12 different formats, colours have shifted without the brand guidelines being updated, typefaces have changed. Come redesign time, everything needs harmonising. This work — often called "design debt" — is never included in the initial quote, because neither the agency nor the client can measure its scale before starting.
Of the last 50 redesigns we've delivered, 43 revealed significant design debt along the way. Average extra work: 3 to 5 studio days per project.
Reason #4 — Approval cycles are too long and poorly structured
The agency delivers a mock-up. It waits for approval. The first response arrives after 10 days, with contradictory feedback from several people on the client side. The agency reworks it. New delivery. New delay. The cycle repeats.
This scenario — which we see in most projects that reach us "as a rescue" after a first attempt has failed — generates an average overrun of 20 to 30% of the initial budget, purely in lost coordination time.
One point of contact has the final word on approvals. Not a committee. Not a director who signs off at the very end without having followed the project. One person, with real authority to decide.
3 to 5 working days maximum for any feedback on a delivery. Beyond that, the delivery is deemed approved. This clause, written into the contract from the start, prevents 80% of schedule slippage.
Feedback needs to arrive as one consolidated document, not as a stream of WhatsApp messages spread over four days. Consolidating it is the client-side decision-maker's responsibility, not the agency's.
Reason #5 — No shared definition of "done"
What does a finished project look like? The question seems obvious — and yet, in most overrunning projects, nobody agreed on the answer before starting.
Does "done" mean the site is live? That every department has signed off on it? That it has passed performance testing? That it works across every listed browser? That there's user documentation? That the CMS is configured for the marketing team? Every point that hasn't been defined upfront becomes a downstream negotiation — and downstream negotiations cost money.
A project with no Definition of Done is a project nobody knows is finished. And a project nobody knows is finished can't be invoiced — or delivered.
— A principle we've applied across every engagement since 2019How we deliver redesign projects on time and on budget
After 19 years and 820+ projects delivered, these are the practices that make the difference between a project that drifts and one that keeps its commitments. Discipline around scope and integrations is also core to how our web development agency in Marrakech runs every website and application build, redesign or not.
Two weeks minimum dedicated to understanding the business, the users, the existing systems and the constraints. This upfront investment consistently reduces surprises during development.
No big surprise launch after 6 months. Testable deliverables every two weeks. Problems get caught early, while they're still cheap to fix.
We systematically build a 15% provision into our quotes, clearly identified and explained. It covers reasonable surprises without requiring an amendment. If it isn't used, it's refunded or carried over to maintenance.
30 days after going live, we run a 2-hour session to analyse what happened, document the lessons learned, and adjust our methodology. Every project makes us better on the next one.
What you can do right now
If you're currently planning a redesign, here are three questions worth asking before you launch the first call for proposals:
— Pre-project checklist
- Who decides? — Name a single decision-maker now, not once things get stuck
- What does "done" mean? — Write your Definition of Done on one page, before any quote
- Which integrations? — List every existing system, request its API documentation
- What availability? — How many hours a week can your team dedicate to approvals?
- What's the real budget? — Add 20% to your target budget before issuing the call for proposals
These questions look simple. The hard part is answering them honestly, internally, before you end up in a tense meeting with your agency six months later.