Setting realistic goals for your project

When kicking off a new project, whether internal or open-source, library or a fully-fledged software, how do you set realistic goals in terms of achievement and timeframe, especially when you have to factor in learning of a new technology that has to be used?

1 Like

I really hope to hear from more experienced people on this one.

I constantly underestimate the effort I need to put to write code. Constantly. A “one-day thing” became “at least a week” more often than I can count :sweat_smile:

I don’t think I have ever said “this will take a day” and been right. :joy:

If the project is exploratory, I tend to wait until I understand what the solution is going to look like before offering any thoughts on potential timeline. Sometimes this manifests as “I can’t tell you today, but if you give me a week I will have a better idea.”

1 Like

But you are providing a timeline, at least one to better understand the problem and the scope of a possible solution. Even that can be hard, sometimes. How do you manage the expectations?

Managing expectations is tough. If I’m lucky, life is like this:

I have been extremely fortunate over the past several years and have had the opportunity to work this way.

For me it keeps coming back to “is this exploratory work or is this applying a known solution?” Exploratory work has huge error bars and people have to be ready for that. Applying a known solution should be much more predictable.

The entire pipeline contributes to this. If you can only run one experiment a day, it is going to take a long time to move forwards. If you can run an experiment in seconds or minutes, you can make a lot more mistakes without burning up time the same way.

This feels like it has been a bit disjointed but hope it helps a bit.


Good points @glb and @raphabot,

In the past, I have extensively used the Spikes a term in Agile Methodology to solve that problem.
The idea is to allocate some time, usually between a day and a week, to explore the problem, try a few things (and hopefully break a few things along the way), to finally come up with a practical solution to implement with all the knowledge needed to estimate the work to be done in a more precise way.

For instance, the solution can take half a day to implement because during the Spike we’ve discovered that a library can do it, or it can take a week because there is something a bit more significant to build; the point is, we now know how long it will take.

Long story short, invest in exploratory time, reap the benefits by knowing the effort required to build it, and learn along the way.


For me, I can speak on the process of me getting my AWS Cloud Practitioner certification. I like to set deadlines for myself that help keep me on track. When it’s something new, I definitely allow myself the time needed to learn (measure twice and cut once).