Note: this page is part of the “Essays on Software Engineering”

I used to run long distance trail races. My last race was in 2016, a 100 km race in Worlds End State Park, in the middle of Pennsylvania. That particular day, I did not plan to finish the race: my body was already exhausted from years of running without much rest, I only wanted to finish the first 50k. Surprisingly, that day, my body felt good and at the 40 km mark, a race volunteer convinced me to keep going as I was way ahead in terms of time. Hours later, I finished the race about 15 minutes before the cut-off, limping, around midnight, after running about several miles without a lamp.

Worlds Ends Race Picture The night before the race

What went wrong that day? I did not plan to run 100k but 50k and did not pack any battery or a lamp replacement. My mind was set on running 50k from the start and not ready to go any longer. I did not plan for the unexpected.

It wasn’t like this before. When a race was less than 26 miles, I took it as a training run. But when it was more than this, I meticulously planned it. I was researching the elevation profile, checking support stations and what food and liquids were provided. I prepare bags to drop at support stations located along the course and pack them with more than twice of what I need: dry socks, food or a new t-shirt. For each race, I clearly knew where and when I should be.

When you think about it, a race is very simple: run X miles under Y hours. There are constraints, such as the elevation profile, the weather or the type of terrain. All of this can be planned and managed to reach the goal. To succeed, all you need is to make sure you are trained, know what to expect at regular interval of the race and have whatever you need through the race.

Over the years, I realized this process is no different than project management. This is exactly the same.

When you start a project, you also have a goal (deliver X within Y months), some constraints and resources. As for a race, if the goal is not realistic, you do not sign up and come back if or when you evaluate this being feasible. Once you sign up, you establish a roadmap that tells you what and when things should be completed. You have milestones that show you the incremental progress you are going to do over time. It gives a clear overview of the project work plan, not only to you but to the team that can also discuss potential dependencies and organize for them to be delivered on time.

Does it sound like basic project management to you? Yet, I still see many important projects being started without even having milestones set. Engineers do not know what they should be doing when they come to work. Even worse: sometimes, engineers or managers do not even know what race they are running (if they are running any). They are sometimes just lost in the company wilderness.

When I start a project, I often try to plan it accordingly:

  1. Have a clear overview of the feasibility: if not feasible, either readjust the scope of do not take the project: better to deliver nothing than strong disappointment.
  2. Research and plan: like when preparing a race, look for the main obstacles in your project and make a plan to overcome them. Define objectives and milestones in a way they are measurable (e.g. I finished the code of module X by date Y). Write them down and communicate them to all internal stakeholders (your team, your sister teams). Communicate more pessimistic milestones for the customer so that you have some margin if things go wrong.
  3. Regularly check your progress to check you can finish the race before the cut-off. Look at your milestones every week and re-evaluate your work plan if needed. If you are ahead of time, you might help some other projects that need support or just finish your project earlier and polish it (better to under promise and over deliver).
  4. Take large margins: take at least 100% of margin, if you plan to complete a project in one month, ask for two months. You might face unexpected issues, either human (one team member is ill or has some family issues) or technical and this margin is here to take the unexpected into account.

These are simple rules. No matter how experienced you are, not following them can transform a nice race halfway into a long nightmare. And regardless of experience, many people do not apply them.

Following these rules and processes helped me to manage multiple projects simultaneously and deliver them before the estimated delivery time. I now schedule my life according to them. It helped me to track what I should be doing and ensure that I complete all the tasks I want to do within a day, a weekend or a month.

Managing projects is very simple: manage them as you run a race.