Enterprise CMS projects sometimes fail not because of bad technology, but because of bad assumptions. Here, by “failing” I don’t mean that you don’t have a working solution in the end of the day, but you have a project that went significantly overbudget and missed the original planned go-live date by a few months. As a consultant and now as a product delivery manager at Webiny, I’ve seen firsthand how crucial it is to align expectations, define scope early, and ensure every stakeholder knows their role before the first line of code is written.
Recently, we worked with a large enterprise client to implement a tailored version of one of Webiny’s applications. At first glance, it seemed straightforward: define the MVP scope, customize the existing application to meet their requirements, and hand it over to their delivery partner so that they can integrate it with their existing CRM and perform some polishing and further extensions where needed. We quickly realized that scope clarity would make or break this project.
🤝 Getting Aligned Early: Bridging Gaps Before They Become Problems
Before the project kicked off, we sat down with three key parties:
- The client stakeholders (technical and business)
- The delivery partner (tasked with integration and implementation)
- Our Webiny team (providing customization and guidance)
The Scope of Work was defined early to make sure the must-have requirements are agreed in the start. We mapped out a detailed scope of work. We didn't do anything fancy, but simply documented the requirements using something like our 📝 Requirements Template. Clarity and simplicity are key here, because it is incredibly important to agree and communicate these across the stakeholders to make sure all parties are aligned and clear on:
- What will be built, by whom, and by when
- What is not part of the MVP and will be delivered later
- What is completely out of scope
- Who owns each deliverable
- Where we have delivery dependencies or risks to be mitigated
It took a couple of iterations to ensure the right must-have items are on the radar and that key stakeholders had been properly engaged, but it was worth it. Documenting this in the start made it easy to push back on requests during the project development and implementation phase.
🧑🔬 The Real Test: Post-Playback Pressure
After the first playbacks, as anticipated, new requests began to roll in. Senior stakeholders, who hadn’t been close to the build, began suggesting features that were “crucial” or “quick wins” but weren’t part of the MVP. The ideas were great but the only way to get the solution in front of the real end users asap was to push back on them and put them in a backlog, prioritise them against the other existing and new ideas that didn’t make it in the MVP, and put them in scope for the next release. For example, getting an AI chatbot to help and guide the end user is an awesome idea, and relatively easy to implement, and it will give the new product a competitive edge, but it is completely useless if, technically, the end user is unable to complete a basic journey from start to submission.
Only because we had a clearly defined scope, we had leverage. We weren’t the team saying “no” arbitrarily. We were pointing back to documented agreements and timelines. It gave everyone a shared language to make trade-offs and kept us focused on what mattered: getting the MVP in front of real users and getting real feedback. In the end of the day, we all had the same goal - get a product that delivers value to the end user quickly and iterate, iterate, iterate with the user to deliver even more value.
This allowed the client to gather actual feedback from users instead of iterating endlessly in a vacuum. It broke us out of the “dark room” of development and into the light of user reality.
🧘♀️ What We Learned: Clarity Is More Agile Than Chaos
There’s a misconception that scope locks teams down. In truth, defining scope is what lets you be agile. When you have a baseline, you can adjust with intention. Without it, everything feels like a moving target that is being chased endlessly. This allows your engineering team to have a laser focus on what matters. We discovered that one of the biggest stifles of engineering productivity is context switching and lack of clear priorities, but about this we will talk another time. What’s important here is to shave off the low value, nice-to-haves, and keep your eyes on the prize.
Here’s what worked for us:
✅ Early Alignment Meetings with all key players
✅ A Written Scope Document that everyone is aware of and is officially signed off on
✅ Defined Responsibilities across Webiny, the client, and partners
✅ Communication and Engagement - clear, timely, and ongoing meetings and emails to manage scope creep and resolve real critical issues immediately.
✅ A Post-Go-Live Plan for Feedback - to assess new requirements post-launch and continue the development of the product accordingly.
🏛️ Well-defined Scope Isn’t Bureaucracy. It’s the Foundation for Agility.
This project reminded me that structure doesn’t stifle innovation—it enables it. Defining scope isn’t about saying “no,” it’s about knowing when to say “yes.” And in large enterprise CMS projects, it’s often the only thing standing between a successful rollout and a slow-motion failure.
If you’re about to start a CMS implementation—whether with Webiny or another platform—my advice is simple: take the time to define the scope together with all the teams involved. Yes, it may take you a couple of weeks, but the cost of skipping that step is far higher than you think. It doesn’t mean the scope and the plan will not change. They will, of course, but the delta will be manageable.
