In order to get better at providing the list of tasks and the time they will take, you need to practice and record your results. So first make every estimate fairly detailed (don't forget to include communications and meetings, requirements development, designing, tests, qa, deployment, documentation (always needed in waterfall), research and other non-coding tasks. The first thing people do wrong is they estimate only for the actual coding time. You think, "Well that will take me about 2 days so that is the estimate" and 12 hours of meetings later, you haven't even started to develop.
When you give an estimate, store it and the time somewhere and when you do the project, mark down how long each task actually took. Soon you will see a pattern (most people consistently estimate too low). You also will now have the data to say what time things take. It becomes harder to argue with your estimates when they are based on hard numbers of what it took for similar tasks in the past.
In a waterfall project, you can assume there will be last minute changes, so estimate for a percentage of time spent on that too! If a task is new (you have no similar tasks in the history), remember to add a more research and design time because figuring out what to do will probably take the most time.
In a waterfall project, the best thing you can do for yourself and your team is to slip the deadline and increase the estimate every single time they change the requirement after the requirements definition phase. If they get new estmates from you consistently that tell them how much that little change will cost, you will reduce the number of "Oh by the way" changes you get drastically. You need to manage the customer in a large project.
And spend the time up front in requirement development and design. That is the purpose of a waterfall project since it is far cheaper to change things at that point than after you have done the development work. There are types of projects that are more suited to waterfall than agile. So don't automatically think it is bad that you use it. Instead learn to use it well to manage projects. If you learn to manage waterfall well, you are ahead of most devlopers in either waterfall or agile environaments because the truth is most developers are lousy at anything involving management of a project and getting projects ouit the door is the name of the game.