WO2004102431A1

WO2004102431A1 - A system for scheduling at least one task having a plurality of activities to be performed by one or more users of the system

Info

Publication number: WO2004102431A1
Application number: PCT/AU2004/000647
Authority: WO
Inventors: Maarten Peter Tentij; Alan Wong; Xinglian Xiao
Original assignee: Crux Cybernetics Pty Ltd
Priority date: 2003-05-16
Filing date: 2004-05-17
Publication date: 2004-11-25
Also published as: AU2003902399A0

Abstract

A system for scheduling at least one task having a plurality of activities to be performed by one or more users of the system, the system including: a storage device for containing data indicative of a commencement time for the task, a completion time for the task, identifiers for the activities (including necessary know-how and skills), identifiers for the users, and scheduling data that is indicative of the allocation of the activities to the users; project templates containing at least one task; activity templates containing one or more of the following information: description, procedures, required materials; required skills; online links; a selection interface between the storage device and the one or more users for allowing the allocation of the activities to the one or more users and for modifying the scheduling data to be indicative of that allocation, wherein at least one user is allocated more than one activity; a scheduling device for defining a plurality of time segments between the commencement time and the completion time and being responsive to the scheduling data for scheduling each of the activities into one or more of those segments and for updating the scheduling data to be indicative of that scheduling.

Description

TITLE: A SYSTEM FOR SCHEDULING AT LEAST ONE TASK HAVING A PLURALITY OF ACTIVITIES TO BE PERFORMED BY ONE OR MORE USERS OF THE SYSTEM FIELD OF THE INVENTION

The present invention relates to a system for scheduling a task and in particular to a system for scheduling a task having a plurality of activities to be performed by one or more users of the system, and where the system is used by 1 or more companies, each with private environments in which they can store data and procedures and histories and can plan and securely allocate work to company users

The invention has been primarily developed for scheduling personnel and other resources to undertake activities in the provision of a service and to provide these users with and link them to the required job know-how, and will be described hereinafter with reference to that application. However, the invention is not limited to that particular field of use and is also suitable for scheduling personnel and/or other resources in other processes such as the manufacture of a good, or any other business, personal or not for profit activity that involves a sequence or collection of steps. DISCUSSION OF THE PRIOR ART Any discussion of the prior art throughout the specification should in no way be considered as an admission that such prior art is widely known or forms part of common general knowledge in the field.

Project management systems are known, and are typically implemented in a networked computer environment that is accessible by a small number of individuals. Those individuals, having developed a timeline of activities to be performed in carrying out the required project, send the relevant information to a plurality of users who are allocated to undertake the activities.

Initially, the development of the timeline is usually undertaken by a project leader, and involves dividing the project divided into component activities that are chronologically cascaded in a logical sequence, and allocated by the leader to the users. This methodology can be used to provide a clear and detailed estimation of the time-based sequence of performance of the required activities and the individuals who will perform those activities. Unfortunately, it is desirable that the project leader be skilled and knowledgable about the activities involved in successfully competing the project, and training is required to ensure all project managers across an organisation plan and conduct projects in a similar way. Training materials must be constantly updated and changes communicated to ensure that processes and practices are kept current. To improve the benefit of these systems, the requisite activities are being progressively defined within ever smaller time periods. This intensive use of project management systems is an attempt to more accurately estimate the time for each activity, and therefore better determine the time allocation and cost for each of the activities. This, in turn, is intended to allow the time and costs for the project as a whole - the project being the sum total of all the activities - to be estimated with the greatest possible degree of accuracy. However, as the time periods decrease, the complexity of the system increases, together with the required quantum of management time and cost. Present systems have advanced to a point where the overall cost of implementing further detail about the activities is not sufficient to justify the cost savings that are able to realised through the inclusion of that detail. There is no integrated way to standardise the detail about the activity across an organisation, delivered in the context of the work assignement. There is also no simple way to analyse the effectiveness of the detail in order to identify process improvement opportunities.

Additionally, with the greater specificity in commencement and completion times for activities there is a constant need for adjustment as a project progresses. That is, the initial estimates for the commencement and completion times are just that: estimates. As the actual completion time are feedback into the system, it is increasingly likely, with the increasing levels of time specificity, that there will be a discrepancy between the estimate of the time and the actual time ultimately taken for the activity. As each activity in the sequence is linked to the subsequent activities, there is a flow-on effect that requires constant recalculation of the commencement and completion dates for the remaining activities. Re-estimation of effort required to complete the work, and the identifaction of new work is typically a function performed by the project leader, rather than project resources in order to prevent unexpected schedule changes. This causes bottlenecks and leads to inaccurate unrealistic schedules because the project leader can be remote from the work being done.

SUMMARY OF THE INVENTION It is an object of the present invention to overcome or ameliorate at least one of the disadvantages of the prior art, or to provide a useful alternative.

According to a first aspect of the invention there is provided a system for scheduling at least one task having a plurality of activities to be performed by one or more users of the system, the system including; a storage device for containing data indicative of a commencement time for the task, a completion time for the task, identifiers for the activities (including necessary know-how and skills), identifiers for the users, and scheduling data that is indicative of the allocation of the activities to the users; project templates containing at least one task; activity templates containing one or more of the following infoπnation (including hyperlinks to remote data): description, procedures, required materials; required skills; additional data (property sheet). a selection interface between the storage device and the one or more users for allowing the allocation of the activities to the one or more users and for modifying the scheduling data to be indicative of that allocation, wherein at least one user is allocated more than one activity; a scheduling device for defining a plurality of time segments between the commencement time and the completion time and be g responsive to the scheduling data for scheduling each of the activities into one or more of those segments and for updating the scheduling data to be indicative of that scheduling; and an input interface for allowing the or each user to:

(a) selectively access the scheduling data to determine the activity or activities that have been allocated to each segment for that respective user; and

(b) modify the data to indicate a status change of an activity that has been allocated to that respective user.

(c) Add activities and change activity duration data without changing the project schedule

(d) View and change task data (e) Access project, task and activity templates describing for example, but not limited to, company or industry best practices;regulatory and compliance instructions; risk management practice and recommendations. Preferably, the status change includes one or more of: the activity being opened by a user; the activity being allocated to a user; the activity being commenced; registration of additional information about the activity including but not limited to risks, issues, and reasons for schedule delays; action on the activity being held; the activity being completed; the activity being approved; and the like.

Preferably, when the task is underway, in that the actual time is between the commencement time and the completion time, the selection interface allows the allocation of the activities for the segment that is current. More preferably, the scheduling data is modified during the segment that is current. That is, the system provides real time allocation and scheduling of activities.

Preferably also, the system includes a policing module that is responsive to the scheduling data for notifying the users of respectively allocated activities that are to be completed in a segment following the current segment. More preferably, the policing module includes a set of configurable rules for providing one or more notifications for each activity. Even more preferably, the policing system is responsive to the scheduling data for notifying users and managers of respective allocated tasks about delays, changes, and commencement dates or deadlines ,

In a preferred form, the scheduling data is indicative of a status of each activity, and the policing module is responsive to a modification of the data representing a change in the status for notifying one or more of the users, where time also acts as a modifier. More preferably, on subscription or configuration each user is notified in respect of the activities to which they are respectively allocated or are responsible for.

Preferably, there are a plurality of users of the system, and the system is for scheduling a plurality of tasks for those users. More preferably, each user is to perform at least one activity in at least one of the tasks. Even more preferably, the tasks overlap, in that the commencement time and the completion time of a first task fall either side of the commencement time of a second task. It will be appreciated that the tasks are able to be chronologically sequential, in that the commencement time of the second task is not prior to the completion time of the first task. However, in some embodiments, the tasks are continuously sequential - in that the commencement time of the second task is immediately following the completion time of the first task - while in other embodiments, the tasks are discontinuously sequential - in that the commencement time of the second task is time spaced from the completion time of the first task. In further embodiments, combinations of overlapping tasks, continuously sequential tasks, discontinuously sequential tasks, and coextending tasks are used.

Preferably also, the time segments are equal. More preferably, each time segment is a day. Even more preferably, each time segment is a working day.

Preferably, the system is a project management system, and the at least one task is scheduled as a component part of a project including a plurality of tasks describing the continuum of business operations.

In a preferred form, the users are assigned to a position within a project hierarchy, whereby the input interface allows the user or users in the hierarchy to access the scheduling data to determine the activity or activities that have been allocated to each segment for that respective user and any other user that they have permission to access. . In another preferred form, skills requirements are allocated to tasks, and activities are made visible to users who have those skills. In another embodiment, only those users with sufficient time availability have access to activities they are assigned or capable of completing. Preferably, the activities are allocated by the user or users selecting one or more of the activities they have visibility of (self-assignment). However, in some embodiments, the activities are allocated to users by another user in a higher position in the project hierarchy. More preferably, the activities are initially offered to predetermined users for self-allocation and, after a predetermined time, any unallocated activities are allocated to users by the another user. In the preferred embodiments, any unallocated activities are assigned to be the shared responsibility of all the users assigned to a task. That is, by default, all task resources are responsible for the successful completion of all activities, unless a specific resource is assigned to air activity. The latter is defined by a method of inheritance and specialisation, which is embodied in corresponding data held in the storage means.

According to a second aspect of the invention there is provided a system for scheduling a task having a plurality of activities to be performed by one or more users of the system, the system including: a storage device for containing data indicative of a commencement time for the task, a completion time for the task, identifiers for the activities, identifiers for the users, and scheduling data that is indicative of the allocation of the activities to the users; a selection interface between the storage device and the one or more users for allowing users to select the activities they are to respectively complete, and for modifying the scheduling data to be indicative of that selection; a scheduling device for defining a plurality of time segments between the commencement time and the completion time and being responsive to the scheduling data for scheduling each of the activities into one or more of those segments and for updating the scheduling data to be indicative of that scheduling; and an input interface for allowing the or each user to:

(b) modify the data to indicate a status change of an activity that has been allocated to that respective user. (c) access the know-how and instructions associated with the activity, such as the description, next step, procedures, materials, skill requirements and additional information.

(d) find and view new activities from one or more catalogues of activities arranged in a taxonomy.

(e) select and add activities to a time segment . (f) manually create new activities and add them into a time segment.

Preferably, at least one user is allocated more than one activity. More preferably, the system is for scheduling a plurality of tasks for a plurality of users.

In a preferred form, the status change includes the respective activity having been completed, or started or suspended, and which includes the concept of "percentage complete". Preferably also, the users are allocated to positions in a project hierarchy and the selection interface is responsive to the hierarchy for allowing a given user to view or assign activities to be completed by another user who is lower in the project hierarchy, or who is a peer in the project hierarchy. Where multiple hierarchies are involved, hierarchy membership and specific access settings are used to restrict or grant access to user activity information.

