This guide contains information
about Project Planning, Project
Tracking, Timesheet and Gantt
scheduling.
]po[ Gantt & Timesheet Guide
Frank Bergmann, 2007-06-09
Contents

Concepts
–
–
–
–

Timesheet Management
–
–
–
–
–


Project
(Gantt-) Task
Bug
Forum Item
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
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
frank.bergmann@project-open.com
www.project-open.com