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?"
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.
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.
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.
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
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
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!
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.
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
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.
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: th-cam.com/play/PLLWMQd6PeGY3t63w-8MMIjIyYS7MsFcCi.html I also cover it in this course: www.iamtimcorey.com/p/foundation-in-c-battleship-project
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?"
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#
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
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.
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.
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
The 'C# Application from Start to Finish' course, both on TH-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 TH-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.
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
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.
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.
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."
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.
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.
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.
![PASULOL รามเกียรติ์ ตอนที่ 4 นนทกพบรัก [Ramakien Ep.4: Nonthok in love]](http://i.ytimg.com/vi/tMUQgmZzf_A/mqdefault.jpg)
![เปิด อาณาจักร หมื่นล้าน "สาระตั้ม" l [Nickynachat]](http://i.ytimg.com/vi/3XE0nPF4YkQ/mqdefault.jpg)
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?"
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.
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!
Thank you, I just made a huge mistake in estimating a project timeline... I need this info
Glad it was helpful!
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!
Exactly before I am going for client meeting regarding new project.
You are awesome Tim..
Fantastic!
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!
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.
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: th-cam.com/video/ybTPIhYLrBQ/w-d-xo.htmlsi=IxhS28xe3X7hjTk8&t=191
Thank you!! That’s awesome 🤩
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
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.
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.
The unaccountable endless new features conversation that part is a good way to get bosses into reality. Great explanation.
Thanks!
Very valuable discussion here, Tim. Thanks a bunch!
You are welcome.
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
Great subject!! Something that is hardly talked out but very important.
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
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!
Great idea to create projects for features that you havent worked with yet! Good knowledge! Thank you!
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
Practice Agile Development. Deliver small and fast. Keep your customer actively engaged. Make your delivery dates a function of customer deliverables.
Well said!
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.
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
You nailed it, Awesome! Thanks Tim.
My pleasure!
Great, this is what I was searching for.
Awesome!
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.
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: th-cam.com/play/PLLWMQd6PeGY3t63w-8MMIjIyYS7MsFcCi.html I also cover it in this course: www.iamtimcorey.com/p/foundation-in-c-battleship-project
This is great. Thank you Time Corey!
You are welcome!
Great Tips, Thanks a lot!
You are welcome.
Wonderful explanation sir
Thanks!
Thank you , I needed this 👍
You’re welcome 😊
As usual I learn so much from you ו thank you for your smart information and generosity.
Your friend from Israel
You are welcome.
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?"
Thank you, this is helpful
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.
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
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!
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
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
Whatever time and resources you think you need, multiply that by 3.14 (π)
I like that.
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 TH-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 TH-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
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.
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
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!
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
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.
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!
So nice video thanks a lot
You are welcome.
And don't forget the time to write unit test!!
That should be included as part of building the software.
Important point!
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
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.
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.
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.
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.
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.
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
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.
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.
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.