More preferably, the given user provides the other users with a predetermined period to select the activities and, thereafter, selects the user or users who are to perform the or each unallocated activity. In the preferred embodiments, the absence of a specific allocated user results in a default that all users assigned to a task are assigned to an activity, or all user that have the necessary skills to perform the activity (where skills and not users, or a mixture of skills and users have been assigned to a task), and in another embodiment who also have the time required to carry out the activity , are responsible for the completion of the activities within that task. Typically, each task has a designated "task leader" with a superior position in the project hierarchy who manages any resourcing allocations. Where tasks have a set of requisite skills but no identified users, there is no designated task leader. In a preferred form, the storage device contains a resource quantifier for each activity and a capacity quantifier for each user, wherein the selection interface is responsive to the quantifiers to ensure that the sum of the resource quantifiers for a given user does not exceed the capacity quantifier for that user. More preferably, the task is defined by a number of sequential segments and the selection interface is responsive to the segments to ensure that the sum of the resource quantifiers for a given user does not exceed the capacity quantifier for that user in each segment. Even more preferably, the selection interface provides a warning signal if the allocation of the activity to the user would result in the sum of the resource quantifiers for that user exceeding the capacity quantifier for that user. More preferably, the user is able to accept the given task if resource quantifiers for other tasks are reallocated or reprioritised such that the resource quantifier for that user is below the capacity quantifier for that user. Preferably, the resource quantifiers are indicative of the proportion of a user's capacity within a given segment to complete the respective activity and the capacity quantifier is indicative of the capacity of a user to perform an activity in a given segment. That is, as the resource quantifiers are allocated to a user, the difference between the sum of those resource quantifiers and the capacity quantifier will reduce. When the difference is zero, the system deems the user as having no capacity to take on additional activities.

In the preferred embodiments, the user who is assigning resources to tasks is able to access the schedule of those resources to determine what they are previously or currently assigned to. Accordingly, if a user's capacity is exceeded or satiated, the user who is scheduling the resources has an understanding of what the resource is otherwise occupied with, and what will have to be done to free up capacity for the current scheduling requirement, if necessary. In an extension of the system, there is a resource levelling function that will use system data to allocate and reschedule work so that a workers capacity is not exceeded, using configurable company policies and heuristics.

Preferably also, the ability of the user to reallocate or reprioritise the resource quantifiers is dependent upon their position in the project hierarchy. More preferably, the storage device includes permission data for each user, and the ability of a user to reallocate or reprioritise the resource quantifiers is dependent upon their respective permission data and the permission data of the user allocating the resource quantifier to that user. In other embodiments, the permissions are determined at a task level.

According to a third aspect of the invention there is provided a system for scheduling a task having a plurality of activities to be performed by one or more users of the system, the system including: a storage device for containing data indicative of a task template, a commencement time, a completion time, identifiers for the users, and scheduling data that is indicative of the allocation of the activities to the users, wherein the task template includes a template commencement time, a template completion time and identifiers for a plurality of template activities; and a selection interface between the storage device and the one or more users for allowing: (a) the selection of the task template by one of the users;

(b) the template commencement time to be assigned the commencement time, and the template completion time to be assigned the completion time;

(c) the template activities to be defined as the activities and allocated to the one or more users; and (d) modification of the scheduling data to be indicative of that allocation.

In the preferred embodiments, the templates include respective duration times, the extremes of which define the commencement times and the completion times. Preferably, when a template is applied to a new project, a scaling factor is applied to the tasks in the templates to stretch or shrink the duration time. For example, if a template that was originally having a duration time of 30 days, and is applied to a new project having a duration time of 45 days, the time between the commencement time and the completion time for each task will be expanded by 150%. However, in other embodiments, the system is responsive to the nature of the task to shrink or expand the duration times at different rates.

Preferably, the system includes a scheduling device for defining a plurality of time segments between the commencement time and the completion time, wherein the scheduling device is responsive to the scheduling data for scheduling each of the activities into one or more of those segments and for updating the scheduling data to be indicative of that scheduling.

Preferably also, the system includes an input interface for allowing the or each user to: (a) selectively access the scheduling data to determine the activity or activities that have been allocated to each segment for that respective user; and (b) allowing the one or more users to modify the data to indicate a status change of an activity that has been allocated to that respective user. In a preferred form, the task is one of a plurality of sequential tasks in a project. More preferably, all the tasks are scheduled by the system.

Preferably, the task template includes at least one resource indicator that specifies one or more of: the quantum of a resource required for the task; the quality or type of that resource; and the segment or segments between the commencement time and the completion time where that resource is required. More preferably, the type of resource is selected from: a human resource; and an equipment resource. More preferably, the resource indicator includes a skill need and a capacity need. Even more preferably, the users are each categorised by a skill ability that is able to be compared with the skill need. Preferably also, each resource has a location indicator, and each task has a location indicator to facilitate matching resources to tasks.

According to a fourth aspect of the invention there is provided a system for allowing a project organiser to schedule at least one project having a plurality of tasks to be performed, the system including: a storage device for containing scheduling data and data indicative of a commencement time for the project and a completion time for the project; a selection interface for modifying the scheduling data in response to the project organiser defining the project by a sequence of one or more tasks, wherein each tasks includes a task commencement time and a task completion time that fall at or between the project commencement time and the project completion time; and a scheduling device for modifying the scheduling data in response to the project organiser associating with each task a plurality of non-sequential activities to be performed between the task commencement time and the task completion time.

Preferably, the storage device includes data indicative of identifiers for a plurality of users of the system, and the scheduling device allocates the activities to the users, such that each activity is allocated to one or more users. More preferably, the scheduling data is modified in response to the allocation of the activities to the users. Even more preferably, the users self allocate the activities. However, in other embodiments, the activities are allocated by the project organiser or by other users. preferably also, the project hierarchy includes a project owner for the project, a task leader for each task who is subsidiary in the hierarchy to the project owner, and a plurality of users who have each been allocated one or more of the tasks, and who are subsidiary in the hierarchy to the project owner and the task owner containing the respective activities. That is, the hierarchy is defined within the project, and is relatively flat, in that a project involving 100 users, would still only require a single project owner and, for each task, a single task leader. Typically, one user is a task leader for one particular task, and is also allocated an activity for a different task where that user is not a task leader. In this way, the hierarchy is not as traditionally used, in that it is dynamically configured between tasks and as tasks are being completed. The project hierarchy can include users who belong to other companies within the same system, which provides a mechanism for numnerous companies using the system to define and run their own projects, and to also collaborate on projects across company boundaries, without gaining access to that external companies non-project specific knowhow unless permission is explicitly given.

In a preferred form, the scheduling device defines a plurality of time segments between the commencement time and the completion time and is responsive to the scheduling data for scheduling each of the activities into one or more of those segments and for updating the scheduling data to be indicative of that scheduling. More preferably, the system includes an input interface for allowing the or each user to selectively access the scheduling data to determine the activity or activities that have been allocated to each segment for that respective user.

According to a fifth aspect of the invention there is provided a method for scheduling at least one task having a plurality of activities to be performed by one or more users, the method including: contafning in a storage device, data indicative of a commencement time for the task, a completion time for the task, identifiers for the activities, identifiers for the users, and scheduling data that is indicative of the allocation of the activities to the users; providing a selection interface between the storage device and the one or more users for allowing the allocation of the activities to the one or more users and for modifying the scheduling data to be indicative of that allocation, wherein at least one user is allocated more than one activity; defining with a scheduling device a plurality of time segments between the commencement time and the completion time and being responsive to the scheduling data for scheduling each of the activities into one or more of those segments and for updating the scheduling data to be indicative of that scheduling; and allowing the or each user to:

According to a sixth aspect of the invention there is provided a method for scheduling a task having a plurality of activities to be performed by one or more users, the method including: containing in a storage device data indicative of a commencement time for the task, a completion time for the task, identifiers for the activities, identifiers for the users, and scheduling data that is indicative of the allocation of the activities to the users; providing a selection interface between the storage device and the one or more users for allowing users to select the activities they are to respectively complete, and for modifying the scheduling data to be indicative of that selection; defining with a scheduling device a plurality of time segments between the commencement time and the completion time and being responsive to the scheduling data for scheduling each of the activities into one or more of those segments and for updating the scheduling data to be indicative of that scheduling; and allowing the or each user to:

According to a seventh aspect of the invention there is provided a method for scheduling a task having a plurality of activities to be performed by one or more users, the method including: containing in a storage device data indicative of a task template, a commencement time, a completion time, identifiers for the users, and scheduling data that is indicative of the allocation of the activities to the users, wherein the task template includes a template commencement time, a template completion time and identifiers for a plurality of template activities; and providing a selection interface between the storage device and the one or more users for allowing: (a) the selection of the task template by one of the users; (b) the template commencement time to be assigned the commencement time, and the template completion time to be assigned the completion time;

According to an eighth aspect of the invention there is provided a method for allowing a project organiser to schedule at least one project having a plurality of tasks to be performed, the method including: containing in a storage device scheduling data and data indicative of a commencement time for the project and a completion time for the project; providing a selection interface for modifying the scheduling data in response to the project organiser defining the project by a sequence of one or more tasks, wherein each tasks includes a task commencement time and a task completion time that fall at or between the project commencement time and the project completion time; and modifying the scheduling data in response to the project organiser associating with each task a plurality of non-sequential activities to be performed between the task commencement time and the task completion time.

According to a ninth aspect of the invention there is provided a system for allowing a project organiser to schedule at least one project having a plurality of tasks to be performed, the system including: a storage device for containing, for each project, scheduling data, communication data, and data indicative of a commencement time for the respective projects and a completion time for the respective projects; a selection interface for modifying the scheduling data in response to the project organiser defining each project by a sequence of one or more tasks, wherein each tasks includes a task commencement time and a task completion time that fall at or between the project commencement time and the project completion time; and an input interface for allowing a plurality of users to selectively access the scheduling data to be assigned a respective association with one or more of the projects; a communication interface for allowing the users to modify the communication data in response to a development within a respective project such that each user who is associated with the project is able to selectively access the modified communications data.

Preferably, the communication data is associated with more than one project. Preferably also, each project includes a plurality of tasks, and the communications data is segmented such that each segment is associated with selected one or more of the tasks. In some circumstances the segments are associated with all the tasks, while typically, they are associated with only one task. This facilitates communication amongst users of the system, as that communication occurs at a project or task level. In other embodiments, each task includes a plurality of activities, and the communication data is further segmented such that those further segments are associated with an activity. This allows the users to be provided with a context at the relevant level. The forms of electronic communication used in the preferred embodiments include email, SMS, alerts, video messages, whiteboard drawings, chat (text messaging) and the like. However, other forms include hypertext links, video and or audio streams and others.

