Not sure if it should be in this category but still.
The question is simple How do you estimate the time a project would take from start to finish?
I’m sure everybody wonders about it when begins software development career and at some point figures it out for themselves(for example I have my own “sense” of what one or another feature might take to implement time vise, etc.). But I’d like to hear how thoughtbot does it. I know you guys don’t do “fixed-price” projects and prefer weekly/feature approach. But say for example you have an iOS(or Rails) project and the client is clear and positive on 4 features he/she wants to be implemented. At first you estimated a week of work per feature but later on while implementing the features and changing things according to client’s feedback a couple of them got so much away from what initially was expected that now it’s definitely going to take longer to implement them(say one feature became dependent on another or interconnected somehow or something of this sort).
How do you usually handle this situations? How do you communicate it to the client?
What I found the most difficult is just that - explaining the client that those “small tweaks” and changes that he wants to add with his weekly/daily feedback are going to move the deliverables deadline, sometimes unpredictably…
Hi Alex, the best way to deal with the impact that those small changes is having on the schedule is to not wait to explain until there is a problem, but instead build a flow and a structure to what is being done that continually reinforces the tradeoffs that are being made based on the changes.
We do this by breaking the work we are doing down into what is estimated to be done each week. When changes occur it will be immediately evident on a weekly basis that what was expected to be done is not done. At that point you have a conversation about why and what can be done for next week to bring the schedule back inline (or get approval for going over).
In this way, you’re having the conversation about impact and schedule change in week 1 as opposed to in week 4.
As to how we estimate, we do it based upon the above. We try to break the overall project down into estimated weeks and what would be done in each one. From there, we can come up with a ballpark number of weeks we think it will take.
I’d be happy to elaborate on this further if you have any other questions, thanks!
-Chad
Thanks @cpytel! This is already very helpful! Just to clarify, I have daily reports/discussions with the client on the progress that was done today, and during this call he usually brings up a thing or two he likes to change/tweak which are add up at the end of the day to some significant amount of work that needs to be done in addition to what we had planned before therefore delaying/stretching the schedule.
Correct me if I’m wrong but as far as I understand if I apply your approach I should tell the client(when he brings those things up) that these changes will delay deliverables and that I’ll elaborate on them and get back to him tomorrow with updated schedule, or something of this sort, right? Sorry for asking about small insignificant specifics of my own case, just trying to wrap my head around it and do the right thing this time or most definitely next time for sure.
Daily conversations are good. It sounds like there is an expectation that there are some changes that don’t affect schedule. I would recommend you lead with more education about how there are no changes that won’t affect schedule - all of them. It’s a matter of managing that change effectively.
My making this clear up front, it moves the conversation from being about any one desired change (which can be driven by emotion).
All that being said, I would be wary about having larger schedule conversations every day. That may be too fine grained. Instead, try to back up and really take a comprehensive look at the progress on a weekly basis.
The combination of these two things should work well combined with each other:
Up front education about how all changes, however minor, take time and affect the schedule. Changes are not bad, and the agile process embraces change, but it does not come without cost
Moving the schedule granularity of review up to a week, so that things can be looked at more comprehensively
thanks so much, feel free to keep asking related questions in this thread, I’m happy to help,
-Chad
How do you estimate the time a project would take from start to finish?