]po[ Gantt & Timesheet Guide Frank Bergmann, This guide contains information about Project Planning, Project Tracking, Timesheet and Gantt scheduling.

Contents  Concepts –Project –(Gantt-) Task –Bug –Forum Item  Timesheet Management –Trust Configurations –Timesheet Logging Scope –Timesheet Logging Interval –Time Overrun Handling –Absences Management  GanttProject Integration  Invoicing

Concepts

Concept: Projects  We think of projects as "containers" of tasks, timesheet information and are the base for group collaboration. Only setup a new project if you have a new group of people collaborating.  Projects are carrying permission information for the tasks below the project. A member of a subproject can log hours on all tasks below the project (by default).  Projects are the base unit for financial controlling. A project should have a quote (external) or a budget attached that define the amount of resources available to spend. On the cost side there are "Provider Bills" (external invoices), "Expenses & Travel Costs" (small external expenses) and timesheet costs (internal costs).  Project are the base for team collaboration. Each project has a filestorage and a forum attached and there is a direct link into the Wiki.

Concept: (Gantt-) Task  A (Gantt-) task defines a specific piece of work that can (potentially) billed to a customer.  Tasks are associated with three different measures of time: –Extimated hours: The PMs estimate how long it will take to complete the task –Billable hours: How many hours can be billed to a customer. –Logged hours: The actually spent number of hours logged via the Timesheet module.  Tasks are associated with a single type of service ("material"). Materials are linked with the price list module, so that you can specifiy a price per customer and material.  Tasks are the base for Gantt scheduling algorithms. Tasks may depend on each other and may have different ways to be started and ended.

Concept: Bugs & Forum Items  Bug: –A bug (bug-tracker item) is a communication measure amongst employees customer contacts. –Bugs are associated with "Bug Tracker Container" subprojects for permission and financial management. The hours spent to fix a bug are logged to the Bug Tracker Container.  Forum Item –The ]po[ forum is a versatile communication measure designed to support a variety of special processes such as CRM (customer conversation notes and reminders to call a customer), provider management (leave comments about the provider's delivered quality),...

Concept: Project vs. Task  The difference between Sub-Projects & Tasks –Projects are thought to be "containers" of tasks, timesheet information and are the base for group collaboration. Only setup a new project if you have a new group of people collaborating. Otherwise we recommend you to use tasks  The project planning & tracking cycle  When to open up a subproject? –If you want to delegate responsability to a different project manager –If you want to separate access to two different subprojects. Example: You don't want to let developers (execution subproject) access the contents of the "acquisition subproject" with contract and sales information.  The GanttProject export only exports the tasks of a project, not subprojects.

Timesheet Management

Trust Configurations  ]po[ supports a number of different "trust configurations" to fit project organizations of different type: –Trusting Organizations: –Every "Employee" (=in-house staff or equivalent) has read access to all projects and tasks in the system. You can configure this option by granting the "view projects all" privilege to the group "Employees". –Similarly, all Employees may have read access to all companies (customers and providers) in the system by granting the "view companies all" privilege to the Employees group. –External users (Freelancers and Customers) are lacking the "view all xxx" privileges. They don't see any project or company in the system unless the project manager or key account has made them a "member" of the specific object. –Competitive Organizations: –Only the members of "Accounting" and "Senior Managers" (or a similar group) have access to all projects and companies. –Employees are treated here just like external users (Freelancers and Customers) in the trusing organization. –Trusting vs. Competitive Organizations: –The "competitve" setting carries a considerable overhead for managing project and company memberships. –Knowledge Management is considerably restricted in a competitive organizations, because the full-text search engine will only return matches from projects with explicite membership in the competitive setting.

Timesheet Logging Scope  A similar decision affects the scope of projects on which a user may log his hours. There are three main configuration options: –"Main Project Scope": A user may log hours to any subproject or task if he or she is member of the "main project" (the ones listed in the "Projects" tab). This option is useful in organizations without many subprojects or to reduce administrative overhead. –"Sub Project Scope": A variant of "Main Project Scope": In multi-level project hierarchies, the user can only log hours to sub-projects where he or she is a member. Or to express it negatively: A user can not log hours to a subproject, unless he or she is explicitely included as a member of the subproject. –"Task Scope": This is the finest granularity of timesheet logging: A user can only log hours to the tasks (of a sub-project) that he or she has explicitely been assigned to.  The three options come with increasing administrative overhead. ]po[ default configuration is "Sub Project Scope".

Timesheet Logging Interval  ]po[ supports "strict" vs. "permissive" timesheet logging: –The "permissive" policy (default) allows users to log hours their projects (according to permissions, see section above) without restriction in the past and in the future. –The "strict" policy restricts the time range to log hours to the current month, except for a configurable number of first days in the month (default 7) where they can still log hours for the last month.  The ]po[ default configuration is "permissive". This policy is useful if an organization just introduces timesheet logging and you don't want to give users any reason to complain about the system that they are not able to log their hours.

Time Overrun Handling  What happens if users log more hours to a task or a project then allowed by the project budget or the "extimated hours" of a task?  ]po[ currently doesn't restrict time overrun situations. Instead, ]po[ provides the reporting measures in order to detect such a situation: –The "Profit & Loss" view of the "Projects" tab allows the PM to determine budget overruns on the level of main projects. –The "Tasks Component" of the main project lists estimated vs. billable hours, so that the PM can easily detect overruns  In the future, ]po[ may include an option to restrict the number of logged hours to the number of extimated hours of a task.

Absences Management  The Absences module is complementary to the Timesheet module. It captures vacation, sickness, training and travel times that are not assignable to a specific project.  Project related travel should not be logged as an absence, but as normal working time for a project.  Currently, only a user himself may add or remove absences. There is no limit to what the user enters into the absences list.  Future versions ]po[ may include more sophisticated control mechanisms such as a confirmation workflow for vacation and travel requests etc.

Timesheet Invoicing

Timesheet Invoicing Overview  ]po[ allows to automate invoice creation based on project and timesheet information. There are several options:  Closed Offer Invoicing: This invoicing mode starts off with a quote detailing the costs of a project and ends with one or more invoices that are to be paid by the customer.  Effort Based Invoicing: The provider bills his customer based on the number of hours delivered to the customer. Thanks to Timesheet management, all employee's hours are tracked and associated to the right project and the right tasks. An "invoicing wizard" then allows to sum up the delivered hours and to multiply them with the price of the task's "material" (service type) for the specific customer. For automation, ]po[ allows to maintain a separate price list for each customer.  Estimation Based Invoicing/Quoting: This is a variant of "Effort Based Invoicing" and may actually be more interesting for quoting then for invoicing. The PM designs a project plan based on the customer's requirements and plans a project. Once the plan has been approved, the ]po[ invoicing wizard automatically creates a quote from the estimated number of hours per task, multiplied with the customer's price list.

Timesheet Invoicing  Managing the customer's price list  Manageing the list of "materials"  Assigning materials to tasks  Executing the Invoicing Wizard

Budget Management  Top-down budget planning  Bottom-up budget planning  Project progress tracking –Base line tracking –Advance vs. Time consumption –Advance vs. Resource consumption  Budget tracking

GanttProject Integration

 Round-Trip Planning  Separation of Tasks from Subprojects –The function "Download GanttProject File" returns a set of gantt-tasks for the current project, excluding any sub-projects "in parallel". This is because each project manager is assumed to be responsible for the tasks below his project. So the PM of the subproject is responsible for his tasks, and the super-project's PM would interfer with the work of the sub-project's PM.  Removing Tasks from a schedule –Removing a task in GanttProject causes difficulties in ]po[ because tasks in ]po[ in general contain logged hours and other objects. –For this reasons ]po[ forces the user to take a decision about where to assign the timesheet information before deleting a task. –Logged hours are moved to the new task. Conflicting timesheet entries (when the same user has logged hours to both the old and the new task for the same day) are merged. –Cost items and sub-tasks are moved from the old to the new task. –Task dependencies and resource assignations to the old task are simply discarded. It wouldn't make sense to pass them on to another task. –Deleting a task may break up a dependency chain if the deleted task represents the connection between two sections of the schedule.

Frank Bergmann