According to a tenth aspect of the invention there is provided a system for allowing a system user or computer software to access the rich project historical data containing all significant project data such as changes made to plans, actual times taken to complete the work, as well as notes and issues and risks and alerts and other communication in order to identify patterns of work and project resource interaction that are used to clearly identify places for process improvement.

According to an eleventh aspect of the invention there is provided a system for "on event" and exception reporting whereby user configurable rules cause system users to be notified in a number of different ways, such as internal alert, email, short text message to mobile phone (SMS), fax, and other means

The preferred embodiments of the invention provide a mechanism for the capture, sharing, access and reuse of steps required to carry out an activity, and to foster constant improvement of the steps to provide a "best practice" information to users in context of an activity, and to allow users to provide expertise - that is, IP capture - on how to carry out a task. This allows and facilitates a "bottom up" approach within an organisation without having to encounter the typical complications and logistical difficulties that arise with personnel meetings, briefings, de-briefings and other educational and data gathering sessions. The "bottom up" combined with a "top down" approach to capturing process descriptions in activity objects that can be searched and inserted into projects can be understood in terms of the product catalogue /shopping cart metaphor. These "items" are sequentially arranged in a logical sequence, and grouped within tasks, and allocated to persons, so that the activities , when sequenced correctly, become a detailed set of instruction to solve a particular problem, yet comprise reusable components that can be reused to reliably achieve repeatable results. This is different from other systems where activities cannot be reused or easily combined in unique ways to solve new problems. The activities represent know-how that can easily be shared or sold. In one embodiment of the system, activity and project template authors can receive payment for the know-how they have contributed to the system because the "owner" or author of the knowledge is recorded. This then provides the basis for a knowledge exchange where subject matter experts can publish knowledge that can be used on projects and can be financially (or through peer recognition) rewarded for providing this knowledge. For example, in mountain climbing or expedition planning, the many activities that need to be completed to say, climb Mount Everest, can be input to the system in the form of a project plan consisting of hundreds of activities which can then be used individually, or as a set, and can bring monetary benefit to the author.

The preferred embodiments of the invention provide a framework for virtual organisations (and virtual project offices) to come into being - whether temporarily or permanently - and to operate efficiently and effectively. This is enabled by the preferred embodiments:

1. Being Internet accessible and not requiring pre- installed software on the client machine.

2. Including activities - and the steps they comprise — that are reusable and accessible on demand.

3. Utilising communication data that is centrally stored. 4. Schedules activities. BRIEF DESCRIPTION OF THE DRAWINGS

Preferred embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings in which:

Fig. 1 is a schematic representation of the system according to the invention; Fig. 2 is a more detailed schematic representation of the architecture of the system of Fig. 1;

Fig. 3 is a functional diagram of the major party inter-relations provided by the system of Fig. 1; Fig. 4 is an illustrative example of a hierarchy for a fictitious company; Fig. 5 is a schematic illustration of the organisation of the users in the fictitious company for multiple projects showing shared access to information; Fig. 6 is a schematic representation of the key knowledge capture-points and flows provided by the system of Fig. 1;

Fig. 7 is a schematic illustration of the usage of the system of Fig. 1 by the users; Fig. 8 is a schematic representation of the relationship between a project and its components; Fig. 9 is a screen shot of one aspect of the input interface for the system of Fig. 1 that provides information about the projects for winch a user is the owner;

Fig. 10 is a screen shot of another aspect of the input interface for the system of Fig. 1; Fig. 11 is a screen shot of the steps involved in an example project when implemented by the preferred embodiment;

Fig. 12 illustrates a screen shot of details involved in a particular job which forms part of a project;

Fig. 13 illustrates an interface showing changes to allocated jobs within a project; Fig. 14 illustrates a series of risks associated with a task;

Fig. 15 illustrates the provision of internet conferencing facilities between a project team incorporated within the preferred embodiment. Fig. 16 illustrates an example chat facility as provided by the preferred embodiment.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

Referring to Fig. 1, there is illustrated schematically a system 1 for scheduling a task having a plurality of activities to be performed by one or more users of the system. The users, in this embodiment, interact with system 1 via thin-client electronic devices in the form of desktop computer 2 and PDA 3. In other embodiments, use is made of alternative electronic devices such as laptop computers, cellular telephones for voice or text based input and output, webcameras , other forms of wireless connectivity (including wireless internet) enabled telephones and the like. While, for illustrative purposes, only two users 2, 3 are shown, system 1 is able to accommodate many more such users, and typically accommodates many hundreds. Users can also be other computing systems 5 that communicate with the system 1. The system 1 is able to server users from multiple discrete units in a secure manner. In one embodiment this architecture is used to provide third party hosted access to the system functionality (often referred to as Application Service Provided (ASP) hosting. In another embodiment the discrete unites are internal company departments. In all embodiments it is possible to securely share information across discrete units, providing the possibility of resources 75 and projects 76 from various units collaborating on a specified activity using a "trusted user" relationship. This is different from prior art ASP models whereby system users belong to one specified unit and cannot access information assigned to other discrete units. This provides a very powerful and new mechanism for inter-company collaboration.

System 1 includes a storage device 4 for containing data indicative of, amongst other things, a commencement time for the task 77 and related project 76, a completion time for the task 77 and related project 76, identifiers for the user jobs 78, identifiers for the users 72 (also referred to as activities), and scheduling data that is indicative of the allocation of the jobs to the users. A selection interface, in the form of the enterprise scheduling application framework 6, is provided between storage device 4 and computer 2 and PDA 3 (and any other users and devices) for allowing the allocation of the jobs or activities to the users and for modifying the scheduling data to be indicative of that allocation. In this embodiment, at least one user is allocated more than one activity, either directly, or as a consequence of being included as a task resource, where activities are then share amongst task resources.

A scheduling device, also embodied in framework 6, defines a plurality of time segments between the commencement time and the completion time and is responsive to the scheduling data in storage device 4 for scheduling each of the activities into one or more of those segments. Once this has occurred, framework 6 updates the scheduling data 4 to be indicative of the activity scheduling, activity status, any cancellations, updates or other changes.

An input interface, in the form of the graphical user front end for framework 6, allows the users to selectively access the scheduling data to determine the activity or activities that have been allocated to each segment for that respective user. It also allows the users to modify the data to indicate the completion of an activity that has been allocated to that respective user. While typically the communication is in a digital format such as text, analogue input such a voice data is also accepted. Fig. 2 illustrates schematically the environment of the preferred embodiment in more detail. Framework 6 is a J2EE framework, and includes a fully functional object pattern for business process scheduling and information management. This framework is configured by a system administrator (not shown) via a system administration console 13. Via this console, the administrator is able to interact with:

(a) Company, user, and related information including permissions and as shown in figure 7.

(b) The business event rules engine contained within framework 6.

(c) Constraint satisfaction and optimisation subsystem 14. (d) A bulk data import/export utility (not shown).

(e) Performance benchmarking utility and control database (not shown).

The preferred embodiments have been developed for use with any major J2EE application server and most RDBMS. Moreover, it is preferred that framework 16 is hosted on dedicated, separate hardware. In this embodiment, the application server's minimum requirements are a J2EE application server supporting CMP Entity and Session EJBs, and supporting the following platforms: Windows | Solaris* | AIX j Unix I Linux. The database server's minimum requirements are a transactional relational database, and providing support for the following platforms: Windows | Solaris* | Linux. Other embodiments could, for example, use upgraded or replacement versions of these and other software packages. When installing the application server on any supported platform, the following are the recommended minimum hardware requirements for the preferred embodiments:

(a) 1 or 2 CPU

(b) 100 MB to unzip files, 75 to 100 MB to install (c) 1 GB free disk space

(d) 512 MB of RAM

(e) TCP/IP Network interface

These minimum requirements will change over time to reflect changes in system features, and industry changes in hardware, computer memory, computer processors, computer architectures, networking technology, and the like.

While the preferred framework is J2EE, other frameworks are also available — such as an MS .NET framework - and are used in other embodiments.

The preferred architecture for system 10 is illustrated in Fig. 2, while a functional diagram of the party inter-relations are provided in Fig. 3. Where reference is made to specific products such as Microsoft ® Outlook ®, these can be substituted for other software providing similar functionality, such as Lotus Notes ®, or other less popular software.

The data held in storage device 4 is collectively referred to as the scheduling data, and is in respect of a plurality of projects that are being run within or participated in by an organisation. The System provides a convenient means for efficiently and effectively facilitating the running and coordination of those projects and the resources required to complete them.

The system 10 operates on the basis of "projects", which are the groupings for operations and coordinations between individual users. Each project includes a project commencement time, and typically also a project completion time. However, some projects are open ended, in that the project completion time is the time of the last scheduled task, and where tasks are constantly added. That is, all tasks or task durations are not known at the time of creation of the project.

Each project includes one or more "tasks", where each task has a task commencement time and a task completion time. That is, tasks are time limited and, as completed, contribute to the progress of the project in which the respective task is included. Each task includes one or more jobs or "activities" that are each to be completed by selected one or more of the users. These activities, contained within the time limits of the associated task, may have specified time limits themselves, where these time limits do not transgress the time limits imposed by the task. Each activity represents a deliverable or output of some kind. Examples of such outputs include:

• The production of a report, letter, document or analysis. • A physical product, such as a painted structure, an assembled good, a repaired device or the like.

• A completed action, be it the sale of an item, the transfer of funds, the movement of goods, the storage of an item in predetermined location, or otherwise.

Each activity includes one or more "detail entries" that are accessible by users who are allocated to an activity. A schematic illustration of the relationship between projects, tasks, activities and detail entries is provided in Fig. 8. It will be appreciated that for each project 20 there are nested tasks 21, for each task nested activities 22 and for each activity nested detail entries 23. For the purposes of clarity, these have only been shown for project 1, task 1 in project 1, and activity 1 in task 1. It will also be appreciated that in some cases the detail entries are able to be linked to the same reference material for different activities or tasks. For example, if two different projects have a task that includes the activity of mixing of a certain grade of concrete, the detail entries for those activities will be the same.. This is notwithstanding that the tasks are completely different, in that one may be for a purposes of constructing foundations for a dwelling, while the other for the construction of a pier. The references for each detail may also be different to reflect the different context, where compliance and regulatory references for the dwelling may be different from those for the pier, even when the method for carrying out the activity is the same. Examples of the minimal set of details associated with an activity are description, procedure, materials, skill requirements, and additional properties. Each detail set can reference material that is accessible through a web browser via a network link. To better illustrate the preferred embodiment, an example will be provided in the form of a fictitious entity, Company X. This entity includes a management hierarchy, such as that illustrated in Fig. 4. Each person within the hierarchy will have to be involved in one or more projects, and will either be overseeing one or more projects, one or more tasks - whether in the same or different projects — or undertaking one or more activities within the tasks. The user overseeing a project is referred to as the owner of that project, while the user overseeing a task is referred to as the leader of that task. Accordingly, the project hierarchy, as opposed to the company hierarchy, is not deep.

Notwithstanding the company hierarchy illustrated in Fig. 4, it is possible for each user to define projects and to have other users involved in those projects. Accordingly, for any given project or task, an owner or leader respectively may have reporting to them, for that project or task, a second user who is above the first user in the company hierarchy. Typically, and as per an example provided in Fig. 9 projects are labelled, for each user, as one of:

• "Own", 91 in that the user is the owner.

• "Group",92 in that the user is able to view, copy or modify (depending on permissions) projects shared to them and owned by other users. • "Schedule", 93 in that the user has activities to perform for that project, and where only relevant tasks (where the user is a resource) and contained activities are made visible. In other embodiments different or additional labelling is used. Multiple projects in each of the categories described above can be accessed by the user.

Fig. 5 illustrates how users who are managers or mentors are able to selectively oversee multiple projects, and how any user is able to view "own" activities they have created (and delegated to others), activities they have been assigned " to do" (by themselves or by others), and "group" activities they have access to because of project roles and user group membership). Fig 10 is an example of a user interface to access these activities

