Setting up for the Planning Engine
Setting things up so the Live Plan engine can render your project plan actually starts when you create a Project in the Administration interface. At that time you specify the outer parameters of the project: the starting and ending dates. The start and end dates are the foundation on which the Live Plan engine builds the project plan. The project ending date is not a fixed, permanent date. You can change it any time as the project progresses, extending the project or moving the end date up.
Another important system configuration that affects project planning is the Working Calendar. It tracks how much overall working time is available. The Working Calendar defines both working and nonworking time such as weekends and holidays. A Polarion administrator should configure the global calendar. The global calendar generally specifies the organization's normal work policy such as the days and hours when people work, as well as days off for weekends and holidays. The global calendar becomes the default for all new projects. Users can configure a personal Working Calendar that defines an individual's work schedule. For example, some people may work only part time. At times, people may work overtime, take vacation time, or take other time off. Between the global calendar and the aggregate of all individual calendars, the Live Plan knows how much total working time is available, and it takes this into consideration when planning Work Items in a given time frame. For information on configuring the global calendar, see Configure the Working Calendar. For information on configuring users' individual calendars, see Configure Your Working Calendar.
If you have team members who regularly split their working time between two or more projects, an administrator can configure time splitting in their user accounts. This causes the Live Plan engine to account for the available time in the relevant projects. For more information, see Configuring User Time-splitting.
Time Points are a key feature for project planning and release management. These are essentially named milestones associated with a date. For example, you might have a Time Point named "Beta 1" that falls on some date prior to the actual end date of the project. If you practice iterative development, you can set up a Time Points for each one of your iterations. Once Time Points are configured for the project, Work Items can be assigned a Time Point. It is then easy to query and view items that are unresolved for any Time Point. The Live Plan engine can plan items according to these milestones, and you can review them in the GANTT chart for any Time Point. For more information on working with Time Points, see the Time Point field. To learn how to configure Time Points, see Configure Time Points.
With the foregoing configurations in place, you can begin creating Work Items in the project and providing values in the Work Item fields related to planning. These include Priority, Severity, Initial Estimate, Remaining Estimate (estimate of time remaining to complete the item), Due Date, Time Point, Due Date, and Planning Constraint. For more information on these fields, see Set up Work Items for Live Plan.
With Polarion, you don't build a project plan in the traditional sense. Rather you concentrate on defining the Work Items that must be completed in the project's time frame, and for the Time Points within that time frame. You enter planning data for each Work Item either as it is created or later in planning meetings. Polarion's project planning engine takes care of building the project plan which you and others in the organization can see online as a GANTT style chart, and optionally export to Microsoft Project. The Live Plan is updated as developers resolve Work Items, or as new Work Items are added and/or estimated, or as time estimates change. The latest state is always available online. So if you choose the export route, keep in mind that you'll want to do it at regular intervals to keep abreast of the progress.
Once you have the project's Work Items defined and planned, you can always run queries to see what items are open or resolved for any period of time, even if your Polarion product does not have the Live Plan chart.
"Dummy" Project planning
Here is a possible approach you could take to set up Live Plan, especially with a new project. You can use Polarion with Live Plan to create different "what if" scenarios for the project before deciding on the actual scenario on which to start development.
In this approach, you create Requirements and linked Work Items for implementation, setting planning fields for the latter. But you don't initially assign the Work Items to developers. Rather, you (or your Polarion administrator) can create a set of dummy user accounts that parallels the people and roles of your actual development team. As you set up your planning data on Work Items, setting time estimates and planning constraints, you can assign each item to one of the dummy users. The end result is a Live Plan that exactly corresponds to your team. You can look for bottlenecks, under-resourced areas, dependencies, and so forth. If you identify problems, you can adjust planning data on relevant Work Items and review the effect of the changes on the Live Plan.
Once you have a Live Plan that you feel you can begin work on, you assign the Work Items to the appropriate real developers. You can do this fairly quickly using the Bulk Edit feature to assign multiple Work Items to one developer in a single operation.