What if I don't want to set the Project Timeline? What breaks?
So, my question is...
What breaks if I don't have a Project Timeline?
It is certainly not required to have one defined. But, I have run into some problems because I don't have one defined. And I have been told that I should set a Project Timeline, i.e. to avoid the problem.
Until someone can convince me that there is a true need for a Project Timeline, other than to avoid problems (what I believe are defects in the tool), I don't plan to do so.
One answer
Comments
Thanks for the quick response. When I look at it from that perspective, i.e. not requiring a team area, that makes perfect sense.
However, our setup requires team areas to be used. One reason is the different length iterations and the other is that we'll be using the Jazz SCM in the future and we need to control access to source code via the team area structure.
So, I'm still thinking that I don't need to have a Project Timeline defined, but I'm very concerned that I'm being told that I should have one in order to avoid problems that RTC has when there isn't one.
Further, if I do have a Project Timeline, then I don't believe I can define a plan that is owned by the project area unless I pick an iteration that is part of the Project Timeline. Currently, I use my project area as the owner of plans for timelines shared by multiple team areas. This gives me a full view of the information in the timeline, scoped across the team areas. I fear that this setup will break with a Project Timeline defined.
If you aren't using your project area as a team area, it should make no difference whether or not you have the Project Timeline set. In particular, I'm aware of no problems you will run into leaving that unset, but also, I'm aware of no constraints you will run into if you set it (for example, when the Project Timeline is set you can still create a plan for the project area and select any iteration from any timeline.
Note that you can control access to Jazz SCM source code even if you are using the project area as your team area (you can do anything in a project area that you can do in a team area). But if you have more than one team using a project area, you almost always want every team to have its own team area, and not use the project area as a team area. And even if you only have one team using a project area, it causes no harm to create a team area for that team.
+1 to Geoff's answer and comments.