The position of the user within the company hierarchy does, in this embodiment, allow them to nominate or allocate certain users at a lower position within the project hierarchy to accept certain task leadership or activities within a project. The user with the higher position in the project hierarchy is able to allocate the project, task or activity to another user. Once that occurs, the lower placed user is able to carry out the activity without further input. That is, the system provides freedom to the manager to nominate users, but also freedom for the nominated user to carry out the activity without the impression of being micromanaged. In carrying out the activity the user can capture information of progress, status, delays experienced, risks and issues identified in the form of notes 25, hours spent, hour to go, etc. During and after activity completion there is a complete record of what has been or was done to complete a piece of work, and what the original expectations were (baseline). This combination provides a powerful mechanism for analysis of processes and activity completion patterns across the organisation, which can be used to make ongoing improvements. Reports to analyse planned and actual activity performance across the organisation are include in the system, and can be added to and modified as necessary using information stored in the database 4. This library of activity history recoded in database 4 as activity records 22 and 78 of work performed can also be used to analyse staff performance, with no need to re- record what activities the staff carried out. Users are able to add activities to a task to reflect new findings, without affecting the task schedule, because task schedules are controlled by the project manager.

The database 4 (Fig. 2) stores not only the scheduling data, but also template data 74 and 79 as well as previous projects, tasks, activities and detail entries. This template and history data is available to a project owner to assist in the creation of a new project. Accordingly, when a user wishes to create a project they typically first review the template data typically created from a similar prior project. The selected similar prior project is typically an example of best practice, and contains information such as which activities are usually required to complete the work, how the activities should be carried out, and which risks scenarios are often associated with tasks and activities of the project. While the commencement date and completion data will have to be redefined, for many projects the activities will be similar. Accordingly, the system provides a framework for allowing a project owner to quickly define a project and to far more effectively gain an overview of the steps that have been used - and the skills and resources required - in prior projects of a similar nature. Because the procedural information is typically described within the system, and not externally within documents that are not directly accessible from the activity to be performed, the procedures are more likely to be acted upon, and are more likely to be up-to- date because they are centrally managed through administration console 13 or shared by expert users that authored similar process descriptions .

The templates are also available for managers and others - such as quality control personnel - to be updated to accommodate recent external developments such as changes in laws, economic conditions, client requirements, process improvement, or the like. It is also possible for a project owner to define a project afresh without basing it upon an existing template. However, once so defined, that project is then itself able to be incorporated into the template data for assisting the defining of subsequent projects.

When a template is used, the owner of the new project first defines the commencement time and the project completion time. The system then applies an algorithm to allocate task commencement times and task completion times to each of the defined tasks in the project. In some embodiments, the task commencement times and the task completion times are linearly extrapolated from the template to the new project. However, in other embodiments, alternative modes of definition are used to account for minimum times required for certain tasks, fixed times for other tasks, and other factors.

The owner is also able to extract from the template data, a template 711 for one or more activities, as opposed to having to extract a template for a project as a whole. Similar comments apply to activities. That is, the owner is provided with as much assistance as they need, while still having the flexibility to tailor the project. Regardless of the level at which the tailoring occurs - be it at the project, task or activity level - the information is captured and encapsulated into the template data for subsequent analysis and use. For example, the quality assurance personnel may monitor for consistent or regular changes to a particular standardised template task to ensure that the template is updated to reflect new work patterns.

Fig. 6 is a schematic representation 60 of the key knowledge capture-points and flows provided by system 1. It demonstrates how project team know-how can be shared without the need for it to be "promoted" by the knowledge management team 61. From time to time the knowledge management team will review, consolidate, normalise and carry out similar actions on the formatted activity and project artefacts before promoting some know-how to become an organisational standard. This is important as it removes the bottleneck typically associated with the identification and publishing of know-how and best practice within an organisation.

