If you work on big projects that have gone through several releases, at some point you are going to encounter a project that won't fit into a single release. This can arise for a variety of reasons. Maybe your company decided to change its release schedule. Maybe customers are only requesting the most basic parts of the project but you see an avenue for adding great functionality. Maybe some of the developers responsible for certain components won't be available until a later date. Whatever the reason, it has been deemed necessary that all of the features you would like to do cannot possibly be done by the time the next release is supposed to ship.
This can become a particularly interesting exercise if estimates have already been done and if, for once, management has put some faith in your estimates. They see several small projects which can easily fit but one big project that has a variety of features that can be packaged, shipped and sold as separate features. Looking at this feature list for the project, items 1, 3 and 4 are deemed necessary to get the basic functionality into the product and will be ready by release date. Features 2, 5 and 6 will not, but hey, estimates are already done. We'll just put the projects into the following release and we already know how long they will take! Planning ahead really worked out this time!
The gut reaction of every project manager I have ever met in the above case is to break the projects out and simply divide the projects up, take the assigned times and then figure this will be how long it will take to do features 1, 3 and 4 in the current release and features 2, 5 and 6 in the following release. Let's say it is broken down as such:
The natural reaction to the above is "Ok, the work in this release will take 170 hours and the work in the next release will take 195 hours. Great!" Unfortunately, I have never worked on a project that has spanned multiple releases that has worked out so cleanly. Dependencies change, you need to go back and retool something in Feature 1 because Feature 6 needs it that way but since it was not part of the original project, it wasn't put in initially. The database schema has changed. You need to rewrite some tests. You are using a new version of your favorite compiler and you need retool some of your old code to take advantage of new features. Any of a multitude of reasons can cause your estimates for the second set of deliverables to change greatly.
From what I have seen this experience most closely resembles painting a room in a house. If you do the whole room in one shot, you can give a pretty good estimate of how long it will take, especially if you have painted that room before. What is much harder to estimate is the total time it will take if you can only get 2 walls done one weekend and then two walls done the next. Assuming you want the room to be useable and somewhat presentable, you will need to take down your trim tape. You have to clean your brushes and put the lids back on your paint. Drop cloths have to get folded up and put away. You likely need to wash yourself. All this needs to be done after finishing the first two walls. Then the next weekend you have to take all your paints out. You need to retape trim. Put the drop cloths down. Do whatever else you need to do to get set up. Then paint the walls. Then take down the trim tape, clean your brushes, put drop cloths away, etc.
Whereas if you could have done the other two walls in the original weekend it would have taken you maybe another hour, if that, by having to put off those two walls until the following weekend, you probably wasted the entire day. So it goes with developing software. There is a lot of stuff that goes on around the different pieces of a project that take time and effort. In estimating an entire project these things are usually accounted for. As they are likely one time costs if the whole project is done in one shot, they are estimated as such. Because of this, you cannot simply divide up a big project by its estimates per feature, then declare it will take phase 1 X hours to do and phase 2 Y hours where X + Y is equal to all parts of the original estimate.
If you do get into a project such as this, your best option is to do your estimates for the first set of features to be released and then re-estimate what will be done for the second set of features after the first set is released. Throw away the original set of estimates and specs and start completely over. This is the only way that you will be able to get a reasonably good estimate of how long those features in the second part of the project will really take.
If you do this and you have kept your original plan in a drawer somewhere, you will most likely see that the new estimates plus the old estimates are at least 25% greater than the total estimates of the first project. Management will almost invariably have kept a copy of the old estimates and will question you as to why, if these features only took 195 hours initially, why are they going to take almost 250 hours now?
My suggestion is, for any estimates you do, be as detailed as possible, especially in the areas that have to do with the scaffolding necessary to get the project done. By doing this you will have a detailed record of the real cost of the project and you can see where the cost for certain items is going to have to be paid on multiple projects. By doing this you will also likely come across common threads in projects that will allow you to find ways to reduce or, if you are really lucky, eliminate the cost of certain tasks. After all, it is hard to address an issue if you don't even know it exists. By keeping a detailed list of the cost of items and reviewing it you should, in the long run, be able to reduce the overall time of future projects.