Get Better at Estimating Your Project Timelines
TLDR: Here is a link to the table with the points to consider when planning a project timeline. NOTE: there are 2 extra points not discussed in this article in the table (Architecture Effort and Effort vs Calendar), I’m still learning more about those.
If you read the title, then maybe you’re like me and struggle with making half-decent time estimates for your project timelines. Or maybe you always make perfect predictions and are here to laugh at this article and problem I encounter quite often. Or maybe you make ok time estimates and wanna see how you can improve in making estimates. Regardless, you are reading this right now and you are about to gain a little insight in a few things I learned from my struggles and from my supervisor. But first, let’s talk about my greatest projection failure.
My failed timeline projection
Here’s a story of the worst timeline projection I’ve ever made. During my second coop, I made a personal website in HTML,CSS, and JS to compliment my resume (an interactive resume). I decided to revisit and redesign it from scratch during my third coop, where I made a User Interface to update the items on the site, created a contact system, and more. The idea appealed to me, as it would compliment my experience in web development, and I could explore new technologies to deepen my understanding along the way. I took about 5 min to plan out what I needed to do and figured it would take me about 3 weekends to make the front/back-end of this 8 page application. I didn’t create a mock-up/sketch of what I wanted it to look like, I just started hacking away at it, starting with the back-end. 3 months later, I finally had a finished product which was essentially taping parts together and which was also extremely buggy.
I later scrapped this site and created a plan to fix the front end and parts of the back end. With only 2 days of planning, I was able to recreate most of the website in 2 weeks (because the back-end was mostly functional which saved me 1 week).
This is when I realized how important it was to plan. Without a solid roadmap, the scope of the project is never set. Certain menial tasks will end up taking much longer to do, leaving the important tasks to be hastily done. And above all, you will never feel satisfied (at least in my case) with your work due to the lack of a vision of what your successful project is supposed to be.
For those interested, my current site can be found here.
What to also consider
External Dependencies
This is a factor that is often overlooked. Projects which involve multiple people can sometimes be delayed by reasons outside of our control; waiting for someone to get back to you, a task you were waiting to be completed had a late start, etc.
With this, plan according to the worst case time. For example, if a contractor says they can get the task done in 3 to 5 days, plan as if it would take 5 days. If they finish sooner than 5 days, then great! If not, you already accounted for it and the project can still move forward.
2. Known Unknowns
This includes all the tasks which you know has to be done, but don’t know how it’s going to be done. In other words, you know what you don’t know. This could be learning about the subject/technology or fixing a conflict between 2 modules.
Start your project with the known unknowns if possible, and if not then start them as soon as possible. The sooner you start them, then the sooner you can find where the roadblocks are, and if necessary the rest of the project tasks can be shuffled around to accommodate for the known unknowns which are behind schedule and something can still be delivered by the deadline.
3. Unknown Unknowns
These are the things that come up. Problems arise, simple solutions are just not possible, sometimes you even have to move backwards before the project can go forward.
When the project timeline has been decided, add some padding as a safety net to your project. According to industry standards, every project should have about 20–30% extra time allocated to it. Saying your project won’t need it is hyper-optimistic, because every projects has its bumps in the road. Regardless, you will be happy you did it!
4. Insufficient Level of Detail
This one is related to the unknowns. Insufficient level of detail provides more unknowns because the project hasn’t been looked into enough. It is also possible to have too much detail, in which every little thing has been laid out, which adds more complexity to scheduling and lengthens the scheduling period.
When planning out the project, it is important to provide enough detail to see all the tasks that need to be done. As you go along tasks will be added to the list; it is a given that things always come up. Maybe the project scope changes. Maybe a conflict between 2 processes occur. Plan out enough to uncover as many unknowns as you can, while not getting lost in looking for something that you can’t find.
5. Complexity
Some tasks are complex. The task could be clearly defined, but implementing it could be difficult. For example, programming linear algebra. Someone must, without using any external libraries, program a function to find the determinant of a matrix. This topic is written and explained in many textbooks. But actually implementing it in a program is a whole different story.
When considering the timeline for specific tasks, give each a complexity rating from 1 to 3. Depending on the score:
- Tasks with a score of 1 should have their time allocation stay the same
- Tasks with a score of 2 should have their time allocation multiplied by 1.5
- Tasks with a score of 3 should have their time allocation multiplied by 2
6. Dunning-Kruger-Effect
This point is for the overconfident, inexperienced ones. The Dunning-Kruger-Effect is used to describe the relationship between experience and confidence. I have to be wary of this especially. At 20 years old, I don’t have enough experience yet to accurately predict the amount of time it would take for me to complete a task. I often overlook complicated tasks and give a much shorter time than actually needed. The relationship can be seen in the figure below.
At the start of anyone’s career, we are filled with confidence after gaining a little bit of knowledge. We believe we know enough to do tasks with ease, and end up overestimating our abilities. As we gain more experience in a field, there will come a time where we are exposed to so much we didn’t know, leaving us feeling lost and confused. After that point once we know what we don’t know, we begin to catch on and learn until we can accurately gauge our ability and make proper estimates.
The way to combat this lack of knowledge and inexperience is by asking someone who is experienced to join the planning. They can make better guesses at how long it will take someone based on that person’s experience to perform a task. And having another set of eyes doesn’t hurt either.
7. Skillset of the Implementor
Depending on who performs the task, the time allocated to them will vary. Typically, you would ask people to perform tasks which suits them and their skillset. You wouldn’t ask a doctor to write a complex program, and if you did you would allocate more time to compensate for their inexperience and lack of knowledge.
When assigning tasks to people, consider their skill set. Try to match skill sets and accommodate for those who aren’t a good match by allocating more time to them.
8. Time-Off
This is one that passed right over my head until my supervisor pointed it out. People take vacations, holidays come up, people get sick and there is also Personal Time-Off (PTO). These will be inconveniences to the project and must be accounted for when creating the timeline.
To counter this, create a timeline with a calendar next to you. Let people add when they will be taking vacations and PTO, and add holidays to the calendar. If a project would take about 3 working days but there is a holiday in between, add an extra day to account for it. Your co-workers will also appreciate the extra time so they aren’t scrambling to get the job done.
9. Working Hours
This one is really important to consider. Your co-workers are at work for, say 8 hours a day, but aren’t actually working on the tasks given to them for all 8 hours. People take breaks, go to the washroom, have lunch, attend meetings, get called for advice… the list goes on and on. And once the workday is done, they are eager to go home and relax from the busyness of the work day. It isn’t fair to say they will work every minute they are at work.
When allocating time, it is safe to assume that a person will work for about 50–70% of their working hours, depending on the person. Architects, PM’s, and other people who are always in meetings will have even less time to focus on their work so be considerate when allocating time.
Conclusion
With this, I covered all of the points that I was told to be cautious of. Considering these points when planning and making time estimates has allowed me to plan better and has eased up the stress in my life and on others too. Of course, there are many more things to consider when planning; these are just a few.
Nevertheless, these points will help make your life and the others involved much better. And if you still tend to over/underestimate yourself and your team, don’t stress too much! Remember, at the end of the day, estimates are just estimates. There are times it will be wrong, we just have to learn from them and accommodate as best we can.
I would like to thank my supervisor Anatoly Volkhover for his advice and insight in mentoring me on this topic.
