How Drupal projects stall — and how to avoid it
A Drupal project is not just stalled when the code does not work. It is stalled when invoices keep growing, deadlines keep slipping, and nobody knows what happens next.
Reason 1: The brief is vague
"We want a modern Drupal site with everything we need" is not a brief. It is a wish.
The developer starts, does their best guess, the client sees the result and says "that's not what we had in mind." Both sides are frustrated and neither is strictly at fault.
Solution: A written functional brief before development begins. At minimum: which pages are needed, which features, who the users are, what integrations are required.
Reason 2: Decisions are delayed
The developer is waiting for the client: "should this button be red or blue, and should the form send email to HR or management?" The client is busy. A day passes, a week passes.
The developer moves on to something else. Later an answer arrives — but now something needs to be revisited that was already built on top of.
Solution: A clear decision-making process. One point of contact on the client side, a commitment to respond within 24 hours. The developer documents pending decisions.
Reason 3: Scope creep
The project starts: "a simple information site, five pages." Six weeks later the list includes: a calendar, user registration, PDF generation, three languages and a CRM integration.
Each addition feels "small" but together the project is twice its original size.
Solution: Every new requirement gets a time estimate before it is added. A change log. When the budget is exhausted, a decision is made about what gets cut — not just adding more.
Reason 4: Content does not arrive on time
Development is done but the site cannot launch because content is missing. "We'll send the copy next week" stretches to six weeks. Meanwhile maintenance costs accumulate, the client is frustrated, and the project is "done but not done."
Solution: Content is part of the project. Content collection starts on day one. Missing content is documented as a risk from the beginning.
Reason 5: Testing is left to the end
"Testing will take a few days" is rarely true. On more complex projects, testing uncovers problems that require development work. Then testing runs again. And again.
The project is "95% done" for weeks — a classic sign that testing was underestimated.
Solution: Testing is an integral part of the project, not an extra step at the end. The developer tests each feature before handing it over. The client tests iteratively, not everything at once at the end.
Reason 6: Too many external dependencies
"We have a CRM we need to integrate, but the CRM's API documentation is coming next month." The Drupal project stalls waiting for an external dependency that cannot be controlled.
Solution: Map all external dependencies at the start of the project. Add buffer time. Consider using a mock during development when the real API is not yet available.
When the project is already stalled
- Hold an honest retrospective — what went wrong, why, who is responsible for what
- Fix the scope — exactly what still needs to be done
- Update the schedule — realistic, not optimistic
- Create a communication structure — who talks to whom, how often, in what format
Sometimes the right decision is to stop the project and start fresh with a clearer brief. That is a hard call but sometimes cheaper than endlessly "finishing" a project that never ends.
If your project has stalled and needs a fresh perspective, contact us.
Kaido Toomingas
WebPro Company OÜ
Need Drupal help?
If the article describes your situation, you do not have to read everything first. A real person will help you choose the next step.