A digital project can have good code, good design and good content, and still go sideways. It happens when a decision isn’t written down, a task is left without an owner or a change of scope gets approved without being assessed. Preventing that is a job in itself, and it’s almost never seen.
On our team, project managers do it. Their name doesn’t appear in the code or in the screenshots of the finished project. They coordinate the team, handle the relationship with you and turn every request into a decision with a cost and a date. For you, that means something very concrete: knowing someone is at the helm.
This work is valuable on any project, whatever its size. On large, complex ones, it also lets everything else function. This article explains what it involves, and it’s also our way of acknowledging it.
Projects where the hard part is in the seams
We mostly work on custom platforms, integrated with each organization’s systems and with years of evolution after launch. They tend to be critical for whoever commissions them, and the level of demand matches what is invested in them. That translates into thousands of messages, hundreds of tasks and many people on both sides of the table.
At that scale, every specialty can do its part well and the project can still suffer. The risk concentrates in the seams: between specialties, between suppliers, between your team and ours. Our project managers work right there. There are several of them, they share a method and each project has one of them as its main contact.
One contact who knows the whole project
Your team needs one point of contact instead of seven. Someone who knows the status of every topic, knows who to ask inside the team and replies to you in your language and your tone. On our long projects, around 1 in 3 of the messages you get from the agency is written by her.
Over time, your team ends up calling her by name hundreds of times, and many of those conversations end with a “thank you”. In our case, those names are Ari and Nona.
That doesn’t put the technical team behind a counter. When it’s time to define requirements or specifications, whoever develops talks to you directly. The project manager calls the session, documents it and follows up on what was agreed.
On your side there are people too, with their day-to-day, their urgencies and their own managers. A good part of this work is making things easy for them. Explaining why something works the way it does, proposing the simplest route and helping decide what goes first. That’s how working relationships that last for years are built.
And then there’s the human side. The message before the holidays saying who covers what and until when. The “we’ve done a great job together”. The “rest up and recharge”. A relationship of years is sustained by deliveries, and also by this.
That there are several of them has a practical consequence for you. What the project manager knows about your project is written down in the project itself. Another can cover for her without you having to explain everything again.
Where what has no owner ends up
Our project managers are assigned almost twice as many tasks as they create. Access to environments, billing questions, analytics setups, hosting changes, the definition of a new feature. When something has no clear owner it ends up on their desk, and they make sure it gets one.
There’s another part that appears in no task. It’s the follow-up notebooks with each meeting’s open topics, the month’s priorities, the minutes, the proposals and the definition documents. They begin before the first line of code, when the project structure is opened: initial documentation, architecture, content plan, workshops, wireframes, analytics and access. Years later, that record makes it possible to reconstruct why each thing was decided.
From a request to a decision with a cost and a date
The gesture they repeat most is turning a request into something you can decide. The answer comes with three facts: what it involves, what it costs and when it can be ready. For example: “That’s 4 hours of Drupal Senior Developer. If you approve it today, you’ll have it tomorrow.”
When the project evolves, they follow the same path on a bigger scale. They gather the need, review it with the technical team and come back with the impact on development and on the schedule. That way you decide with the full picture and without surprises at the end of the month.
Four situations that keep recurring
In the day-to-day of a project, the same response patterns come up again and again.
They explain why and propose an alternative to achieve the same thing.
They open its own thread so it doesn't get lost and can be followed.
They help separate what is essential from what can wait, so that what matters arrives on time.
They suggest a 15-minute call and it's sorted.
The month of the launch
In the month before going live, coordination activity can multiply by 5 compared with a normal month. There’s coordinating with your hosting provider and closing domains, emails and service keys. Also separating what blocks the launch from what can wait.
On deployment day, your team gets a clear notice: while it lasts, better not to edit content, and as soon as it’s over we tell them. These are tasks without a line of code, and a calm launch depends on them. It’s the moment when it’s most noticeable that someone is at the helm.
The cost objection
The usual objection is that all this is a layer of management that makes the project more expensive. The coordination work exists whether or not anyone is assigned to it. If a specialist doesn’t do it, whoever should be programming does it, or you do. Either way, you pay for it, with hours no longer spent building or with decisions lost along the way.
It happens on a small project, a medium one and a large one. What changes with size is how much it weighs. On a small project it takes fewer hours and is still what keeps the relationship with you clear. On one lasting several years, with integrations and several suppliers, it holds everything else up.
That’s why we consider this role necessary on any project, and essential on large, complex ones.
What to ask before signing a multi-year project
If you’re going to commission a platform of this kind, from us or from another team, ask yourself these questions. They’ll tell you whether coordination is planned or will be improvised.
Six questions about coordination
They work for any supplier and any technology.
Who will be my main contact, and who covers when they're away?
Where is what we decide written down, and who keeps it up to date?
When I ask for something new, will I know what it involves, what it costs and when it can be ready before I approve it?
Who helps me sort out the requests when everything looks urgent?
Who coordinates my hosting, analytics and integration suppliers?
Who leads the go-live and how is my team told?
On our projects, the one who answers those six questions is a project manager. Their work is part of what you hire, just like development or design, even if it’s the one you see least. They’re worth a great deal, and we wanted to put it in writing.
For you, that means something very concrete: knowing someone is at the helm.