Comments on: Here’s Why Every Project Takes Longer Than You Think It Will

By: Zuhair Sagga

Zuhair Sagga — Sun, 04 Feb 2018 16:49:55 +0000

I do agree with you. But I would like to introduce a way to do a better team estimation for the project which we took at CMU Software engineering master degree. it is something called TSP and PSP. I personally used it and it worked for myself and for my team. Of course not 100% from the start but after a while it do get me a good result. The idea is to test on-self time frame and then test on-self within a team with different team combination. and record everything so if a similar case does happen we can estimate as a team how long it can take for us to fix it. Again there will be always production bugs this is way it is better to have a half developer time 1 resource who handle operations.

By: Simon Dutton

Simon Dutton — Fri, 18 Dec 2015 14:42:49 +0000

Great article, Alex. We are actually wrestling with this subject at the moment too. We’ve had some internal debates and posted some thoughts on our own blog. Here if you want to read for yourself http://engineering.laterooms.com/looking-into-the-crystal-ball/ Look forward to your Kanban post.

By: Petr Pinkas

Petr Pinkas — Fri, 04 Dec 2015 13:46:28 +0000

Hey Alex, I love the Fantasy vs. Reality one! Would you be up to perfect it with couple meetings, going to bathroom, couple phone calls, reading some SMS or couple IM chats? 🙂

By: Grant Heinrich

Grant Heinrich — Fri, 04 Dec 2015 12:45:30 +0000

My very first boss, a very clever man, insisted we bill no more than 6.5 hours a day at his PR company, and questions were asked if you were in the office outside 9AM-6PM. 20 years later, I still think he had the right number.

By: Brandon Landis

Brandon Landis — Fri, 04 Dec 2015 10:14:57 +0000

He Alex, nice work once again. Extremely timely read for me as we’ve had a couple of instances in which our design/dev/marketer (that’s me!) team have had projects run over in recent months. Much needed perspective. Keep on rocking, will be sharing this around as per usual. – B

By: Anca Mosoiu

Anca Mosoiu — Thu, 03 Dec 2015 23:10:55 +0000

Great post! This subject is near and dear to my heart, so I’m un-lurking in order to comment.

I’ve been a consultant for 25 years, and, while I can give some estimates down to the hour, these are only possible on certain kinds of projects – those which I’ve done before and therefore have a known amount of technical and decision-making complexity. I up my estimates based on the number of people that have to weigh in on decisions about anything – requirements, features, technologies, hosting, etc.

Decision-making time is probably one of the biggest factors for slowing down a project of known technical complexity. When you can’t decide between Bootstrap and Foundation, or between charging dollars vs donuts, or you need more than 1-2 people to “sign off” on a direction — you’re in trouble.

How do you guys deal with that?

By: Shannon Lewis

Shannon Lewis — Thu, 03 Dec 2015 20:28:19 +0000

We figure a work week is 32 hours per week from a scheduling standpoint. This factors in the down time etc. I am starting to think 30 is probably better from a scheduling standpoint. We try to limit meetings etc but you are still pulled sideways many times a day. I recently heard about a productivity method where you work 50 minutes totally uninterrupted (turn off phone, close browsers etc) so there are no distractions. Then take a 20 minute break. Do another 50, take a 30 minute break etc. It seems crazy since you are taking so many breaks. But the theory behind it is you are way more productive since you are totally focusing on the task in hand with no interruptions at all. You can get into the flow of the task at hand. I am going to try this for a week and see. I have talked to a few folks who do this and they say they are really productive and get more work done in less amount of time. I’ll let you know after my trial week is up. Tried the pomodoro method and hated it. it didn’t work with my natural work cycle. The longer work time of the 50/20/50 might be better for me.

By: Keld Vraakjaer

Keld Vraakjaer — Thu, 03 Dec 2015 17:36:35 +0000

Our general rule is we calculate approximately the time needed for a project, and then multiply by Pi. So whenever a project deadline does not hold, perhaps you forgot to multiply with Pi?

By: Daniel Jones

Daniel Jones — Thu, 03 Dec 2015 16:56:44 +0000

Hi Alex, thanks for this post all very good information. I wanted to
write as I’ve been following the blog for a while now and when I noticed
you surf and ran your own SaaS business you received a new level of
respect in my mind! 😉 That said, I’ve got an idea for a SaaS business
in a different vertical and wondered if you had any advice for getting
that first iteration of the project off the ground. For example, is it
better to get it out the door and use a more affordable development team
abroad? Or pay more and use a local team in the States or UK (where I’m
based). Its not a complex SaaS product, but if it were to scaled, I
think we’d definately need a robust behind the scenes platform. Anyway,
let me know if you have any advice on that! Thanks and keep up the great
work!

By: Bijoy Thomas

Bijoy Thomas — Thu, 03 Dec 2015 16:39:51 +0000

Even if you plan for interruptions and add “buffers” to account for them, there is no way the project will be completed on the exact date as planned. You will get close and that’s valuable. I have seen a lot of managers (who claim to practice Agile) consider estimates ( in points or hours) as commitments. Estimates are estimates and nothing more. A team can continue to refine and get good at estimating but at the end of the day, estimates are estimates.

By: Josh

Josh — Thu, 03 Dec 2015 16:34:07 +0000

A good way to experience this for yourself is to install a time tracker like Rescuetime (free).

I have been using it since about a year ago, and it blew my mind to realize that even on my best days, I’m only productive about 80% of the time.

It helps me have realistic expectations of the people I manage, rather than expecting if they have 16x 30 minute tasks to do that they will get this done in a day.