While in the description the users are shown as being co-located within a single organisation, Company X, 60 it will be appreciated that system is equally applicable to inter-organisational projects or to those projects involving consultants or other parties separate from Company X. The usage of the system by the users is schematically illustrated in Fig. 7. System Administration Console. The Console is used to administer the application. It provides the means to register Users (72), to record template know-how (74) and 79 (both representing company knowledge of best practices or industry recommendations, and to register Resources (75) and Skills (710). The Console 13 is also used to manage system security in order to ensure only authorised access to information is possible.

Users. Users are registered with the system and require a user name and password to gain access to the system. Once a User has logged into the system, the User can create new Projects (76), and can schedule Tasks (77) for the Project. Users are associated with resources, and with the skills of the resource. Users, in the context of a project, are also associated with roles, such as project owner, task leader, customer, sponsor, engineer, architect, etc - as appropriate for the project.

Group Projects. Projects can be shared with other users, using a security and permissions mechanism. Sharing projects provides other users with information about the status and composition of projects already in the system. These shared projects can form the basis of new projects.

Template Jobs. Template Jobs are the deliverables or outputs to be produced in each Task (77). Information on Jobs includes "best practice" used by the organisation to carry out its work - its recipes for success. Also included are process instructions on how to create an output or deliverable - detailed steps, with hyperlinks to supporting information such as documents or web pages. Jobs also contain a list of materials required to produce the deliverable and a description of the skills required to accomplish it. The Job description also contains meta-data or properties that classify the deliverable, and which is used to support search and suggest functionality. Access permissions can be associated with a Template Job, to restrict access and usage to only authorised Users.

Resources. Resources are human or other physical resources (such as equipment or rooms) that can be scheduled to participate in Tasks (77). Access to Resources, and resource information can be limited using the permissions system. It is possible for a User to view the availability of any Resource they are authorised to see. This makes it easy to see when a meeting room or equipment is available, and when people are available to be scheduled for new work. Those Users that are also registered Resources will see at a glance which Tasks they have been scheduled to participate in. Projects. Users create Projects that contain the scheduled Tasks (77) to be performed to achieve a project goal. Projects can be shared with other Users using a permissions system. Projects can be created from scratch, or can be created using a Template (79) for the kind of Project the User is managing. Projects can be defined to require particular Skill sets or Resource teams

Tasks. Tasks are time-delimited slots that describe an activity that must be performed. Tasks contain User Jobs (74), and Resources (75), and Skills (710).

User Jobs. Each Task is associated with the User Jobs, or outputs, of that Task. These deliverables can be based on authorised Company Jobs (74), or can be created by Users when no company standard exists. User Jobs can be shared with other Users in the same way as Company Jobs. User Jobs can be promoted to become Company Jobs, according to company policy. Template Projects. Templates can be created from a successful Project (76), and used as a blueprint for a new Project. Templates contain a series of Tasks (77), and dependency relationships between Tasks. Templates also contain the User Jobs (74) required to perform the Task (77).

Skills - Skills can be used to describe roles, or capability, or system and process knowledge. Resources have skill sets, and Jobs have associated skill set requirements. This allows the system user to identify project or organisational skill needs and shortfalls or availability. It also enables work to be allocated on a skills basis (rather than identifying specific Resource(s).

Once the owner of a new project sufficiently defines that project - with selected template data and/or newly derived tasks, activities and details - the knowledge of that project is made available to all users to allow them to be allocated to the activities by associating them with a project or tasks, or by associating the skills they have a project or tasks. The tasks are each broken down into a number of time- based segments between the task commencement time and the task completion time. In this embodiment those segments are continuously sequentially arranged, are of equal duration and are each a 24-hour period. Within a project it is possible to have a number of tasks running in parallel. However, where a task requires as an input, the outputs of another task, there is a need for appropriate scheduling. It will be appreciated that a given project is able to have, for any given segment, one or more tasks being performed.

While some tasks will only be current in a single segment, it is more usual for a task to extend across a plurality of adjacent segments.

The activities within a task are allocated into one or more of these segments depending upon the nature of the activity. Typically, however, an activity will be current in one segment only. While in some cases the owner will suggest or even allocate specific users to be task leaders or to perform certain activities, it is more typical for the activity allocation to be done by the users themselves. That is, self-allocation is the preference, and the interface with the users for providing that self-allocation is exemplified in the screenshot in Fig. 10. Buttons labelled [Accept] 101 and [Release] 102 are clicked by system users on selection (lughlighting) of a job. "Accept" will signify the user has accepted a Job, thus removing it from the list of other system users allocated to the same Task 77, or having the requisite skills to carry out the work, where Tasks are assigned generic Skills 710. Where the user is a Task Leader, as referenced by the Key displayed on Figure 10, that user will still see the Job, appropriately tagged. "Release" 102 signifies the user has completed a portion of the work or for another reason cannot complete the work, and releases the job (User Job 78) back to the pool of resources assigned to the Task containing the Job, or back to the users with skill sets capable of completing the work. However if, after a predetermined time, the self-allocation has not occurred, the system alerts the project owner. This allows that owner to do one or more of: re-schedule the projected or selected tasks or activities within the project, seek additional resources, re-prioritise resources, including users, or simply assign users to the tasks and/or activities yet to be allocated. Activities not specifically assigned to a resource are considered the responsibility of the human task resources.

Not only does the input interface allow users to accept activities that are to be performed, it allows them to later release or reject that activity. In some instances, the owner polices such changes — in that the scheduling data for that project is monitored for such changes, and the owner alerted should such changes eventuate - and have the ability to confirm or deny the change. However, in other instances the change is automatically accepted and the activity is then once again provided to all users as an available item for allocation. In another instance, a user can allocate the activity to another user directly, handing over the work to be done. A user can also allocate the activity to a role (such as owner, sponsor, designer, engineer, etc). In this way users do not need to have an understanding of the resources working on the project, but understand the role of the resource that needs to become involved.

Each project, task and activity has a skill need and a capacity need for that skill, while each user and other resources have a skill ability and a capacity ability. For example, if an activity is to paint a structure, the skill need is a painter, while the capacity need is the number of painters, which is derived from the structure. There will also be other skill needs, such as scaffolding, painting equipment, safety equipment and the like. Again, the capacity need for that skill will be derived from the structure. Where the system has previously been used to schedule the activity, the skill needs will already be accurately captured in the template data and, as such, the project owner and the users allocated to that activity will be greatly assisted in performing the activity.

The storage device 4 also includes data about the consumables for the activities, which in the above example will include quantities and qualities of paint, adhesive tape, sandpaper and the like. In some embodiments, upon initiation of a project, the system 1 interfaces with an inventory and ordering system for ensuring the required raw materials - that is, the consumables - are available for the users.

Each user is categorised by their respective skill ability and their capacity ability through association with a resource. Users are also categorised by their role within the project.. The capacity ability is determined for each segment so that it is able to be accurately determined if a particular user has the capacity to undertake a given activity. For the above example of painting a structure, if the capacity requirement for a given segment is for 50% of a painter, and a user with the required skill ability has only a 20%) remaining capacity for that segment - due to activities being undertaken on other projects - that user is able to ensure they are not over committed, and the person responsible for scheduling resources can also see which entities have the necessary capacity. Alternatively, the user is able to reschedule other activities to free up time to attend to the painting. In some cases, the project owner or task leader is authorised via the permissions to make the rescheduling for another user. User rescheduling is important because it frees up the manager of the project from having to perform all the rescheduling, using imperfect knowledge about the users and the work the users are involved with. As the activities are allocated to users in the respective segments, the scheduling data is modified accordingly and those activities are mapped from the globally viewable schedule, and are visible from the personal schedule of the user who has been allocated the activity. The project owner remains able to access the required scheduling data to determine which user has been allocated to which task or activity. Similarly, a task leader is able to view the allocation of activities within the task to users so as to retain an overview of the resource allocation.

All users are able to view their own schedule, which is responsive to the current scheduling data for providing a real time schedule of projects in which they are respectively involved, and the tasks and/or activities that are required to be undertaken by them personally.

Once an activity is completed, the relevant user updates the scheduling data to confirm that this is the case. Accordingly, the project owner and task leader are provided with a live update on progress. The system 1 can also include a policing system for providing advance warning to users of approaching activities that have to be performed by them. The timing of the policing messages are either configured by a user - be that a project owner, team leader or a user who is to undertake an activity - or by the system 1 based upon the template data. For example, for some activities it is useful to provide a number of days advance warning of the completion date, and to follow up with a further policing message just prior to the segment in which the activity is to be completed. This is particularly useful for those activities that span a number of time segments to ensure that the user is making progress prior to the final available segment. In this embodiment, system 1 is also responsive to the other activities allocated to a user when determining the timing of the policing messages. Messages can be sent to named users, or to project roles, so that knowledge of the users associated with the project is not required.

The interface between the users and system 1 provides a real time view of the user's schedule. An example of the type of GUI that can be used for accessing the system is illustrated in Fig. 9. This includes three main tabs, those being the "My Projects" tab 90, the "Group Projects" tab 91 and the "My Schedule" tab 92. The My Projects tab allows the user to quickly and easily view, and obtain an overview of all the projects 93 of which they are the owner. It provides real time reporting, based upon changes to the scheduling data, to ensure that the owner is aware of completion or rescheduling of activities and tasks. While the timescale in Fig. 9 is graded in days, it can be redrawn in weeks, months, quarters, years or the like.

The "Group Projects" tab 91 allows the user to quickly and easily view the projects in which they are interested, but in which they are not the owner. It also allows selected viewing - as defined by the permissions - for projects on which a user is not a resource. This selective viewing or access is granted in one of a number of ways, including Read, Use and Write access.

The "My Schedule" tab 92 provides the user with a consolidate list for each segment of the activities that are to be performed by that user. In this embodiment, the segments are each 24 hours and, as such, it is typical that any one segment will have more than one activity in each of those segments.

"My Schedule" provides access only to tasks the user is a resource on. This way external participants are able to be given access to the system, with views that include only those portions of the project that they are directly involved with. For all project views, portfolios enable the projects to classified and can provide filtered views of projects. Project status filters enable users to view for example planned, active, suspended, or completed projects.

The advantage of this level of specificity is that the user is provided with scheduling information in a manner that does not make them work in an awkward way. For example, rather than scheduling every activity for the segment linearly in accordance with the time allocation given to it, all the activities are simply placed in the same "bucket" and the user has the discretion to undertake the activities at their discretion and in accordance with that user's preferred mode of work. This level of flexibility ensures that the user is not exposed to a barrage of reminders for specific activities throughout the day, while also ensuring there is available a clear list of the remaining activities for that day. Activities can be scheduled for specific times within the task time parameters, if necessary, using "lag" and "duration" attributes. The system accommodates communications on a project basis. That is, all users are able to provide information in the form of progress data to the system 1, which is stored in storage device 4. The permissions determine who is entitled to view the progress data for a given project. The communications include text messages, email, SMS, fax, video, audio-visual or others. This progress data is associated with the project as a whole, a task or an activity and the viewing availability can be determined by the positioning of an individual within the project which, in turn, can be derived from the permissions. Examples of messages can include interim reports on progress, or reasons for early or late completion, reports on meetings between individuals that is relevant to the conduct of the activity, task or project, anticipated problems, requests for assistance and the like. As all these messages are attached to an activity, task or project, it is easy for the user, at whatever level in the project and according to permisions, to obtain up-to-date information on matters that are of consequence to their own progression of the activities that have been allocated to them.

Another form of message is a shared virtual whiteboard that allows users to easily share ideas notwithstanding geographic dispersion. Moreover, the system can store not only the resultant image but the sequence of stokes that led to the creation of that image. In this way, users are able to gain additional information about the message being conveyed. Preferably also, the sequence of strokes includes an audio component for allowing any audible discussion that was underway between the users to also be replayed in synchronism with the sequential recreation of the image.

The scheduling information includes for each activity a field referred to as activity status. This status has one of a number of possible states, including, for example: "Yet to commenced" or "Open"; "Delayed"; "Overdue"; "Rescheduled" or "Held"; "Cancelled"; "Completed"; and "Approved", amongst others. The actual value of the states is arbitrary. Accordingly, the system 1 offers flexibility in that the label value is loaded into the user interface on application start-up. This allows one entity or organisation to use a status label of "started" and another to use the same status with a label of "no show".

The users update the status of the activity they are responsible for, as required. Typically, once an update is made, the user will also provide a brief communication - that will be added to the progress data - so that all relevant users participating in the project will be, or can quickly be, brought up to speed with the progress of the project or a subset of the project. That is, the activity status and the progress data are used in combination to allow a user to "drill down" as required. This is particularly useful in projects where unexpected delays are encountered, as users are able to communicate the reasons for the delays - by way of the progress data - to all users who need to know. Using the notes mechanism, reasons for delay can also be associated with a period of time, or duration, so that it is a simple matter to explain to a customer where and why delays occurred. This is particularly important when there are penalties associated with late completion of a project or a project task. Recording and communicating (automatically according to user defined rules if necessary) information about, or reasons for, delay allows early intervention by other users to apply corrective action. A systematic array of notes associated with the project, task or activity allows users to access status reports on all projects of interest at a glance. That is, users do not need to drill down into the project to get a good understanding of recent activity.

If, once a project is underway, there is a change in a relevant circumstance, be that internal or external to the company, the system 1 is able to easily reschedule, modify or cancel any one or more of the remaining tasks. Moreover, the relevant users are immediately informed of the change. For example, take a project that is the harvesting of a grain crop with a mechanised harvester, and a change in circumstance that is rainy conditions. In this eventuality, the resources of the harvester and the operator of the harvester will be freed up for that segment or segments, while the requirement for a service crew for the harvester - and the associated consumables for conducting that service - will be sought in that same segment or segments. The crew will be notified of the new schedule details automatically, according to rules that were configured when the project was set up. Rescheduling the filming of various scenes for a film where the lead actor falls ill is another example where rescheduling can incur significant additional financial costs if mistakes are made, in addition to the administrative effort required to achieve the change.

The rescheduling is, in some instances, a result of internal delays or other factors. When this occurs, the system 1 modifies the scheduling data for the remaining tasks in the project by reallocating the tasks to the same users, but in different segments, or to other users with the required skill ability and capacity in the new segment.

In so far as consumables are concerned, these are typically specified in an activity. Once an activity is accepted by a user, the system provides that user with a suggested bill of materials, and seeks confirmation that this is the requirement and, if not, what is. Once confirmation is received, in one embodiment, an order for those materials is placed if necessary. In another embodiment, the user will print a list of materials they require for the day or week or month ahead. In some embodiments, the creation of an order includes defining an activity for a store person within Company X to collect and deliver those materials to the user. That is, one project feeds into another project.

The project in which the store person is involved is open-ended and has activities added in accordance with the materials needs of users in other projects. That is, the project has no completion date, although the tasks do, in that the materials are required for delivery to the users by a certain date to allow the commencement of the task or activity in respect of which the materials have been sought. An example of how this may be structured is that in the storeperson project, each task represents an external project, and each activity is an order for materials. The store person is able to keep an overview of all the tasks via system 1 and to make those tasks available to other personnel witlun the operational area. Moreover, particularly where unusual materials are requested, the activities within the task for the store person includes detail entries to assist the sourcing of those materials. There is also provided suggested pricing information and preferred suppliers.

Because the granularity of the segments used in the preferred embodiment is 24 hours, the act of rescheduling - as is often required for large projects - is far less complex than for prior art systems. For example, it is possible to reallocate activities and, so long as they still fall within the task commencement time and the task completion time, there is no need to reschedule the task itself.

The use of the system 1 provides a dynamically re-configurable system for coordinating and mobilising resources — of the human and other kinds — in accordance with the project needs that are defined. The individuals within a company hierarchy are being continually reorganised in terms of the respective project hierarchies to optimise the use and performance of the available resources. However, it does not replace the company hierarchy as the primary means of accountability within the organisation, but works in conjunction with it to provide a context for carrying out the specific actions required. Other advantages of the preferred embodiments also include: • No need for a client install: as only Internet Explorer with Flash plugin are needed. In another embodiment user interface technology other than Macromedia Flash is used, for example HTML, and in other embodiments there is a client install of for example Java code.

• Online delivery: as all data and server engine located at host site (which could be third party or company HQ). • Application Service Provider (ASP) deliverable: which allows different companies to share the same hardware and software.

• Intercompany collaboration: which allows system users from different organisations to work together on a project.

• Multi-user functionality: with different types of permission (for example, "administrator", "manager" and "collaborator") based functionality.

• Multi-project.

• Personalisable: through an XML file, so that user interfaces can support any language, any label.

• Multiple activities per time slot. • Deliverable per activity: in that an activity should bring about some output (a report, a physical product, etc.)

• Activity links: where multiple online artefacts can be provided such as documents, images, videos, templates, web sites, and web forms can be accessed directly from the activity, task or project. Procedure per deliverable: in that detailed information about best practice is available and easily accessible to the relevant users.

The creation of an extended knowledge base through the use of hyperlinks from deliverables to other documents, and to Internet or Intranet accessible content.

BoM per deliverable: hi that detailed costing of materials to carry out an activity is achievable.

Resource management: people know what they are doing when with easy overview for managers, an communication of change (in both directions) is simple.

Real time collaboration, problem solving and subsequent review: chat, video-conference, whiteboard, notes.

Alerts: Internal, SMS, email, fax.

Unique user interface look and feehpushbutton not menu driven to take into account new devices such as touch screen tablets and handheld personal digital assistants (PDA).

Ability to share projects with customers, partners, mentors, managers, board members, regulatory bodies, etc.

Able to archive projects, and re-import them at a later date, into sytem 1, or other systems.

Able to plan a project at a high level, an in inceasingly more detail, and to involve peers and other decision makers in this proves, without it being visible to or impacting others until the planning phase is complete.

Project re-use, through copy/rename or template; an aspect of knowledge capture.

Work over narrow-band: allows use of a thin client model and thereby broadens the application suitability to wide range of project industries.

Aimed for use "from boardroom to storeroom", give the user intrerface broad appeal across all segments of an organisational hierarchy .

Multi-standard connectivity: for example, cable, wireless, GPRS or WiFi (802.11b).

PDA compatible: interfaces are sized for ease of display on commercially available PDAs.

Multi-time zone: allows this to be specified in personal profile file.

Different project views: "My projects", "Group Projects", "My schedule".

Legacy system integration, through XML APIs or direct database access.

Secure: use https and other security protocols and methods as well as username/passwords and permissions or context related access (or denial of access) to information.

Multi-project management - Facilitates multi-tasking and control

Project templates: build reusable and accurate plans and schedules to facilitate best practices and constant process improvement.

Scenario planning: what-if and alternate strategies.

Project budgeting: rapidly provide cost estimates and control spending at many levels of detail.

Workflow support: alert resources they can start work on a deliverable.

Project sharing: including concurrent multi-user update capability. Direct team access: team contribution to progress tracking.

Project and task progress monitoring: direct access to work status across the organisation. Resource suggestion: identify suitable staff using skills and availability. Resource allocation: schedule resources to complete deliverables.

Resource availability calendars: Easily identify staff availability and allow users to maintain their own calendars.

Project calendars; Associate typical working hours with a project. Personal work calendar: detail resource activities and To-do lists. Shared task and activity notes : support and capture stakeholder communication. Customisable management reports: target areas of interest. Bill of materials identification: supports task preparation and costing. Discrete, reusable activity descriptions: promote reuse, standardisation, starting points. Best-practices and know-how capture: sharing, both top-down and bottom-up. Website content management: dynamic activity and process publication. Constant process improvement: support to iteratively fine tune business practice. Sub-contractor management: through selective access to project components, including detailed activity procedures.

Centralised project archiving and history that is well organised and easy to access: this allows ease of learning from the past.

Ability to use the rich data associated with activities, tasks and projects to find work patterns that can be emulated and encouraged, or that can be stopped, or that can be used to train future system users and other employees. Access via web-browser client: anywhere, anytime, anyplace. Low bandwidth requirements - Cost effective and allows dial-up modem access Minimal training required: easy for non-technical staff to use. Flexible application functionality: modular, extensible and customisable. Framework architecture: standardisation supports scalability and reliability. J2EE based: supports full open standards compliance. MS Outlook integration: through the click of a button. XML import/export utility: data can be reused.

Time-tracking system: actual time spent can be directly integrated to reports, costings and other analysis.

External application and data integration: through XML APIs. Configurable rules; exception reporting, subscription to change and new information. Email and SMS messaging: quickly and reliably signal changes and updates. Schedule optimisation: constantly improve plans.

Advanced risk management support including templates with prepopulated typical risk scenarios. • Modular schedule optimisation methods through Constant Satisfaction sub-system interface. For example, critical chain and/or mixed initiative scheduling and support.

• Graphics and video streaming: support for fraining or stakeholder input.

• Earned value project tracking: determine project delivery status. • MS Project import/export: projects are able to be shared with other technologies o Personalisation: language and time zones

The "personalisable" advantage referred to above allows the project owner, the task leader or any the user to define at the level allowed by the permissions such things as timezone, language, etc. This is of particular importance for those projects that involve users in more than one time zone and who require the use of more than one language across the proj ect.

The advantage of having multiple activities per time slot solves a significant downside of the prior art. Particularly, current project management systems encounter considerable, and at times insurmountable complexity when everything that has to be done has to be sequentially represented on a timeline. The prior art requires people to work unnaturally in that they have to precisely schedule an activity when they don't want to, and where there is no real advantage in them having to do so. Users directly making changes the work times will then impact the overall schedule, something a Project Manager cannot usually allow, because of prior commitments to project completion dates. The preferred embodiment enables controlled user "bottom-up" schedule manipulation, as well as manager initiated "top-down" changes. Take the example of a user being allocated the task of writing a short report for delivery on Thursday, with the capacity need for producing that report being two hours. This task would also include the activities of contacting by telephone or other means one or more key people to provide input into the report. This gives rise to complexity in formulating the system and personal frustration to the user to list each activity - draft report, contact Fred, contact Jane, contact Graham, edit report, circulate for comment, finalise, deliver - with a precise time. This problem is compounded by prior art system that require those separate activities to be linked with commencement and completion times. The preferred embodiment, however, allows a task that lasts all of Wednesday with all of the above activities in it. Each activity can be ticked off- in that the user simply updates the schedule information via the input interface with a single click of a mouse button or other equivalent. The user is also able to assign one or more of the activities to other users. This ensures that the "microtasks" are done, but does not require the onerous effort of specifying in detail the commencement and completion times. This is an enormous management simplification and more closely mirrors the way humans think and work in practice. New microtasks can also be added as they are identified by system users, and real durations can be captured after the initial rough-cut planning is complete.

Email, SMS and other communication is linked to a business or other activity, rather than being stored in a separate repository. This is important for audit trails and moving the user away from a standalone email environment for business communication into an environment directly linked to and supportive of the business activities that need to be performed. It also provides a bottom-up approach to project definition. The project owner is able to provide an outline of what needs to be done, and the experts - such as skilled project resources - are then in a far superior position to flesh out the details and to add tasks that the project owner has left out. This is important, because increasingly the project owner is skilled in management, and not necessarily in the detail of the projects being managed.

The preferred embodiments of the invention are able to capture the data that is being sought by prior art systems for allowing accurate cost figures and performance figures to be calculated. However, that capture is being done in such a way as to not intrusively disrupt the actual performance of the activities or the planning of the project in the first instance.

Applications of the preferred embodiment include, but are not limited to:

1. Strategic

(a) Scenario Planning (b) Business Modelling

(c) Organisational Change

(d) Regulatory compliance

2. New Business

(a) Mergers and Acquisitions (delivery of process and procedures to new staff) (b) Expansion of offices, including Franchise activities.

(c) Relocation of staff (moving offices, opening and closing offices)

3. Production/Engineering/R&D

(a) Engineering Designs/Drawings Creation

(b) Specialized Production Manufacturing Processes (c) Risk Management of plant production lines

(d) Issue Management and Register Maintenance

(e) Hazard and Operability / Process - regulatory compliance

(f) Maintenance scheduling

(g) Delivery of services in a changing situation. For example, emergency services and fire- fighting and other situations where there is a sharing of pooled resources.

4. Sales and Marketing

(a) Campaigns

(b) Customer Profiling

(c) Call Centre Activities (d) Marketing Research

(e) Product/Services Catalogue

5. HRM

(a) Hire Interviews and process

(b) Exit Interviews and process (c) HR Policies

(d) Knowledge capture and skills Inventory

(e) Training and Education Programs

6. Legal

(a) Management of IP portfolio, including patents, trade marks, copyright, design registrations, know-how and the like (b) Contracts

7. Financial

(a) Financial Modelling

(b) Financial Reporting (c) Regulatory Compliance

(d) Governance

(e) Invoicing

(f) Asset Management

8. IT (a) Software Programs and Databases usage

(b) Help Desk processes

(c) Software development

(d) Software release management

9. Procurement (a) Supplier Profiles

(b) Production Planning and Requirements Analysis

(c) Purchasing, warranty and returns

(d) Deliveries and inventory management

10. Wine making and Agri-business (a) Harvest scheduling

(b) Production and product flows

11. Filmmaking

(a) Shoot planning and execution

12. Event management (a) Repeatable complex event planning and execution

13. Building and Construction

(a) Sub-contractor direct involvement

14. Defence and security

(a) Incident investigation (b) Large scale emergency response planning and activation

Other applications include building management; facilities management, such as building maintenance or process plant management and extension or maintenance, taxi ordering systems, personal or corporate consulting, be that for fitness and health, business advisory, accounting, advertising, marketing, planning, governance or others. Governance is a good example of where the preferred embodiment can be used in a way that is not supported by prior art. Regulatory requirements (such as the Sarbanes - Oxley Act) mean that organisations need to perform a wide range of activities that impinge across the business. It is not feasible to define a project to achieve the work, because time frames are not fixed, yet some deadlines are critical. Also, staff will identify new work as they learn what compliance entails, and it is desirable to standardise on some of the jobs that work that needs to be done by several departments, divisions, offices, etc. Training staff to use a new software tool will take a long time. Without a tool used by all participants, administration costs will be high. It is important that the company board and senior management at all times are aware of the status of the many interrelated activities in order to ensure good governance is carried out. The preferred embodiments of the invention allow consultants or project managers and directors to maintain ongoing client or project resource contact and ensure that suggested plans are followed to achieve the desired success. Instead of a consultant or manager just developing a plan of action, the preferred embodiments makes it possible for that consultant or manager to mentor the customer, partner or staff in the successful execution of the plan, or parts of the plan, using the Internet or other suitable communication medium.

The project plans, schedules, processes, checklists, and workflows of a company are able to be quickly captured into the schedule data or template data, and delivered to stakeholders and participants over the Internet. Moreover, the permissions mean that the privacy of that data — which is often highly commercially sensitive - is protected to the level that is required. The preferred embodiments also allow customers to take advantage of the system without necessarily having to be involved in the typically high levels of investment for new software. That is, the preferred embodiments are able to be hosted by a third party. Not only does the third party hosting provide an "on demand" software access opportunity, it also importantly enables system users from multiple companies (including consultants and sole proprietors and small sub-contractor) to collaborate on a project or business activity without requiring access to a company network (which may be a costly exercise that may breach company security policy. This is supportive of a global trend whereby companies increasingly bring together large numbers of people from disparate environments to work together on a project. The preferred embodiment, through the use of reusable discrete activity objects also enables good control of the work each participant undertakes, and provides a mechanism for analysing the history of all participants in order to help in the project or business activity participant selection process.

Fig. 11 illustrates an embodiment of the invention that is applied to a consultancy environment, and includes an activity schedule showing a number of tasks associated with a single project. Each task has one or more deliverables associated with it. Fig. 12 illustrates the details of a task deliverable or activity. Procedures are able to be explicitly described, or contained in a linked document or web page. This allows the user to drill down, but only as required. That is, in the normal course of events the user is not swamped with information, but is able to access information that has been previously identified as being relevant and of assistance. If that user finds other information of more use, this can be incorporated into the project at the relevant level. If the other information is particularly significant, it is included in the template data and therefore made available to users subsequently being engaged in a similar project, task or activity.

Fig. 13 illustrates the message view that is available to the users. The project owner or task resource is able to notify project stakeholders about schedule changes, or other task related information. The preferred embodiments of the invention specifically address the inability of the prior art to make use of email as an effective means for allowing users to communicate over the Internet in the context of a project, task or activity. This is achieved by grounding each communication, be it an email or otherwise, in a specific project, task or activity. This obviates enormous filing issues, and actually makes email more workable. This is important in environments where email received by users is a combination of unsolicited (spam), from friends, from private business activities (dentist reminder), from the employer (general information and requests), from colleagues, and from project participants. Storing and finding relevant project communication, especially after the project is no longer active, is very difficult using prior art solutions.

In addition, prior art project management systems typically identify what needs to be performed, but not how the work is to be done. The conventional wisdom is based upon an assumption that the person who will carry out the work will understand from the label of the activity how to carry out the activity, or that the project manager will separately instruct the user how to perform the task. Where the project manager has scheduled an expert user to carry out the work, there is typically no mechanism in place for capturing the expertise in the context of the project, and being able to easily reapply the expertise. The steps have hitherto not typically being easily accessible to a project manager or a user as a catalogue. Accordingly, it has been impractical, if not impossible, to build a task or project in a modular way, using pre-configured and predefined steps. The preferred embodiments address these deficiencies and allow a project to be built in the first instance, or to be formed entirely from pre-existing building blocks, or a combination of the two, such as where modular units are tailored or modified to reflect the exact requirements of the project under consideration. To illustrate the importance of clear communication of how to complete an activity an example domain is food. If 20 chefs we instructed to make spaghetti bolognaise, there would be 20 similar but different dishes prepared. In environments where uniformity is not required, the fact that all 20 chefs were clearly told to cook a particular dish (at a certain time, in a certain location) is an advantage. Where it is important that the meal is prepared in a certain an uniform way - for marketing reasons , or to take advantage of ingredient prices or processes that maximise profit, prior art systems cannot in a simple way, communicate work instructions and track progress over time. In a further modification of the preferred embodiment, the system is arranged so that users are able to create new Jobs (descriptions of work to be done). The Jobs can include links to files (documents, images, movies) or to web pages. Procedures (step by step instructions) can be provided within the jobs which can also be linked to files or web pages. Jobs are within the context of a Task, and a Task is associated with a Project or other business activity. On creation, Jobs can be given a "category", or can be unfilled.

When a user creates a job it is by default "private", in that is available to the user for reuse within the current activity, or on another activity. A keyword search facility can be provided so that Jobs can be found by searching on keywords. A user can make their Job "public". This makes it available to other users, within the context of their security permissions. This way know-how can be collected from the field and shared with peers without aά'ministrative involvement.

This system can be further extended by the provision of a centralized Company Job Catalogue. An administration user is provided with the ability to "promote" a Job into the list of Jobs in the Company Job Catalogue to create a Job template. This signifies the Job is an example of company or industry best practice. The Job Catalogue can be organised as a tree structure (taxonomy) that is configured by the company. When a Job is promoted it retains its "Original Author" identification. This provides a way of giving recognition to knowledge creators, and helps identify who the company experts in a particular field are.

User are then able to access the Company Job Catalogue, use keywords or the category taxonomy to find a Job, and can insert Jobs into their Projects or activities. These Project Jobs maintain a reference to the "seed" Job Catalogue identifier.

The users of the preferred embodiment are able to save a Project as a Project Template. Templates can be private, and available only to the Template Author, or can be public. A private Project Template does not update the Company Job Catalogue. When a Project Template is made public, the Jobs it contains that have no Job Catalogue reference, are promoted to the Catalogue. This means they are regarded as examples of best practice. Preferably, the system is arranged so that only an Administration user can make a Template public. All Jobs in a Project Template contain a Job Catalogue identifier, unless the Catalogue Job is subsequently deleted. Project Templates are stored within portfolios for easy reference.

When a user selects a public Project Template, the Job Catalogue identifiers are used to find and select the Catalogue Job details. This means that an administration change to a Catalogue Job will be transferred to a Project when the Template is next used. Where no Catalogue Job exists, the local Job details can be used.

The system can be provided with a number of predefined Project Templates and Catalogue Jobs that define a number of best-practice operational processes. Issues can be managed using a "Notes" paradigm. Notes can be associated with Projects, Tasks,

Jobs and Resources. There are a number of standard Note categories, and Issue is one of these. Other user categories are Risk, Schedule, and User. There are three special categories - System, which is a record of changes to project details, automatically logged by the system, and Billable and Non-billable Notes, which track actual time spent completing a Job. Notes can be "Open" or "Closed". Notes also record the time the Note was opened, and the time it was closed, providing a way to measure the time spent working on the item in question. For example, Schedule Notes can be used to track Project delays caused by the project customer.

The system provides the facility to define event rules that generate a notification, such as email,

SMS or internal alert, when a Note is registered. This means that a Project Manager or a Task Leader can request to be notified whenever an Issue is raised, or closed. There are a number of Note Reports that can be generated - these reports can list all open (or closed) Notes for a selected time range, or by Author, or by Type.

Notes enable Project participants to access a permissions protected Project Note Register. This provides easy access to Issues, items impacting the Schedule (reasons for delay), Risks, and general items that have been raised. Closed Notes remain available for access at any time, even months or years after the project was completed. An Issue or a Risk Note that requires action should be formally managed as a Risk.

Although the invention has been described with reference to specific examples, it will be appreciated by those skilled in the art that it may be embodied in many other forms

Claims

CLAIMS:

1. A system for scheduling at least one task having a plurality of activities to be performed by one or more users of the system, the system including: a storage device for containing data indicative of a commencement time for the task, a completion time for the task, identifiers for the activities (including necessary know-how and skills), identifiers for the users, and scheduling data that is indicative of the allocation of the activities to the users; project templates containing at least one task; activity templates containing one or more of the following information: description, procedures, required materials; required skills; a selection interface between the storage device and the one or more users for allowing the allocation of the activities to the one or more users and for modifying the scheduling data to be indicative of that allocation, wherein at least one user is allocated more than one activity; a scheduling device for defining a plurality of time segments between the commencement time and the completion time and being responsive to the scheduling data for scheduling each of the activities into one or more of those segments and for updating the scheduling data to be indicative of that scheduling; and an input interface for allowing the or each user to:

(a) selectively access the scheduling data to determine the activity or activities that have been allocated to each segment for that respective user;

(b) Access the information required to complete an activity through the activity entry (in a project schedule or a calendar)

(c) modify the data to indicate a status change of an activity that has been allocated to that respective user;

(d) add activities and change activity duration data without changing the project schedule;

(e) view and change task data; and (f) access project, task and activity templates describing for example, but not limited to, company or industry best practices; regulatory and compliance instructions; risk management practice and recommendations.

2. A system as claimed in claim 1 wherein the status change includes one or more of: the activity being opened by a user; the activity being allocated to a user; the activity being commenced; registration of additional information about the activity including but not limited to risks, issues, and reasons for schedule delays; action on the activity being held; the activity being completed; the activity being approved, time spent on an activity, time to completion estimates.

3. A system as claimed in claim 1 wherein, when a task is underway, in that the actual time is between the commencement time and the completion time, the selection interface allows the allocation of the activities for the segment that is current.

4. A system as claimed in claim 3, wherein the scheduling data is modified during the segment that is current and the system provides real time allocation and scheduling of activities.

5. A system as claimed in claim 1 further including a policing module that is responsive to the scheduling data for notifying the users of respectively allocated activities that are to be completed in a segment following the current segment.

6. A system as claimed in claim 5 wherein the policing module includes a set of configurable predetermined rules for providing one or more notifications for each activity.

7. A system as claimed in claim 5 wherein the policing system is responsive to the scheduling data for notifying users and manager of respective allocated tasks about delays, changes, and commencement dates or deadlines.

8. A system as claimed in claim 7 wherein the scheduling data is indicative of a status of each activity, and the policing module is responsive to a modification of the data representing a change in the status for notifying one or more of the users.

9. A system as claimed in claim 8 wherein on subscription or configuration each user is notified in respect of the activities to which they are respectively allocated or are responsible for.

10. A system as claimed in claim 1 wherein there are a plurality of users of the system, and the system is for scheduling a plurality of tasks for those users.

11. A system as claimed in claim 10 wherein each user is to perform at least one activity in at least one of the tasks.

12. A system as claimed in claim 11 wherein the tasks can overlap, in that the commencement time and the completion time of a first task fall either side of the commencement time of a second task.

13. A system as claimed in claim 1 wherein the time segments are equal.

14. A system as claimed in claim 13 wherein each time segment is a day.

15. A system as claimed in claim 14 wherein each time segment is a working day.

16. A system as claimed in claim 1 wherein the system is a project management system, and the at least one task is scheduled as a component part of a project including a plurality of tasks describing the continuum of business operations.

17. A system as claimed in claim 1 wherein the users are assigned to a position within a project hierarchy, whereby the input interface allows the user or users in the hierarchy to access the scheduling data to determine the activity or activities that have been allocated to each segment for that respective user and any other user that they have permission to access.

18. A system as claimed in claim 1 wherein skills requirements are allocated to tasks, and activities are made visible to users who have those skills.

19. A system as claimed in claim 18 wherein only those users with sufficient time availability have access to activities they are capable of completing (skill based activity requirement broadcasts).

20. A system as claimed in claim 1 wherein the activities are allocated by the user or users selecting one or more of the activities they have visibility of.

21. A system as claimed in claim 17 wherein activities are allocated to users by another user in a higher position in the hierarchy.

22. A system as claimed in claim 17, the activities are initially offered to predetermined users for self-allocation and, after a predetermined time, any unallocated activities are allocated to users by the another user.

23. A system as claimed in claim 17 wherein any unallocated activities are assigned to be the shared responsibility of all the users assigned to a task.

24. A system for scheduling a task having a plurality of activities to be performed by one or more users of the system, the system including: a storage device for containing data indicative of a commencement time for the task, a completion time for the task, identifiers for the activities, identifiers for the users, and scheduling data that is indicative of the allocation of the activities to the users; a selection interface between the storage device and the one or more users for allowing users to select the activities they are to respectively complete, and for modifying the scheduling data to be indicative of that selection; a scheduling device for defining a plurality of time segments between the commencement time and the completion time and being responsive to the scheduling data for scheduling each of the activities into one or more of those segments and for updating the scheduling data to be indicative of that scheduling; and an input interface for allowing the or each user to:

25. A system as claimed in claim 24 wherein, at least one user is allocated more than one activity.

26. A system as claimed in claim 25 wherein the system is utilised for scheduling a plurality of tasks for a plurality of users.

27. A system as claimed in claim 24 wherein the status change includes the respective activity having been completed, or started or suspended.

28. A system as claimed in claim 24 wherein the users are allocated to positions in a project hierarchy and the selection interface is responsive to the hierarchy for allowing a given user to view or assign activities to be completed by another user who is lower in the project hierarchy, or who is a peer in the project hierarchy.

29. A system as claimed in claim 24 wherein multiple hierarchies are provided and hierarchy membership and specific access settings are used to restrict or grant access to user activity information.

30. A system as claimed in claim 24 wherein a given user provides the other users with a predetermined period to select the activities and, thereafter, selects the user or users who are to perform the or each unallocated activity.

31. A system as claimed in claim 24 wherein, the absence of a specific allocated user results in a default that all users assigned to a task are assigned to an activity, or all user that have the necessary skills to perform the activity are responsible for the completion of the activities within that task.

32. A system as claimed in claim 24 wherein the storage device contains a resource quantifier for each activity and a capacity quantifier for each user, wherein the selection interface is responsive to the quantifiers to ensure that the sum of the resource quantifiers for a given user does not exceed the capacity quantifier for that resource.

33. A system as claimed in claim 32 wherein a task is defined by a number of sequential segments and the selection interface is responsive to the segments to ensure that the sum of the resource quantifiers for a given user does not exceed the capacity quantifier for that user in each segment.

34. A system as claimed in claim 33 wherein the selection interface provides a warning signal if the allocation of the activity to the user would result in the sum of the resource quantifiers for that user exceeding the capacity quantifier for that user.

35. A system as claimed in claim 34 wherein a user is able to accept the given task if resource quantifiers for other tasks are reallocated or reprioritised such that the resource quantifier for that user is below the capacity quantifier for that user.

36. A system as claimed in claim 32 wherein the resource quantifiers are indicative of the proportion of a user's capacity within a given segment to complete the respective activity and the capacity quantifier is indicative of the capacity of a user to perform an activity in a given segment.

37. A system as claimed in claim 24 wherein a user who is assigning resources to tasks is able to access the schedule of those resources to determine what they are previously or currently assigned to.

38. A system as claimed in claim 24 wherein the ability of the user to reallocate or reprioritise the resource quantifiers is dependent upon their position in the project hierarchy.

39. A system as claimed in claim 24 wherein the storage device includes permission data for each user, and the ability of a user to reallocate or reprioritise the resource quantifiers is dependent upon their respective permission data and the permission data of the user allocating the resource quantifier to that user.

40 A system for scheduling a task having a plurality of activities to be performed by one or more users of the system, the system including: a storage device for containing data indicative of a task template, a commencement time, a completion time, identifiers for the users, and scheduling data that is indicative of the allocation of the activities to the users, wherein the task template includes a template commencement time, a template completion time and identifiers for a plurality of template activities; and a selection interface between the storage device and the one or more users for allowing:

(e) the selection of the task template by one of the users; (f) the template commencement time to be assigned the commencement time, and the template completion time to be assigned the completion time;

(g) the template activities to be defined as the activities and allocated to the one or more users; and (h) modification of the scheduling data to be indicative of that allocation.

41. A system as claimed in claim 40 wherein the templates include respective duration times, the extremes of which define the commencement times and the completion times.

42. A system as claimed in claim 40 wherein when a template is applied to a new project, a scaling factor is applied to the tasks in the templates to stretch or shrink the duration time.

43. A system as claimed in claim 40 wherein the system includes a scheduling device for defining a plurality of time segments between the commencement time and the completion time, wherein the scheduling device is responsive to the scheduling data for scheduling each of the activities into one or more of those segments and for updating the scheduling data to be indicative of that scheduling.

44. A system as claimed in claim 40 further including an input interface for allowing the or each user to:

(c) selectively access the scheduling data to determine the activity or activities that have been allocated to each segment for that respective user; and

(d) allowing the one or more users to modify the data to indicate a status change of an activity that has been allocated to that respective user.

45. A system as claimed in claim 40 wherein the task is one of a plurality of sequential tasks in a project.

46. A system as claimed in claim 40 wherein the task template includes at least one resource indicator that specifies one or more of: the quantum of a resource required for the task; the quality or type of that resource; and the segment or segments between the commencement time and the completion time where that resource is required.

47. A system as claimed in claim 41 wherein the type of resource is selected from: a human resource; and an equipment resource.

48. A system as claimed in claim 41 wherein the resource indicator includes a skill need and a capacity need.

49. A system for allowing a project organiser to schedule at least one project having a plurality of tasks to be performed, the system including: a storage device for containing scheduling data and data indicative of a commencement time for the project and a completion time for the project; a selection interface for modifying the scheduling data in response to the project organiser defining the project by a sequence of one or more tasks, wherein each tasks includes a task commencement time and a task completion time that fall at or between the project commencement time and the project completion time; and a scheduling device for modifying the scheduling data in response to the project organiser associating with each task a plurality of non-sequential activities to be performed between the task commencement time and the task completion time.

50. A system as claimed in claim 50 wherein the storage device includes data indicative of identifiers for a plurality of users of the system, and the scheduling device allocates the activities to the users, such that each activity is allocated to one or more users.

51. A system as claimed in claim 50 wherein the scheduling data is modified in response to the allocation of the activities to the users.

52. A system as claimed in claim 51 wherein the users self allocate the activities.

53. A system as claimed in claim 49 wherein the project hierarchy includes a project owner for the project, a task leader for each task who is subsidiary in the hierarchy to the project owner, and a plurality of users who have each been allocated one or more of the tasks, and who are subsidiary in the hierarchy to the project owner and the task owner containing the respective activities.

54. A system as claimed in claim 49 wherein the scheduling device defines a plurality of time segments between the commencement time and the completion time and is responsive to the scheduling data for scheduling each of the activities into one or more of those segments and for updating the scheduling data to be indicative of that scheduling.

55. A method for scheduling at least one task having a plurality of activities to be performed by one or more users, the method including: containing in a storage device data indicative of a commencement time for the task, a completion time for the task, identifiers for the activities, identifiers for the users, and scheduling data that is indicative of the allocation of the activities to the users; providing a selection interface between the storage device and the one or more users for allowing the allocation of the activities to the one or more users and for modifying the scheduling data to be indicative of that allocation, wherein at least one user is allocated more than one activity; defining with a scheduling device a plurality of time segments between the commencement time and the completion time and being responsive to the scheduling data for scheduling each of the activities into one or more of those segments and for updating the scheduling data to be indicative of that scheduling; and allowing the or each user to:

(c) selectively access the scheduling data to determine the activity or activities that have been allocated to each segment for that respective user; and (d) modify the data to indicate a status change of an activity that has been allocated to that respective user.

56. A method for scheduling a task having a plurality of activities to be performed by one or more users, the method including: containing in a storage device data indicative of a commencement time for the task, a completion time for the task, identifiers for the activities, identifiers for the users, and scheduling data that is indicative of the allocation of the activities to the users; providing a selection interface between the storage device and the one or more users for allowing users to select the activities they are to respectively complete, and for modifying the scheduling data to be indicative of that selection; defining with a scheduling device a plurality of time segments between the commencement time and the completion time and being responsive to the scheduling data for scheduling each of the activities into one or more of those segments and for updating the scheduling data to be indicative of that scheduling; and allowing the or each user to:

57. A method for scheduling a task having a plurality of activities to be performed by one or more users, the method including: containing in a storage device data indicative of a task template, a commencement time, a completion time, identifiers for the users, and scheduling data that is indicative of the allocation of the activities to the users, wherein the task template includes a template commencement time, a template completion time and identifiers for a plurality of template activities; and providing a selection interface between the storage device and the one or more users for allowing:

(a) the selection of the task template by one of the users;

(b) the template commencement time to be assigned the commencement time, and the template completion time to be assigned the completion time; (c) the template activities to be defined as the activities and allocated to the one or more users; and (d) modification of the scheduling data to be indicative of that allocation.

58. A method for allowing a project organiser to schedule at least one project having a plurality of tasks to be performed, the method including: containing in a storage device scheduling data and data indicative of a commencement time for the project and a completion time for the project; providing a selection interface for modifying the scheduling data in response to the project organiser defining the project by a sequence of one or more tasks, wherein each tasks includes a task commencement time and a task completion time that fall at or between the project commencement time and the project completion time; and modifying the scheduling data in response to the project organiser associating with each task a plurality of non-sequential activities to be performed between the task commencement time and the task completion time.

59. A system for allowing a project organiser to schedule at least one project having a plurality of tasks to be performed, the system including: a storage device for containing, for each project, scheduling data, communication data, and data indicative of a commencement time for the respective projects and a completion time for the respective projects; a selection interface for modifying the scheduling data in response to the project organiser defining each project by a sequence of one or more tasks, wherein each tasks includes a task commencement time and a task completion time that fall at or between the project commencement time and the project completion time; and an input mterface for allowing a plurality of users to selectively access the scheduling data to be assigned a respective association with one or more of the projects; a communication interface for allowing the users to modify the communication data in response to a development within a respective project such that each user who is associated with the project is able to selectively access the modified communications data.

60. A system as claimed in claim 59 wherein the communication data is associated with more than one project.

61. A system as claimed in claim 60 wherein each proj ect includes a plurality of tasks, and the communications data is segmented such that each segment is associated with selected one or more of the tasks.

62. A system for "on event" and exception reporting whereby user configurable rules cause system users to be notified in a number of different ways, such as internal alert, email, short text message to mobile phone (SMS), fax, and other means.

63. A system substantially as herein described with reference to any one of the embodiments of the invention illustrated in the accompanying drawings and/or examples.