I highly recommend utilizing a Product Breakdown Structure which is part of a Prince2 methodology. It can be used to help organize any project work.
In a nut shell, identify the end product of the project. For example a car. then break that end product down to the next level products. For example, drive train, body, interior, etc. Then break those products down until you hit a level where the product can be estimated relatively easily/confidently. Make sure you define a scope for each product so that estimates for each product are based on a commonly understood and agreed upon scope. It doesn’t matter how the scope of each is defined, as long as the scope is clearly understood by all. For example, a car door contains a frame, window, lock mechanics, etc. Does it also include the interior panel with all the switches as well? Doesn’t really matter as long as those are included in the scope somewhere logical, like maybe the interior, as opposed to the door assembly.
Also look at the end product from both a business perspective and a technical perspective in this process. Business: What does the business want out of the project and Technical: What will it take for IT to both develop and support the resulting business end product. Meaning, do you have a development environment, test data, test tools, developed test cases, trained staff, capable staff, etc. and are there sufficient product environments to support the anticipated thru put levels or response times.
I’d strongly recommend looking at this specific step in Prince2. My last company adopted this as part of their standard Project Development Life Cycle and project estimate accuracy improved significantly.
I hope this helps