Tim. I loved the look on your face when you said the "I think it will take 3 months... Why?, because???". That was awesome. I think that if most of us are honest we have been there at least once in our career.
Mr. Scott from Star Trek is my guiding light concerning time estimates - multiply your initial estimate by four and use that to negotiate with management. When you finish the project early, you get the reputation as a "miracle worker".
It is not so simple. If they suspect you are doing this - they simply force you to bring your estimate down. You need strong justification for your estimate.
It doesn't work for me. Boss: "How long it will take?" Me: "Three months minimum if everything goes well, infinity if I die today." Boss: "I need you to have it in two weeks, I promised it." Me: "Why are you always asking me then?"
This was very well articulated, thank you. I try to get my bosses to see this and you've given me some great new language and understanding to communicate with.
When working with morons: double your estimate. When working with customers who don't know what they want: triple your estimate When it was already sold before you are asked: RUN
Client: I'd like to have a thing with a plug! Sales: No problemo. Project Manager: Well, we need to build a thing with a plug. We don't have all the requirements, but I think we can improvise here and there... Team: *Builds a high-end fridge with 40" touchscreen, together with a shop interface and a social media service*...and a plug, of course. Customer: WTF? I WANTED A F**** TOASTER! MAKE IT A TOASTER IMMEDIATELY! FOR FREE! Sales: Calm down, that should be easy. It's probably just software...
I love to see when the community all comes together to work on a problem like this. Suggestion: fill the fridge with customer's favorite beverage and loop kitten videos on the 40". They will love it.
The challange is when you have a customer who have some basic knowledge about what they want, it's very difficult to estimate time, because they will try to cut time
Thank you so much! This information is applicable in every role, especially for eager young professionals like myself. I recently made mistakes overestimating what I could do, underestimating how much needed to be done, so this video is incredibly helpful - plan out every step in each component of the project - add 40% buffer time for the inevitable - "pay" for mid-project additions - communicate challenges/changes early - under-promise, over-deliver
Great topic thanks. It's very difficult to estimate especially when working alone as a freelancer, you might estimate certain features but when you get stuck to execute one thing and you are getting some errors you have never encountered before, you debug unsuccessfully, post your question on some online forums like stack overflow, takes days sometimes to get feedback and suddenly your time estimate falls in water, you lose 50% of your estimate. It's very tough to estimate when you are still a junior in a topic. And to explain that to clients it's a mission. Thanks alot for these topics, hope you will do more on time estimate, project scoping, project architecture, choosing right tools if using third-party paid libraries vs own to speed up project, etc.
Scope creep is dangerous for timelines. Your advice about adding a feature; by explaining that something else has to be removed if you want to stay with the timeline, is well thought off and priceless. I also believe in project notes that define the project, features and expectations as best as possible. Most often these notes helps to settle arguments, if two weeks/months later there is a difference of opinion between the developers and the project manager or owners about features and timelines. We are all just human and our memory isn't perfect!
3:07 Hi Tim, thank you so much for this video! I’m not a developer, although I have ambitions to create some apps. So I was very glad to come across your channel/podcast. I was trying to make sense of how to plan my own time/projects(not coding, but creative and business based), I have a tendency to massively underestimate how long things take me to complete. So I googled how do I estimate how long a project will take to complete? And your video came up. It helped so much. I’m going to be using your approach and suggestions to better plan for/estimate how long things would take me to complete. At this point in your video you talk about the WOULD break down, and then refer to quite a few different videos/series that discuss the WOULD model. For someone like me, who is not trying to learn how to code, but is keen to learn about your WOULD model, please could you tell me which video is the best to watch and possibly what the time tag is for the WOULD model discussion? Thank you so much for your time, Sarrie
Continuous project planning really helps when the timeline or deadlines are important. Use a tool that supports that, and estimate with uncertainty, rather than adding slack. Adding slack does not help clear communication, and makes estimation shaming an even bigger problem.
Thank you Tim! This is extremely useful and couldn't come at a better time. Although, as you say, it's not an exact science with a formula, you've described enough of a framework that should keep expectations in check, and customers happy. I'm sure all of your recommendations will help. I particularly like the idea of using time segment estimates to more effectively help customers choose between additional features vs. a later release. This of course means accurately tracking time. When done consistently, I've found time tracking in and of itself can improve productivity, as you become much more intentional about what you're working on right now. Great suggestions!
I have been working for 8 years as .net dev. From my experience, there are a couple of things that may ease an estimation process. 1. It's better to overestimate than underestimate. 2. Break into pieces as much as you can. More details - clearer picture. 3. Always include risks. It's usually 15-30% depending on a task. 4. Always take into account communication basing on your previous experience. Example: Desing functionality (review current implementation, investigate the impact of a change and potentially affected modules, prepare diagrams if needed) Implement A Implement B Implement C Test coverage (cover with tests if applicable) Communication (includes internal communications, requirements management) Stabilization (Usually around 30% from overall estimated development efforts but depends on circumstances. In the scope of this task we fix various defects found by the QA team. Not applicable for bug fixing.) Depending on a project some activities could be added or split into different tasks but the skeleton usually looks like the above example.
13:31 very important rule that I know very well, but couldn't obey since the beginning. example is I started a simple wpf application that works with database. few days later what I have is partly mvvm, partly asynchronous mess that I myself started to couldn't understand what's going on. reporting your progress, failures (communicating) to your boss on time (often) is very advantageous when you have an understanding boss. you don't even need to estimate a slack time, at least it works for me.
I usally estimate too less time for a project. Actually so much that I now have so many projects that my colleages have sad stop for me to get more work because I can't make it in time. I just realised it a couple of weeks ago when we got sat down and made a list of all the things we're doing right now. Both the overall list of projects and the small portions that made up those projects. So on the last business meeting I added 100% time on top of the normal which made it a more realistic timeframe.
I utilize it in a number of my projects but the clearest explanation is in the C# Application from Start to Finish project. Check out the first six videos in this playlist: ua-cam.com/play/PLLWMQd6PeGY3t63w-8MMIjIyYS7MsFcCi.html I also cover it in this course: www.iamtimcorey.com/p/foundation-in-c-battleship-project
Another great video 👍 Whenever there is anything we are unsure how to do after breaking it all down into tasks we add investigations with an allotted time. Hardest thing for me is that I've come back into development after a break of a few years so it's hard to catch up and what to catch up on, difficult to know where to concentrate my efforts!
Welcome back. I suggest making a list of learning topics based on the needs of your business and/or on your interests. Stay focused and train based on the list.
Tim, this is golden information which Unfortunately I had to learn with experience. Hopefully someone watches it and don't do those estimate mistakes :-D
For quick estimates, you can estimate 1 day per exposed property plus 20% of the original estimate. Then say that you need more info so that you can have a better one. Somehow, these has been close to real development time most of the time.
my timeline was established before i was given the scope by 2 non programming managers who literally guessed a time of 6 weeks to write a full on automation application to manage 12 products, each with 3 versions of product sizes. about 200 changes later and a ton of additional work required, im near completion in 18 months..
There is a lot of benefit you can get out of this process, though. Now you don't need to talk abstractly about timelines. You can point to this project. This should help you push for things like firm, realistic estimates, change management, etc. If they push back, say "It didn't work well last time. What is going to make it work better this time?"
my problem is estimating the total cost that's why i haven't accepted fixed cost contracts. i'm not sure how much to add for cost. and if that's ok.... by the way tim thanks a lot for your videos you are helping a lot of people, this is great service and i wish you more success
Hey Tim! I tried to enroll in a few courses on your site, but when I select Canada (where I'm from), the address info form vanishes except for postal code. Then when I hit the "buy now" button the form validation says "We could not establish a correct country for tax purposes. Please try again." I've tried on chrome, edge, and explorer. Is there a workaround? I want to give you my money!
Hey, sorry to hear that. Please send me an email at Help@IamTimCorey.com as soon as you can with any details, including the address you are trying to use, so we can get folks working on it. No CC info though
Hi Tim, great video and very interesting topic. Can you do another one similar but on how do you estimate a price of a net core MVC project, including hosting and databases hosting as well? Thanks for all your help teaching us C#
Can you please make a video or playlist which focuses on Azure as a whole for developers? Thanks a lot for sharing your knowledge. I have understood many aspects of software development in depth through your videos.
I've watched a lot of your videos, and I think your teaching technique is excellent, but when I went to your website to purchase some courses, I couldn't enter CC information due to bugs on the page. Need help with that but don't know how to get it.
Hey, sorry to hear that. Please send me an email at Help@IamTimCorey.com as soon as you can with any details, including the address you are trying to use, so we can get folks working on it. No CC info though
The 'C# Application from Start to Finish' course, both on UA-cam and paid, uses/demonstrates the WOULD framework in the first five Lessons. I created the WOULD acronym to help you remember the approach so there is no wiki out there on it. Lesson 02 in the UA-cam Path demonstrates the 'Walk thru the app" and Opens up the requirements, Lesson 04 addressed User interface, Lesson 05 is the Logic discussion, Lesson 03 is the Data design... ok, I got it bit out of order. The point is that I do all the planning BEFORE I start coding. Check it out!
It should be called "Guesstimation" Problems: Estimates becomes deadline. Bases on hours given, management arrives at completion date. After that hours doesn't matter. There is scope creep. Adhoc work. Higher priority defects. Team spirit- help others with no acknowledgement. Unsupportive management.
Think of a number that sounds about right, then quadruple it. I used to just double it, but that would occasionally come out too short compared to the reality. Never tell your boss a number that's too low. They get upset if you go over, but don't when you come under a much larger number.
I like to recommend the use of agile methods like Scrum to make it more manageable. Few people, even skilled can estimate a 3 months project, especially if there will be a lot of changes. It is better to make a sequence of very small projects, each one max 2 weeks. Then build the first project and get feedback. This works better because you keep focus on what you are doing and you can show results early to gain confidence. I know this still is a hard job. Planning is hard.
My usual phrase is: "I'm making it up, so why don't you make it up, you have a much better idea how much money we want. If we'll be below deadline... good, if we'll be above, we'll make some excuse."
Where time is paid for, either by external clients or by an internal budget, I am a big proponent that the price is fixed only within (say) a 15% or so range of the point estimate. Once it goes higher than that the pain must be shared 50-50 - or something like that. Otherwise it leads to zombie projects where developer is making a loss and client is just getting shtty software. Client lose- developer house lose - developer lose. This has to be contracted upfront, of course.
Yes! I suggest shared risk contracts. If the developer uses less time than the budget, the client is reimbursed half the unused hours. If more time is needed they pay half the extra hours.
Sign in mechanic's shop: $50ph. $75ph - if you want to watch. $100ph - if you want to help or offer advice. $250 - if you or your stupid buddies already had a go at fixing it.
I honestly believe this is a problem best solved by Neural Networks. Unlike the eternal human optimist they are pure realists. Complexity is no issue at all. They could even spit out a frequency distribution instead of a point estimate. All we need is some clean data. Even 100 completed projects would probably work. Anyone?
Developer: This will take 2 weeks Project Manager: Okay, you have 2 days Client: Can we have these 700 new features? Project Manager: Sure Developers: "You promised what now" Project Manager: Relax, we got you 1 extra day, called Sunday Developers: You'll be in on Sunday too right? Project Manager: I'm fishing but you can reach me on my iPhone, maybe Project Partially Delivered: 6 Months Later Project Manager: Disappeared under weird circumstances
Someof the worst project management advice I've ever hear. First of all there is a formula, it's called PERT and there's a reason the Navy has been using it for years. Also the idea of a swag is fine at a high level not at providing an estimate. Oh and also time estimation is a science that's why there's a career called project management. Wow
The vast majority of developers are still trying to master their coding skills, working on small projects and are not blessed enough to have the training you mention or to even have a project manager. They need a informal starting point, which this was intended to be.
Tim. I loved the look on your face when you said the "I think it will take 3 months... Why?, because???". That was awesome. I think that if most of us are honest we have been there at least once in our career.
Yup. Its a universal challenge everyone runs into.
Mr. Scott from Star Trek is my guiding light concerning time estimates - multiply your initial estimate by four and use that to negotiate with management. When you finish the project early, you get the reputation as a "miracle worker".
lol
It is not so simple. If they suspect you are doing this - they simply force you to bring your estimate down. You need strong justification for your estimate.
It doesn't work for me. Boss: "How long it will take?" Me: "Three months minimum if everything goes well, infinity if I die today." Boss: "I need you to have it in two weeks, I promised it." Me: "Why are you always asking me then?"
This was very well articulated, thank you. I try to get my bosses to see this and you've given me some great new language and understanding to communicate with.
Glad it was helpful!
Developer: This will take 2 weeks
Project Manager: Okay, you have 2 days
When working with morons: double your estimate.
When working with customers who don't know what they want: triple your estimate
When it was already sold before you are asked: RUN
Client: Can we have these 700 new features?
Project Manager: Sure
Developers: "You promised what now"
Project Manager: We got you 1 extra day
Client: I'd like to have a thing with a plug!
Sales: No problemo.
Project Manager: Well, we need to build a thing with a plug. We don't have all the requirements, but I think we can improvise here and there...
Team: *Builds a high-end fridge with 40" touchscreen, together with a shop interface and a social media service*...and a plug, of course.
Customer: WTF? I WANTED A F**** TOASTER! MAKE IT A TOASTER IMMEDIATELY! FOR FREE!
Sales: Calm down, that should be easy. It's probably just software...
I love to see when the community all comes together to work on a problem like this. Suggestion: fill the fridge with customer's favorite beverage and loop kitten videos on the 40". They will love it.
The challange is when you have a customer who have some basic knowledge about what they want, it's very difficult to estimate time, because they will try to cut time
Thank you so much! This information is applicable in every role, especially for eager young professionals like myself. I recently made mistakes overestimating what I could do, underestimating how much needed to be done, so this video is incredibly helpful
- plan out every step in each component of the project
- add 40% buffer time for the inevitable
- "pay" for mid-project additions
- communicate challenges/changes early
- under-promise, over-deliver
Thanks for watching. Good summary!
Great topic thanks. It's very difficult to estimate especially when working alone as a freelancer, you might estimate certain features but when you get stuck to execute one thing and you are getting some errors you have never encountered before, you debug unsuccessfully, post your question on some online forums like stack overflow, takes days sometimes to get feedback and suddenly your time estimate falls in water, you lose 50% of your estimate. It's very tough to estimate when you are still a junior in a topic. And to explain that to clients it's a mission.
Thanks alot for these topics, hope you will do more on time estimate, project scoping, project architecture, choosing right tools if using third-party paid libraries vs own to speed up project, etc.
Thank you. Added your topics to the list.
Thank you, I just made a huge mistake in estimating a project timeline... I need this info
Glad it was helpful!
I've watched 27 videos of yours in the last two days so far. Your materials are wonderful. Thanks for donating your experience! 💐
Glad you like them!
Exactly before I am going for client meeting regarding new project.
You are awesome Tim..
Fantastic!
Scope creep is dangerous for timelines. Your advice about adding a feature; by explaining that something else has to be removed if you want to stay with the timeline, is well thought off and priceless. I also believe in project notes that define the project, features and expectations as best as possible. Most often these notes helps to settle arguments, if two weeks/months later there is a difference of opinion between the developers and the project manager or owners about features and timelines. We are all just human and our memory isn't perfect!
Thanks for sharing.
3:07 Hi Tim, thank you so much for this video! I’m not a developer, although I have ambitions to create some apps. So I was very glad to come across your channel/podcast. I was trying to make sense of how to plan my own time/projects(not coding, but creative and business based), I have a tendency to massively underestimate how long things take me to complete. So I googled how do I estimate how long a project will take to complete? And your video came up. It helped so much. I’m going to be using your approach and suggestions to better plan for/estimate how long things would take me to complete.
At this point in your video you talk about the WOULD break down, and then refer to quite a few different videos/series that discuss the WOULD model. For someone like me, who is not trying to learn how to code, but is keen to learn about your WOULD model, please could you tell me which video is the best to watch and possibly what the time tag is for the WOULD model discussion?
Thank you so much for your time, Sarrie
Here you go: ua-cam.com/video/ybTPIhYLrBQ/v-deo.htmlsi=IxhS28xe3X7hjTk8&t=191
Thank you!! That’s awesome 🤩
Continuous project planning really helps when the timeline or deadlines are important. Use a tool that supports that, and estimate with uncertainty, rather than adding slack. Adding slack does not help clear communication, and makes estimation shaming an even bigger problem.
Thanks for the tip, what tools are you suggesting?
@@IAmTimCorey The PlanMinder (theplanminder.com). There is an article about continouos project planning on the site.
Thank you Tim! This is extremely useful and couldn't come at a better time. Although, as you say, it's not an exact science with a formula, you've described enough of a framework that should keep expectations in check, and customers happy. I'm sure all of your recommendations will help.
I particularly like the idea of using time segment estimates to more effectively help customers choose between additional features vs. a later release. This of course means accurately tracking time. When done consistently, I've found time tracking in and of itself can improve productivity, as you become much more intentional about what you're working on right now.
Great suggestions!
Thanks for sharing that! Good points
The unaccountable endless new features conversation that part is a good way to get bosses into reality. Great explanation.
Thanks!
I have been working for 8 years as .net dev. From my experience, there are a couple of things that may ease an estimation process.
1. It's better to overestimate than underestimate.
2. Break into pieces as much as you can. More details - clearer picture.
3. Always include risks. It's usually 15-30% depending on a task.
4. Always take into account communication basing on your previous experience.
Example:
Desing functionality (review current implementation, investigate the impact of a change and potentially affected modules, prepare diagrams if needed)
Implement A
Implement B
Implement C
Test coverage (cover with tests if applicable)
Communication (includes internal communications, requirements management)
Stabilization (Usually around 30% from overall estimated development efforts but depends on circumstances. In the scope of this task we fix various defects found by the QA team. Not applicable for bug fixing.)
Depending on a project some activities could be added or split into different tasks but the skeleton usually looks like the above example.
Thanks for sharing from your experience. Great insights
Very valuable discussion here, Tim. Thanks a bunch!
You are welcome.
Great subject!! Something that is hardly talked out but very important.
Thanks
13:31 very important rule that I know very well, but couldn't obey since the beginning. example is I started a simple wpf application that works with database. few days later what I have is partly mvvm, partly asynchronous mess that I myself started to couldn't understand what's going on.
reporting your progress, failures (communicating) to your boss on time (often) is very advantageous when you have an understanding boss. you don't even need to estimate a slack time, at least it works for me.
That sounds like a great boss!
Practice Agile Development. Deliver small and fast. Keep your customer actively engaged. Make your delivery dates a function of customer deliverables.
Well said!
I usally estimate too less time for a project. Actually so much that I now have so many projects that my colleages have sad stop for me to get more work because I can't make it in time. I just realised it a couple of weeks ago when we got sat down and made a list of all the things we're doing right now. Both the overall list of projects and the small portions that made up those projects. So on the last business meeting I added 100% time on top of the normal which made it a more realistic timeframe.
Painful lessons to learn
Thanks Tim! Where can I learn more about the WOULD framework?
I utilize it in a number of my projects but the clearest explanation is in the C# Application from Start to Finish project. Check out the first six videos in this playlist: ua-cam.com/play/PLLWMQd6PeGY3t63w-8MMIjIyYS7MsFcCi.html I also cover it in this course: www.iamtimcorey.com/p/foundation-in-c-battleship-project
I always overestimate a project. But its because i still dont believe how fast i can program. I would rather overestimate, though, than underestimate.
Wise.
Another great video 👍
Whenever there is anything we are unsure how to do after breaking it all down into tasks we add investigations with an allotted time.
Hardest thing for me is that I've come back into development after a break of a few years so it's hard to catch up and what to catch up on, difficult to know where to concentrate my efforts!
Welcome back. I suggest making a list of learning topics based on the needs of your business and/or on your interests. Stay focused and train based on the list.
You nailed it, Awesome! Thanks Tim.
My pleasure!
Tim, this is golden information which Unfortunately I had to learn with experience. Hopefully someone watches it and don't do those estimate mistakes :-D
Thanks for the encouragement
Great idea to create projects for features that you havent worked with yet! Good knowledge! Thank you!
My pleasure!
This is great. Thank you Time Corey!
You are welcome!
Great, this is what I was searching for.
Awesome!
Thank you , I needed this 👍
You’re welcome 😊
For quick estimates, you can estimate 1 day per exposed property plus 20% of the original estimate. Then say that you need more info so that you can have a better one. Somehow, these has been close to real development time most of the time.
Thanks for sharing!
my timeline was established before i was given the scope by 2 non programming managers who literally guessed a time of 6 weeks to write a full on automation application to manage 12 products, each with 3 versions of product sizes. about 200 changes later and a ton of additional work required, im near completion in 18 months..
There is a lot of benefit you can get out of this process, though. Now you don't need to talk abstractly about timelines. You can point to this project. This should help you push for things like firm, realistic estimates, change management, etc. If they push back, say "It didn't work well last time. What is going to make it work better this time?"
my problem is estimating the total cost that's why i haven't accepted fixed cost contracts. i'm not sure how much to add for cost. and if that's ok.... by the way tim thanks a lot for your videos you are helping a lot of people, this is great service and i wish you more success
Thank you
Hey Tim! I tried to enroll in a few courses on your site, but when I select Canada (where I'm from), the address info form vanishes except for postal code. Then when I hit the "buy now" button the form validation says "We could not establish a correct country for tax purposes. Please try again." I've tried on chrome, edge, and explorer. Is there a workaround? I want to give you my money!
Hey, sorry to hear that. Please send me an email at Help@IamTimCorey.com as soon as you can with any details, including the address you are trying to use, so we can get folks working on it. No CC info though
As usual I learn so much from you ו thank you for your smart information and generosity.
Your friend from Israel
You are welcome.
Wonderful explanation sir
Thanks!
Great Tips, Thanks a lot!
You are welcome.
Hi Tim, great video and very interesting topic. Can you do another one similar but on how do you estimate a price of a net core MVC project, including hosting and databases hosting as well? Thanks for all your help teaching us C#
Noted, added to the list.
Can you please make a video or playlist which focuses on Azure as a whole for developers?
Thanks a lot for sharing your knowledge. I have understood many aspects of software development in depth through your videos.
I will add it to the list. Thanks for the suggestion.
Noted
I've watched a lot of your videos, and I think your teaching technique is excellent, but when I went to your website to purchase some courses, I couldn't enter CC information due to bugs on the page. Need help with that but don't know how to get it.
Hey, sorry to hear that. Please send me an email at Help@IamTimCorey.com as soon as you can with any details, including the address you are trying to use, so we can get folks working on it. No CC info though
Couldn't find any "Wood Project" or even wood in the your/his videos, can someone send the link?
The 'C# Application from Start to Finish' course, both on UA-cam and paid, uses/demonstrates the WOULD framework in the first five Lessons. I created the WOULD acronym to help you remember the approach so there is no wiki out there on it. Lesson 02 in the UA-cam Path demonstrates the 'Walk thru the app" and Opens up the requirements, Lesson 04 addressed User interface, Lesson 05 is the Logic discussion, Lesson 03 is the Data design... ok, I got it bit out of order. The point is that I do all the planning BEFORE I start coding. Check it out!
@@IAmTimCorey Got it, thanks
Thank you, this is helpful
You are welcome.
It should be called "Guesstimation"
Problems:
Estimates becomes deadline.
Bases on hours given, management arrives at completion date. After that hours doesn't matter.
There is scope creep.
Adhoc work.
Higher priority defects.
Team spirit- help others with no acknowledgement.
Unsupportive management.
I have worked there too! Try to find one thing you can do to improve your work environment for yourself and your coworkers.
Thank you for this. I made a mistake when I told to a client that project will take 1month which is too much toll for me.
You're very welcome! Experience is the best teacher
@@IAmTimCorey indeed, now I'm working my ass to make this done early. Hahahaa
Whatever time and resources you think you need, multiply that by 3.14 (π)
I like that.
Think of a number that sounds about right, then quadruple it. I used to just double it, but that would occasionally come out too short compared to the reality. Never tell your boss a number that's too low. They get upset if you go over, but don't when you come under a much larger number.
Careful, you don't want a reputation for padding your schedule.
I like to recommend the use of agile methods like Scrum to make it more manageable. Few people, even skilled can estimate a 3 months project, especially if there will be a lot of changes. It is better to make a sequence of very small projects, each one max 2 weeks. Then build the first project and get feedback. This works better because you keep focus on what you are doing and you can show results early to gain confidence. I know this still is a hard job. Planning is hard.
If you management allows that, great!
My usual phrase is: "I'm making it up, so why don't you make it up, you have a much better idea how much money we want. If we'll be below deadline... good, if we'll be above, we'll make some excuse."
Sounds about right!
Its easy. Take the time you think it will take, double it and add 50% plus or minus a margin of error of up to 12 to 18 months.
The client just might start to get suspicious. LOL
So nice video thanks a lot
You are welcome.
Where time is paid for, either by external clients or by an internal budget, I am a big proponent that the price is fixed only within (say) a 15% or so range of the point estimate. Once it goes higher than that the pain must be shared 50-50 - or something like that. Otherwise it leads to zombie projects where developer is making a loss and client is just getting shtty software. Client lose- developer house lose - developer lose. This has to be contracted upfront, of course.
Interesting concept. Thanks for sharing.
Yes! I suggest shared risk contracts. If the developer uses less time than the budget, the client is reimbursed half the unused hours. If more time is needed they pay half the extra hours.
Sign in mechanic's shop:
$50ph.
$75ph - if you want to watch.
$100ph - if you want to help or offer advice.
$250 - if you or your stupid buddies already had a go at fixing it.
What about testing time?
It depends on how you do it. Creating tests should be a part of the process. Testing the application should best happen by someone else.
And don't forget the time to write unit test!!
That should be included as part of building the software.
Important point!
I honestly believe this is a problem best solved by Neural Networks. Unlike the eternal human optimist they are pure realists. Complexity is no issue at all. They could even spit out a frequency distribution instead of a point estimate. All we need is some clean data. Even 100 completed projects would probably work. Anyone?
Start an open source project! Seriously.
Slack is love, Slack is life.
I'm going to disagree with you there. Slack is fun, but it is also a big source of distractions, which reduce work efficiency.
someone disliked this video. can i know why?
Some folks with a lot of training and experience occasionally forget that others may not have access to that.
Developer: This will take 2 weeks
Project Manager: Okay, you have 2 days
Client: Can we have these 700 new features?
Project Manager: Sure
Developers: "You promised what now"
Project Manager: Relax, we got you 1 extra day, called Sunday
Developers: You'll be in on Sunday too right?
Project Manager: I'm fishing but you can reach me on my iPhone, maybe
Project Partially Delivered: 6 Months Later
Project Manager: Disappeared under weird circumstances
REAL Project Managers don't do that. Fake ones, as you point out, do not last long. ... you think he fell in while fishing? LOL
You can’t. Anyone who tells you you can is delusional.
Wow, I hope you don't work on the payroll system. I also hope you have a better day tomorrow.
Someof the worst project management advice I've ever hear. First of all there is a formula, it's called PERT and there's a reason the Navy has been using it for years. Also the idea of a swag is fine at a high level not at providing an estimate. Oh and also time estimation is a science that's why there's a career called project management. Wow
The vast majority of developers are still trying to master their coding skills, working on small projects and are not blessed enough to have the training you mention or to even have a project manager. They need a informal starting point, which this was intended to be.