How to adapt your scoping process when today’s new project is due yesterday
It was our daily morning stand up meeting on Google meet.
Our (Project Manager) PM: “So we have an urgent project and we need to drop everything and start working on it.” He roughly explained the project.
The team: “When is the due date?”
The PM nervously: “… In one day”
Unison gasps by the team!
The scoping was done in less than 2 hours. I’m pretty sure it’s an all-time record at Doctolib. This was clearly an unusual scoping due to the fast changing national vaccination campaign that Doctolib was working on at the time. So naturally, it called for an unusual extreme approach. At Doctolib Tech, extreme is not the usual approach, but every scoping tends to be unusually special in its own way.
If this is the first time you hear about “scoping”, let me give you my brief definition:
Scoping is the art of understanding and documenting all of a project’s key elements: goals, deliverables, tasks, costs and deadlines. It is vital for successful project execution.
Make sure to check our post “The two kinds of tech scoping” written by Emmanuel Gautier on our Doctolib Blog to know what tech scoping is like at Doctolib.
The Tech Holder is the main person responsible for the tech scoping at Doctolib. You can also check our post “The Tech Holder: the key to empowering engineers… about the build!” written by Nicolas De Nayer.
I have done multiple scopings at Doctolib on different projects. Each time the scoping was different depending on multiple factors:
- Project size
- Due date
- Project sensitivity/complexity
There may be an infinity of ways to scope, but here are the 4 types I encountered:
- The standard scoping
- The small project scoping
- The multiple solution exploratory scoping
- And keep reading to know about the urgent project scoping that was perfectly done in a record of 2 hours.
The standard scoping:
- Time needed: 4 to 5 days
- Number of Tech Holders: 1
My first scoping was for a project that helps patients book the right appointment with the right Covid-19 vaccine for them by guiding them to the specific visit motives they are eligible to.
Tech scoping at Doctolib comes with a handy checklist template that holds different steps, each step assigned to a role.
Before I, the Tech Holder, started my holy mission of Tech scoping, the PM prepared Product specifications and kicked it off to the whole team. Product specifications are presented as a written specification documentation.
As this was my first scoping, I was greatly guided by my manager (EM) to investigate the project from a technical point of view, write a scoping document, and try to challenge the product, data, or design team when needed. In addition to planning how to implement the features, I needed to think about performance, security, and maintainability of the code we would be shipping.
Once I had broken down the project into tickets, the PM and I were able to co-write them.
With the biggest excitement of a first scoping, I shared my first draft with the whole Doctolib Tech team and asked for reviews. This of course led to multiple iterations on the scoping and very interesting discussions.
I finally kicked off the project with my team and created a roadmap.
My Tech Holder responsibilities don’t end when all tickets are done. I actually had to update the related documentation as the project progressed and to keep the scoping up to date every time any changes were made down the road.
The PM created a dashboard to be able to follow up on the KPI. On my end, I also created a dashboard to follow metrics and to make sure the rollout went smoothly.
What I really like about this scoping, is the clear and well-organized steps. The checklist really helps to define due dates for each step and therefore keeps me productive. One of the mistakes that can be made with this approach is to spend too much time investigating or writing the scoping document. You have to investigate just enough to have a rough idea about how to implement the solution from a technical point of view.
The small project scoping
- Time needed: 1 to 2 days
- Number of Tech Holders: 1
I have scoped a few small projects. The scoping was about 1 or 2 stories. For such scopings, we usually spare ourselves a checklist as it’s likely to add complexity to a project that doesn’t need it.
I can usually guess the project is super tiny when instead of a Product spec kick off, I get a small briefing about the context with the PM and EM with rough or no written specification (especially when it comes to tech-only projects).
I do my usual duties of investigation and documentation to finish up with creating 1 to 3 tickets mostly. As small as it may be, I still share it with the Doctolib Tech team and hold my kick off meeting.
The follow-up of these kinds of projects may not need a lot of monitoring or a dedicated dashboard.Clearly, the goal of this kind of scoping is to stick to the big principles of standard scoping without going through all the small unneeded details.
The multiple solution exploratory scoping
- Time needed: 2 to 3 weeks
- Number of Tech Holders: 1 +1 person helping full time
I have also scoped complex projects. One worth talking about is a proof of concept to improve SEO for the Doctolib patient website. The project came with one problem but multiple possible solutions: improve SEO with SSR, pre-rendering, or a few quick wins. Its main goal wasn’t to implement or ship any of these solutions, but to decide which solution is best for Doctolib.
Along with the previous steps that I listed in the standard scoping, came more work to take care of.
I had to investigate the feasibility of each solution, its pros and cons, its complexity, and its technical requirements. And of course, I had to explain why I finally chose a solution over the other ones.
The investigation of the solutions wasn’t only reading some code or asking around. I had to make a few PRs on the side or code locally to test some technologies or to get deeper into the future complexity that we may encounter, without developing the solution.
The project involved multiple teams and needed multiple workshops with Principal Engineers (PEs), EMs, and devs to iterate on my scoping.
The scoping took 2 to 3 weeks overall.
The complex project scoping is like a project in itself. I would recommend having 2 people work on it due to its complexity and need for constant feedback, review, and iteration.
The urgent project scoping
- Time needed: 2 to 3 hours
- Number of Tech Holders: 1 + the whole team helping
The national vaccination campaign had new changes and Doctolib had to adapt its product according to these changes without delay. The project had to be started on the same day it was announced. The scoping was a team effort. Our manager shared his whiteboard tab. One team member volunteered to take notes for the scoping document. We brainstormed on the solution, while everyone was investigating the codebase on the side for more information. Once each detail was drawn up on the whiteboard, we agreed on the different stories that the project would entail. Another member of the team volunteered to create the tickets and the timeline.
We made a quick presentation to the PM, and the first ticket was started as we were finishing writing the scoping.
Extreme situations call for extreme ways. Teamwork helps a lot to make it happen in such a short amount of time. But on day to day project scoping, this would clearly be the kind of scoping we don’t want to have, as there is not enough time for feedback or iteration to be given.
I believe that scoping should be flexible depending on the project in question. What I like about tech scoping at Doctolib, is that Doctolib made a scoping template to outline the main steps that need to be followed along with the people/teams involved. The template is a big helper but not words written in stone. Each Tech Holder has the entire flexibility to follow or draw around these lines as they see fit.
