AU2016202813A1 - Methods and systems for task time estimate re-asssessment in a task scheduling system - Google Patents

Abstract

Disclosed are systems and methods for task completion and/or task commencement time estimate re-assessment in a task scheduling system. For example, by determining a remaining task time for a task which has been initiated, a resource may be queried as to whether the task will be completed within the remaining time. If not, the resource is asked to provide a new remaining time for completion of the task. During the new remaining time, the resource may be queried as to whether the task will be completed within the remaining time. If not, the resource is asked to provide another new remaining time for completion of the task. These steps can be repeated until the remaining task time is less than the minimum review threshold. In this way, downstream tasks can be delivered to the task buffer with a reasonable assurance that the upstream task or tasks are near completion. 10 hours 5 hours Display Query: 305 Confirmation that FIG. 3 will be complete in 5 hours? Response: 8 hours 8 hours 4 hours Display Query: Confirmation that will be complete ino 43hours? Response: 6 hours 6 hours31 Dis 'Play Query:31 Confirmation that will be complete in 3 hours? Response: 4 hours hour Display Query: Confirmation that will be complete in 2 hours? ------ 325 Confirmation received or mnimimum review threshold reached

Description

WI00096013 2016202813 02 May 2016

METHODS AND SYSTEMS FOR TASK TIME ESTIMATE RE-ASSSESSMENT IN A TASK SCHEDULING SYSTEM

Field

Disclosed are methods and systems for task time estimate re-assessment in a task scheduling system.

Background

In task scheduling systems, tasks or jobs are delivered to resources based upon various criteria, including time estimates and resource capabilities. In one example, task scheduling systems for software developers deliver tasks to a task buffer from where the software developer resources can take up the tasks. In another example, tasks can be carried out in a warehouse distribution centre where the task management system directs stocker and/or picker resources, in another example, tasks can be carried out in manufacturing where assembly is directed by a task scheduling system.

There are different levels of assessments and processing in a task scheduling system. A system can include a plurality of sub-systems including one or more task management tools and/or automated task managers. By the task scheduling system, there may be an establishment of a task including the attributes and/or qualifications of a resource required for completing the task, a time estimate evaluation of the task completed by a resource or by some other means, an assessment to determine a distribution mix of tasks to resources, output of tasks to a task buffer, display of tasks on a task buffer board, managing progress and completion of tasks, delivery of output of the task to the appropriate resource, and so on. Delivering tasks to a task buffer can provide a mix of tasks to one or more particular resources, which can be a part of a larger mix of tasks to a resource group. It is desirable to provide a mix of tasks to a resource of an achievable quality and with as little resource waste as possible. 1 WI00096013 2016202813 02 May 2016

Summary

Disclosed are systems and methods for task completion and task commencement time estimate re-assessment in a task scheduling system. For example, by determining a remaining task time for a task which has been initiated, the task having been allocated to a resource, and by determining a minimum review threshold, a resource may be queried as to whether the task will be completed within the remaining time. If not, the resource is asked to provide a new remaining time for completion of the task. During the new remaining time, the resource may be queried as to whether the task will be completed within the remaining time. If not, the resource is asked to provide another new remaining time for completion of the task. These steps can be repeated until the remaining task time is less than the minimum review threshold. In this way, downstream tasks can be delivered to the task buffer with a reasonable assurance that the upstream task or tasks are near completion so that the task scheduling system may operate with better efficiency. Additionally, the embodiment of a sub-system for task commencement time estimate re-assessment may also contribute to the efficiency of a task scheduling system. in many task scheduling systems, tasks are delivered to resources, at least in part based upon the time the task is expected to take to complete. One method of estimating task time is an x-factor method and system which is discussed in detail below. Once the task time is estimated, a task management system can include a task completion monitoring sub-system and method. A benefit of such a sub-system can include that it may provide downstream resources who (or that/which in the event that the resource is not human) depend on completion of the task with relevant timing information. For example, if a task must be completed before a resource can begin the next task, a task manager sub-system can deliver the next task when the first task is completed. However, without information relating to the expected completion of the first task, the task scheduling system may not be able to distribute the next task in a timely manner. For example, pre-requisites may be required. Both distributing the next task too soon or too late can have consequences for a delivery schedule. 2 WI00096013 2016202813 02 May 2016

The disclosed systems and methods of a task scheduling system include a sub-system for task time estimate re-assessment providing processing means for determining a remaining task time for a task which has been initiated, the task having been allocated to a resource, and determining a minimum review threshold which is configurable, and on a display, providing means for displaying a request for a confirmation by the resource of an expectation that the task will be completed within the remaining task time. If the confirmation is not received, providing means for displaying a request for an expected optimistic range of time from the current time that the task will be completed is further disclosed. Also disclosed are processing means for receiving the optimistic range of time as a new value for the remaining task time and processing means for determining a particular percentage of time from the current time to the end of the new value for the remaining task time as well as means for storing the particular percentage of time. The particular percentage may be the midpoint of the remaining time, or any other percentage and can be configurable. The confirmation query may be delivered when the remaining time may be, for example, 50% of the previous estimate, that is, at the mid-point. In that case, the remaining time is 50%. Additionally disclosed are processing means for determining when the particular percentage of time is the current time to deliver the confirmation query, wherein the remaining time is an amount of time related to the particular percentage. If the confirmation query is delivered when the task time is at 40% of the task time estimate, the related remaining time of the task time estimate would be 60%.

At that time, the resource can re-assess the remaining time with an optimistic new time for completing the task. Moreover, disclosed are processor means for repeating the before-discussed processes to determine an optimistic revised new value for a task time, until the remaining task time is less than the minimum review threshold. As discussed, a similar sub-system is disclosed for task commencement time re-assessment. Accordingly, the disclosed systems and methods may improve efficiency of a task scheduling system. 3 WI00096013 2016202813 02 May 2016

Brief Description of the Drawings FIG. 1 illustrates an example production environment; FIG. 2 illustrates the display managing server; FIG. 3 illustrates the disclosed re-estimation process being repeated several times; FIG. 4 depicts a flow chart of the disclosed methods; FIG. 5 is a block diagram of an example of an estimation system for use in a project management or work tracking; FIG. 6 is a block diagram of an example of a project management and work tracking system including an estimation system; FIG. 7 is a flow chart of an example of a process for providing a consolidated estimate; FIG. 8 is an example of a skewed probability distribution; and FIG. 9 depicts empirical data in carrying out the described systems and methods.

Detailed Description FIG. 1 illustrates a production environment 100, such as an open plan office where, for example, a new software application is coded. The production environment 100 is any production environment. For example, it may also be related to manufacturing goods, such as cars, or a call centre processing customer calls, a warehouse receiving and distributing goods, or any other production environment. It is understood that the disclosed task scheduling systems and methods is applicable to any production environment. FIG. 1 shows a production environment 100 plurality of work stations, 101,102,103, 104 and 105 including displays. The tasks, upon mix assessment as described in detail below (as well as any other suitable assessments), are delivered to a task buffer which may reside in storage unit. The tasks stored in the task buffer can in turn be displayed on a board. The tasks can be displayed, for example, on a large display 107 and/or the work station displays. The tasks can be displayed in an arrangement that indicates how long the tasks have been on the board, that is, during a defined 4 WI00096013 2016202813 02 May 2016 time period, in this example, the tasks are in columns and rows. As an example, column 109 receives a task icon from the bottom of the column, in the iower most row. As time passes, it can progress upwardly if the task has not been completed and/or otherwise eliminated from the board until it reaches a row representing the limit of a defined time period.

As an example five workstations 101-105 perform multiple tasks. In some examples completed tasks contribute to an entire product, such as a coding a function or class of a software product, the translation of a particular user interface into a different human language, testing of a software module and other tasks. In these examples, the work stations 101-105 are computer clients, such as Personal Computers. A task management tool of a task scheduling system can estimate how long it will take or is estimated to take to complete a task from when the task is commenced. Each workstation may be associated with one operator, such as a programmer with particular attributes. The task manager can associate a task with that programmer, a group of resources or any other combination of entities involved with the task. The task manager may include a time estimate tool utilising an x-factor to determine time estimates. The x-factor is discussed in detail below.

As mentioned above, a production environment 100 can include a tool that further includes an electronic display 107 for displaying a board of the multiple tasks. In one example, the display 107 is a TV screen. The display 107 is communicatively coupled to the multiple workstations 101-105. For example, an HDMI cable or Wi-Fi connects the display 107 to a display managing server 111, which can be, in turn, connected to the same network that the workstations 101-105 are connected to.

This way, the display 107 can be communicatively coupled to the workstations 101-105. In one example, the task manager is a further server on the same network and sends task assignment data to the display managing server 111. The task assignment data is indicative of the assignment of each task to one of the workstations 101-105 or operators. 5 WI00096013 2016202813 02 May 2016

While some examples relate to the task board being displayed on display 109 it is to be noted that task board may also be displayed on the workstations 101-105 or on any other computer system or printed. Task board may be accessible as a HTML webpage or other graphics page by using a web browser. It is beneficial that the task board is a large board that can be seen from a distance, as the visualisation feature that is described herein provides to the viewer notice of a potential risk of a resource falling behind in task completion substantially without need for detailed analysis.

Fig. 2 illustrates the display managing server 111 in more detail. Display managing server 111 can include a processor 202 connected to a program memory 204, a data memory 206, a communication port 208 and a user port 210. The program memory 204 is a non-transitory computer readable medium, such as a hard drive, a solid state disk or CD-ROM. Software, that is, an executable program stored on program memory 204 causes the processor 202 to perform the method in FIG. 3.

The processor 202 may store the tasks of the task board 109 in data store 206, such as on RAM or a processor register in the form of a bitmap image, pixel values in a framebuffer or a graphics card buffer. Creating, generating, modifying the board including related actions, may relate to the processor 202 generating a coded representation, such as an HTML table or an SVG file, that is accessible by display 109 through an internet browser in kiosk mode, for example. Processor 202 may also send the task data via communication port 208 to a server in accordance with the task manager.

The processor 202 may receive data, such as task data, from data memory 206 as well as from the communications port 208 and the user port 210, which is connected to display 109 that shows a visual representation 109 of the board to an observer 216. In one example, the processor 202 receives task data from the task manager via communications port 208, such as by using a Wi-Fi network according to IEEE 802.11. The Wi-Fi network may be a decentralised ad-hoc network, such 6 WI00096013 2016202813 02 May 2016 that no dedicated management infrastructure, such as a router, is required or a centralised network with a router or access point managing the network.

In one example, the processor 202 receives and processes the task data in real time. This means that the processor 202 can update the board 109 when task data is received from the task manager and completes this calculation before the task manager sends the next task data update, such as data indicating the completion of a task or the assignment of a new task. Timing of the task scheduling system can be configurable.

Although communications port 208 and user port 210 are shown as distinct entities, it is to be understood that any kind of data port may be used to receive data, such as a network connection, a memory interface, a pin of the chip package of processor 202, or logical ports, such as IP sockets or parameters of functions stored on program memory 204 and executed by processor 202. These parameters may be stored on data memory 206 and may be handled by-value or byreference, that is, as a pointer, in the source code.

The processor 202 may receive data through all these interfaces, which includes memory access of volatile memory, such as cache or RAM, or non-volatile memory, such as an optical disk drive, hard disk drive, storage server or cloud storage. The computer system 200 may further be implemented within a cloud computing environment, such as a managed group of interconnected servers hosting a dynamic number of virtual machines.

It is to be understood that any receiving step may be preceded by the processor 202 determining or computing the data that is later received. For example, the processor 202 determines the task data and stores the task data in data memory 206, such as RAM or a processor register. The processor 202 then requests the task data from the data memory 206, such as by providing a read signal together with a memory address. The data memory 206 provides the data as a voltage signal on a physical bit line and the processor 202 receives the penetration value via a memory interface. 7 WI00096013 2016202813 02 May 2016

It is to be understood that throughout this disclosure unless stated otherwise, nodes, edges, graphs, solutions, variables, values and the like refer to data structures, which are physically stored, for example, on data memory 206 or processed by processor 202. Further, for the sake of brevity when reference is made to particular variable names, such as "period of time" this is to be understood to refer to values of variables stored as physical data in, for example, computer system 200 in a suitable manner or form.

Referring to FIG. 3, a task time can be estimated in any suitable manner. FIG. 3 illustrates the re-estimation process being repeated several times. For example, as discussed in detail below, a task time can be estimated utilising the disclosed x-factor method. In so doing, in this example, a task time may be estimated to be ten hours 301. Additionally, a minimum review threshold may be determined, for example, to be two hours. The task having been allocated to a resource by the task management system, at a particular time, the remaining task time at the midway point during the ten hour time estimate may be five hours 303.

The midpoint (5 hours) is selected in this example to make a first query that can be provided on a display requesting a confirmation that the task will be completed within the task time (here, 10 hours). The first query can be made at any appropriate time, such being a configurable parameter. The timing of the first query may be dependent upon the task time length. For example, if the task time is 2 hours, it may be more useful to ask the first query after 45 minutes or 1.5 hours than at the midpoint. If the initial task time is a long task time, for example, 72 hours, the first query may be beneficially made when the remaining time is 24 hours. Circumstances may determine the best timing for the first query when the task is initially underway.

In this example, the remaining time is five hours which is the midpoint of a ten hour initial task time estimate. A response to the query is that the task will not be completed within the remaining task time, being five hours, but will be completed in eight hours, which is longer than the initial estimate. The response could have been that the task will be completed in less time than five 8 WI00096013 2016202813 02 May 2016 hours, or five hours. In that case, that is, there is a confirmation that the task will be completed within the remaining task time and the disclosed systems and methods may default to determining a mix of tasks for distribution based upon the confirmation. Any suitable default is within the scope of this discussion.

In this example of the disclosed systems and methods, the response of an optimistic range of time as a new value for the remaining task time is eight hours 307. When the remaining time of this eight hours is at the midpoint of the eight hours, that is, four hours, the disclosed systems and methods provides a request for a confirmation by the resource of an expectation that the task will be completed within the remaining task time. In this example, the response is no, and that the new value for the remaining task time that is six hours 313.

The disclosed systems and methods provide for calculating the midpoint (or other suitable percentage) from the current time to the end of the new value for the remaining task time which is three hours. When the six hours is at the midpoint, that is, three hours 315, the disclosed systems and methods provides a request for a confirmation by the resource of an expectation that the task will be completed within the remaining task time 317. In this example, the response is no, and that the new value for the remaining task time that is four hours 319.

Again, the disclosed systems and methods provide for calculating the midpoint (or other suitable percentage) from the current time to the end of the new value for the remaining task time which is two hours. When the four hours is at the midpoint, that is, two hours 321, the disclosed systems and methods provides a request for a confirmation by the resource of an expectation that the task will be completed within the remaining task time 323. In this example, the response is a confirmation. Alternatively, a minimum review threshold may have been reached 325.

The minimum review threshold can provide a stopping point for the task time re-assessment processes, for example, when the remaining time becomes small. The determination of the minimum review threshold can be dependent upon any one of a number of factors including a 9 WI00096013 2016202813 02 May 2016 practical granularity, the urgency of the downstream or dependent work, the length of the task time being a long task time or a short task time, a particular percentage of the task time, as well as any other suitable criteria. The system can be configurable to make the minimum review threshold a suitable value.

The example of FIG. 3 illustrates that at the midpoint of the remaining time a confirmation of an expectation that the task will be completed within the remaining task time is provided. In this example, the midpoint of the remaining time maybe a convenient time to request the confirmation. Another time to request a confirmation can be a suitable particular percentage of time from the current time to the end of the new value for the remaining task time. For example, the confirmation request time can be 40% of the new value for the remaining task time. So, where the new value for the remaining task time is ten hours, the confirmation request may be provided at four hours. The next time a confirmation is requested can be at a different suitable particular percentage of time from the current time to the end of the new value for the remaining task time. Consistency of utilising the midpoint may be beneficial in the production environment. FIG. 4 depicts a flow chart using the example of FIG. 3 where the midpoint in the remaining time is the point at which a confirmation is requested. The loop between 417 and 403 is processed several times in the steps of 301-325 of FIG. 3. The flowchart depicts that the steps of the disclosed methods can include determining a remaining task time and determining a minimum threshold review 401 at which time the systems requests a confirmation of an expectation that the task will be completed within the remaining task time 403. The disclosed systems and methods can then determine if a confirmation has been received 405. If a confirmation is received, the system may determine a mix of tasks for distribution to resources based upon the confirmation or any other suitable post-process activity can take place 407. As described above, if instead of a confirmation, a new optimistic range of time that the task will be completed is received, a new value for the remaining time task can be determined 409. The request for confirmation and request for a new 10 WI00096013 2016202813 02 May 2016 optimistic range can take place in a single step. From that, a midpoint (or other suitable percentage) from the current time to the end of the new value for the remaining task time can be calculated 411.

The mid-point value (or other suitable percentage value) is stored 413 so that it can be determined when it is the mid-point (or at the suitable percentage value) of the remaining time 415. A determination can be made if the remaining task time is less than the minimum review threshold 417. If yes, a mix of tasks for distribution can be based upon the remaining task time or any other suitable post-process activity can take place 419. If no, then the disclosed systems and methods can provide a confirmation request of an expectation that the task will be completed within the remaining task time 403 and the loop between 417 and 403 can be processed until the remaining task time is less than the minimum review threshold. In this way, downstream tasks can be delivered to the task buffer with a reasonable assurance that the upstream task or tasks are near completion.

As discussed above, a similar process can be utilised in the task scheduling system to determine when a task will be commenced. That is, in the case where work on the task has not commenced, and is yet to commence, a similar process can include an expectation that the task will commence at a certain time, for example, in ten hours time. At a certain point in that 10 hours, for example, in five hours, a query is delivered to the resource asking for confirmation that the task will be undertaken or commenced, and the response is no, the system can provide the opportunity for the resource to provide an optimistic re-assessment of the time that the resource expects to commence the task. That time may be six hours. Then again, a query may be generated to request confirmation, this time in three hours, that the task will be commenced in three hours. If there is no confirmation then the resource will be provided the opportunity to provide an optimistic reassessment of the time that the resource expects to commence the task. This may continue until the remaining task commencement time is less than the minimum review threshold. In this way, the expectation of a task commencing can be accounted for in the task management system. 11 WI00096013 2016202813 02 May 2016

Referring to the X-factor method of task time estimation as mentioned above, many methodologies and systems exist for resource estimation in project planning and some systems can be quite effective where resource requirements can be well defined and predictable. For example, where processes are mechanical, routine repetitive tasks such as laying carpet per square metre, or consumption of resources where historical data allows relatively accurate estimation, such as time for consumption of a tank of fuel during average city driving. Reasonably reliable estimates, particularly time estimates, can be produced using historical data for repetitive or routine tasks.

Estimation of effort (typically measured in time or value based on time estimates) for professional services presents a much more difficult problem due to the nature of the work. For example, in research and development work in a project is often new. A new problem to solve or set of requirements to implement may have no accurate historical body of data from which to infer estimates exists. Further, the execution of the work is highly dependent on the individuals performing the work. This can include individual competence and efficiency, available working hours, task loading and other external factors. Other external factors may include personal problems which may impact on work performance, for example, health or family problems, or work related impacts such as office politics or performance perceptions. All of these factors which may influence the individual performing the work can be highly variable and individualised.

Some known approaches to try to improve estimation accuracy in highly variable environments include detailed definition of work components and estimating based on each narrowly defined component. Project planners start drilling into the task durations attempting to fix the estimation problem, based on the theory that finer granularity enables more accurate prediction - i.e. the more we know, the more accurate the estimate. This approach may be effective if one were dealing with something that is highly predictable or based on historical data, for example when measuring how long it would take for a tank of petrol to be consumed with average city drivers. In this case, one can obtain a distribution to use for estimation from experimental or historical data. 12 WI00096013 2016202813 02 May 2016

However, finer granularity of estimation may not solve the problem, particularly for professional services. Some narrowly defined tasks may be more accurately estimated but others still suffer from high variability as discussed above.

Some known systems aim to solve estimation problems using various statistical methodologies, involving estimating standard deviations around the means. For example, an estimate of five hours being interpreted as a mean of five hours and a probability distribution existing around that mean estimate, typically assuming a normal "bell" curve distribution. Many methods involve some number that is deemed to be a mean, and then some other numbers that are standard deviations. Such systems typically use a three or four point estimation technique, for requiring estimators to try to accurately predict three of four different values for a task - for example, mean, median, mode, standard deviation - giving an estimate of variability about likely/expected outcomes. Several problems with existing statistical estimation methods have been noted when these are applied for estimation of professional services.

First, many methods assume a normal distributions for probability for the outcome, however the probability distributions tend to be skewed. Typically, a time estimate for a body of work has a much higher chance of being longer than a most likely estimate than it has of being shorter than the most likely estimate. Thus, any method based on a standard distribution is flawed, and in reality losses will accumulate and gains are lost.

Second, significant consideration and/or calculation is required for the estimator to derive the three or four point estimation data. However, due to the nature of the work this calculation requires many assumptions - so the estimates may have been estimated using incorrect assumed values and therefore be inaccurate. There is a reluctance to provide such estimates due to the effort and once an estimate is given, pressure to commit to generating the outcome "on time" at the maximal likelihood estimate given. 13 WI00096013 2016202813 02 May 2016

Third, estimates tend to be optimistic or pessimistic, this may also be influenced by external human factors, such as a project manager putting pressure on staff to provide shorter time/lower cost estimates. When making a consolidated estimate, an over representation of under or over estimators can significantly influence the outcome.

Another problem is network effects whereby some tasks are executed serially but others may be executed in parallel. Estimates in this case are not all additive, serial tasks are additive but others are not. This means additional data is required to enable network effects to be taken into consideration for a consolidated estimate encompassing several tasks. The effort required to model network effects to enable accurate compensation for network effects in estimates is typically not performed and therefore the mathematics used for calculating consolidated estimates is typically flawed. Historical data may be used to regressively determine an empirical value to use for compensation of network effects, but this will only be effective if the amount of parallel and serialism is relatively constant between projects.

Typically the result of these estimation methods and problems is erroneous estimations which can be misleading, when used in project planning management and tracking systems and induce frustration and lack of confidence. There is a need for a more effective estimation system for estimation of effort for integration into project management and tracking systems.

Disclosed are quantitative time estimation methods and systems of a project management system. Utilising a display driver and a processor, methods include rendering for display a sub-task identifier and one or more user input fields for a sub-task representing high confidence assessment of a first time estimate value and a high confidence assessment of a second time estimate value for the sub-task. The second time estimate value is a multiplier or divisor value representing high confidence assessment of variability from the first time estimate value. The disclosed method further includes from user input, the processor generating an associated centre value derived from two of the low end time value, the high end time value and the range width value and the processor 14 WI00096013 2016202813 02 May 2016 aggregating the associated centre value for each sub-task of a task to generate a consolidated quantitative time estimate for the task for utilisation in the project management system.

The disclosed X-factor method can include in a task scheduling system including a processor configured as an estimation processor and a display, a quantitative time estimation method of generating a consolidated quantitative time estimate for a task comprising a plurality of defined subtasks the steps of for each one of the plurality of defined sub-tasks of a task, outputting for display on the display a sub-task identifier an indicator of data input fields for input of a first time estimate value being in a unit of time and an x-factor value, the fields for receiving input of a responsible person of a first time estimate value determination and an x-factor value determination by the responsible person, the first time estimate value being a quantitative value indicative of one end of a time estimate range, the first time estimate value being a value that the person responsible for the user input has a particular level of confidence in being an end point of a range for time estimation purposes and the x-factor value being an integer multiplier value of the first time estimate value representing the degree of the particular level of confidence that the responsible person has in the first time estimate value. The method can further include receiving instructions by the estimation processor via user input to the display fields for input of a first time estimate value and an x-factor value, the instructions representative of a user data input of the responsible person indicating the first time estimate value, and the x-factor value, wherein the first time estimate value is the low end time value and wherein the multiplier value is used to determine a high end time value being in a unit of time by multiplying the first time estimate value by the multiplier value and in response to receiving the first time estimate value and the multiplier value, the estimation processor determines, using the received first time estimate value and the multiplier value for the sub-task, a low end time value, a high end time value, a range width value being in a unit of time and an associated centre value of the range value. Moreover, the method can include in response to having received the first time estimate value and multiplier value for all sub-tasks of the task and aggregating by the estimation processor the associated centre value for each sub-task of a task to 15 WI00096013 2016202813 02 May 2016 determine the consolidated quantitative time estimate being in a unit of time for the task, without an assumption of a particular statistical distribution. Also the method can include outputting the consolidated quantitative time estimate being a standard estimate which is not an estimate of mean, median or mode for the task for task scheduling by the task scheduling system and incorporating the consolidated quantitative time estimate for the task into a resource scheduling tool of the task scheduling system that is processing a plurality of tasks for work flow management output to generate project estimates.

In a disclosed quantitative time estimation system, the system can include a display driver, a processor and a database. The database can be for storing in a task definition storage location of the database task data representative of one or more defined tasks and wherein each task comprises a plurality of sub-tasks, wherein data elements representative of each of the sub-tasks are separately stored in data fields defined in the database, the data representing each-sub task including a sub-task identifier data element. The display driver can be configured to generate for display on a display screen, a user interface displaying at least one sub-task identifier and provide input fields to input a first time estimate value and a second time estimate value for the sub-task, wherein the first time estimate value is a quantitative value representing high confidence assessment of one end of a time estimate range, and the second time estimate value is a quantitative value representing high confidence assessment of the other end of the time estimate range. The processor can be configured to, in response to receiving data input of the first time estimate value and the second time estimate value, determine using the first time estimate value and the second time estimate value for the sub-task, a low end time value, a high end time value, and a range width value and store the low end time value, high end time value, and range width value as data elements for the sub-task in data fields defined in the database, generate for the subtask an associated centre value derived from the low end time value and the high end time value and store the associated centre value as a data element for the subtask in a data field defined in the 16 WI00096013 2016202813 02 May 2016 database. The processor can be further configured to provide output representative that an associated centre value has been stored for all sub-tasks of a task and aggregate the associated centre value for each sub-task of a task to determine the consolidated quantitative time estimate for the task. The processor can be further configured to output the consolidated quantitative time estimate for the task for utilisation in a project management system.

The disclosed project management systems and methods include a data base for storing in a task definition storage location, task data representative of one or more defined tasks and wherein each task includes a plurality of sub-tasks. Data elements representative of each of the sub-tasks are separately stored in data fields defined in the database, the data representing each-sub task including a sub-task identifier data element. A processor can be in data communication with the database, the processor configured to automatically update task and sub-task data stored in the database in response to receiving data input indicative of task planning and execution. A display driver can be configured to generate and display on a display screen, a user interface to enable data input to define tasks and sub-task in the task definition storage location of the database, wherein for a project planning phase the display driver can be configured to generate for display on a display screen, a user interface displaying at least one sub-task identifier and providing input fields to input a first time estimate value and a second time estimate value for the sub-task, wherein the first time estimate value is a quantitative value representing high confidence assessment of one end of a time estimate range, and the second time estimate value is a quantitative value representing high confidence assessment of the other end of the time estimate range. The processor can be configured to, in response to receiving data input of the first time estimate value and the second time estimate value, determine using the first time estimate value and the second time estimate value for the sub-task, a low end time value, a high end time value, a range width value and store the low end time value, high end time value, and range value as data elements for the sub-task in data fields defined in the database. The process can furthermore be configured to generate for the 17 WI00096013 2016202813 02 May 2016 sub-task an associated centre value derived from the low end time value and the high end time value and store the associated centre value as a data element for the subtask in a data field defined in the database. The processor can be also configured to provide output representative that an associated centre value has been stored for all sub-tasks of a task, aggregate the associated centre value for each sub-task of a task to determine the consolidated quantitative time estimate for the task, store the consolidated quantitative time estimate. The processor can be further configured to apply the consolidated quantitative time estimate for one or more tasks in an automated task scheduling process.

The disclosed systems and methods provide a computer system implemented quantitative estimation method and system enabling generation of a consolidated estimate for a task comprising a plurality of sub-tasks. In a first example, as illustrated in the block diagram of Figure 5, the system comprises an estimation processor 510 which utilises a task definition 520 data file or database and a user interface and display driver 530 to facilitate communication with user terminals or other input and output devices. The task definition data file or database 520 stores data for one or more tasks broken down into sub-tasks. The estimation processor 510 is configured to, for each task, trigger the user interface and display driver to cause display of sub-task data to users and receive input of a first value and a second value for each subtask. In response to receiving data input of the first and second values, the estimation processor 510 determine an estimated range for the sub-task. From these two values only the estimation processor determines, for a range, a low end estimate, a high end estimate, a range width and a centre value. The estimation processor determines a consolidated estimate by aggregating the centre values calculated for each sub-task from the input values for all the subtasks of a task.

The disclosed systems and methods can be utilised as an component of a project management or work tracking system or as a standalone estimation system. An example of a project management and work tracking system incorporating an embodiment of the estimation 18 WI00096013 2016202813 02 May 2016 method is illustrated in Figure 6. The project management and work tracking system is implemented in a computer system environment comprising processor 610 resources and memory 620 resources used to implement program system functionality including scheduling of tasks/sub-tasks and tracking execution by a scheduler/tracker 680 using defined task and sub-task data 670 and managing acquisition and dissemination of project data from users by a user interface and display controller 660.

Project tasks are broken down into sub tasks and the task/subtask data 670 stored in memory 620, for example as one or more data files or in a database structure. The scheduler/tracker 680 is configured to enable project data to be entered into the system for initial project definition and project execution tracking. The scheduler/tracker may provide tools to facilitate the initial task definition and subtask breakdown from higher level project specifications and requirements, and task/subtask scheduling. The scheduler/tracker may facilitate task and subtask definition and storage in a task definition storage location of a database task data representative of one or more defined tasks and sub-tasks. Data elements representative of each of the sub-tasks can be separately stored in data fields defined in the database, the data representing each-sub task including a sub-task identifier data element which can be used to render for display information to allow a user to identify the subtask. The scheduler/tracker may include functionality for automated monitoring and update of project execution data. For example, managers and team leaders may input initial project task and subtask definitions and initial data, the data for these subtasks can be subsequently updated manually or automatically based on activity of project team members, for example in response to deliverable being completed or periodic status updates of work progress input form user terminals and updated in the system memory 620. The user interface and display controller 660 is configured to control display of project information to users, (for example, via their user terminals 640a-c or common resources such as a project tracking display screen 650), outputting of reports, and receipt of input data from users, for example from networked user terminals 640a-c. For example, the user interface and display controller 660 may be 19 WI00096013 2016202813 02 May 2016 configured to control presentation of a display screen displaying sub-task identification data and data fields allowing input of estimation values, for example estimation of effort required for completion of a task which will typically be a time based estimate. This may include display of graphical user interfaces to assist input of data values, for example displaying duration selection sliders, date selectors etc. manipulable by a user to graphically indicate a numerical value, for example, number of person minutes or hours, calendar based estimates etc.

The user interface and display controller may also be configured to perform data transformation of input data from a file input into alternative file formats or database entries. For example, conversion of a data input in a spreadsheet format to database data entries. Input format conversion may also convert input data from input formats incompatible with other system components into compatible formats. Alternatively an input interface and display controller embodiment may be configured to perform data extraction or data mining to automatically identify project relevant data from monitored inputs or associated systems, for example data mining from change requests, and extraction of project relevant time entries from a timekeeping system. It should be appreciated that the above described examples of project management and work tracking functionality is non-limiting and the different functions implemented by the project management and work tracking system will vary between embodiments and different functions can be implemented to tailor the system for different project environments.

The system can be implemented using a variety of different system architectures. For example, in an embodiment the processor 610 and memory 620 resources may be provided by a general purpose computer such as a personal computer (PC), laptop/tablet computer, or server having internal memory including volatile (for example, random access memory RAM, buffers etc.) and non-volatile (hard disk, solid state memory, optical disk etc.) memory resources and optionally external memory resources accessible by the processor via wired or wireless data connections. In alternative embodiments the processor 610 and memory 620 resources may be network accessible 20 WI00096013 2016202813 02 May 2016 distributed resources, for example distributed processing and memory resources within a company network, or "cloud based" on demand processing a memory resources accessible via the internet.

In this example the project management system processing 610 and memory 620 resources are in data communication with user terminals 640a-c and other communication resources such as display screens via a network 630. For example, the network 630 may be a local area network, such as an Ethernet network or secure WiFi within a company premises, or a secure intranet. Alternatively, the network may be a public network such as a telecommunication network or the Internet. The user terminals 640a-c may be laptop or desktop computers, tablets or smart phones etc., having input interfaces such as keyboards, touch screens, scanners, transceivers, microphones and sensors (for example, sensors for motion, speed, temperature, humidity, light, location etc.). Output interfaces can include display screens, speakers, printers etc. The types of input and output devices provides at a user terminal can vary between users terminals and many variation of terminals can be supported by any one system embodiment.

The system functionality is implemented in some embodiments as one or more software programs which execute using the processing 610 and memory 620 resources as described above and interact with external interfaces of the networked computers 640a-c. The system may be implemented as software programs or routines executable using the processing 610 and memory 620 resources which are accessible via a network 630 from one or more user terminals which provide user interface capability and local processing capability and memory. In alternative embodiments some system functionality may be implemented using a combination of hardware and software. For example, the network 630 may be a local area network, such as an Ethernet network within a company premises, or a secure intranet. Different users may be enabled access to the system for specific purposes only. For example, some employees or job categories may be provided with access to view a broad range of data but limited to updating only defined data elements, typically related to work defined for the user. Other users, such as project managers and team 21 WI00096013 2016202813 02 May 2016 leaders may be provided access to enable viewing and updating of broader ranges of data. In some embodiments, updating of some categories of data may be restricted to ensure that only the user to whom work is allocated or an authorised delegate may update the data relating to the work.

The disclosed embodiments may be implemented as a component of a project management system or as a stand-alone system.

An example of an estimation method in accordance with an embodiment is illustrated in the flowchart of Figure73. The disclosed methods and systems provide a quantitative estimation method of generating a consolidated quantitative estimate for a task comprising a plurality of defined sub-tasks. Each task is broken down into a plurality of sub-tasks, the task and sub-task data is stored in a system database or data file. In an embodiment the task and sub-task data is stored in a database accessible to the estimation engine via data communication, for example, via a wired or wireless private network (i.e. Ethernet LAN, WiFi WLAN or combination thereof) or communication network and the Internet.

As shown in Figure 7, for each one of the plurality of defined sub-tasks of a task, sub-task identifiers are retrieved 710 from memory 720, for example using a database query, or extracted from a data file or lookup table etc. A displayed sub-task identifier can be a numeric, alphanumeric, text, an icon, image or any other suitable indication of the sub-task requiring a time estimate, and may provide access to data relevant to the sub-task, including, for example, descriptive content, available resources, time constraints, physical constraints and associated attributes about the subtask and/or the task. The data relevant to the sub-task may be displayed in response to a user input such as clicking on an icon or button to expand a window or display additional data fields.

The user interface and display driver 530 controls the formatting and rendering for display of the sub-task identifiers 720, so when displayed a user can input time estimate values. The formatting of data for display may include display of data entry fields or cells and instructions for time estimate value entry. The sub-task identifier can be presented in any form that allows a user, 22 WI00096013 2016202813 02 May 2016 typically a responsible person for the sub-task, to recognise the sub-task and input time estimation data. The data defined for each subtask can include a task/sub-task allocation identifier indicating the team member or team to which the task/sub-task has been allocated. For example, using text, numeric, alphanumeric codes, icons, colours, images, maps etc. Effects such as zoom in and zoom out or expansion and collapsing of tasks and subtasks may also be used to allow visualisation of different levels of detail and granularity of tasks and task breakdown during the estimation process. The user interface and display driver can be configured to selectively render for display sub-tasks for a responsible person or based on allocated users for tasks. For example, subtasks for display may be grouped based on team or team member allocated to the sub-task and display of sub-task ordered by team and/or allocated team member, alternatively only tasks/sub-tasks allocated to a team or team member may be rendered on displays/terminals associated with the allocated team.

For each sub-task 730 the estimation processor 510 receives and stores in memory a data input indicating a value for one end of a range for the estimate 740 and a data input indicating range width 750. In a first embodiment the first time value is a low end estimate for the sub-task and the second time value is a value indicating range width, for example a multiplier. In a second embodiment the first input is a high end time estimate for the sub-task and the second time value is a value indicating range width, for example a divisor. The second value may also be a width value.

In a third embodiment the first time value is a low end estimate and the second time value is a high end estimate. In response to receiving input of the first time value and the second time value, the estimation processor calculates from the first time value and second time value for the sub-task a low end time value, a high end value, a range width value and a centre value 760. In the first embodiment described above the low end time value is multiplied by the multiplier to calculate the high end estimate time value. In the second embodiment described above the high end time value is divided by the divisor to calculate the low end time value. In the third embodiment the high end time value is divided by the low end time value to derive a multiplier indicative of the range width. 23 WI00096013 2016202813 02 May 2016

For each of the embodiments the centre value, which may also be referred to as the standard estimate, can be calculated: , , low end estimate+hiqh end estimate r,_ „. center value = - [Eq. 1]

The steps 730 to 760 can be repeated until all subtasks for a task have been completed 770.

In response to having received and processed the first time value and second time value for all sub-tasks of the task 770, the estimation processor aggregates the centre value for each sub-task of a task to determine the consolidated quantitative estimate for the task 780, and outputs the consolidated quantitative estimate for the task 790. The estimate can also be stored in memory or a database. The consolidated estimate may be output to a user via a user interface. Alternatively or additionally the consolidated estimate can be output to one or more further project management or tracking system components, for example a resource scheduling tool. In some embodiments, data output to the project management and work tracking system can also include any one or more of the low end time estimate, high end time estimate, multiplier/range and centre value for sub-tasks. For example, the subtask estimate values output as a data file, data signal or stored in a database part of or accessible to the project management and work tracking system.

Alternative or additional consolidated estimates are contemplated within the scope of this discussion. For example, the data defined for each subtask can include an allocated user identifier the estimation processor is further configured to aggregate the centre value of each sub-task for an allocated user of one or more task to determine a consolidated estimate for the allocated user.

The above consolidated estimate generation can be repeated for a plurality of tasks, for example a group of tasks making up a body of work, and a further consolidated estimate generated for a plurality of tasks by aggregating the consolidated estimates for each task. 24 WI00096013 2016202813 02 May 2016

Consolidated estimates may also be prepared based on a team of allocated users or other task attributes, for example project critical path tasks, project phase, physical resource based task or subtask grouping etc.

Embodiments include the estimate range ends and width which are determined from two input subjective values. For example, in one embodiment one value indicates one end of an estimation range and the other value indicates the width of the range. The person responsible for making the estimation, the responsible person, can be instructed to choose the values to input as subjective low granularity estimates, that the responsible person has high confidence that the subtask outcome can be achieved or delivered within the estimate range. For example, the first value may be a very optimistic estimate, which the user has a high confidence in being a "best case scenario" but not beyond feasibility for execution of the subtask, for example 85-90% confident that a better result will not be achieved. The other value indicative of the width may be indicative of the other end of the range, or a multiplier "n", for example, based on the reasoning that after nominating an optimistic estimate value a pessimistic estimate may be n times the optimistic estimate. For example, 85-90% confident that a "worst case" would not be more than triple the time estimated for the "best case". This estimate input request enables users to input an intuitive "guess" estimate range, using only 2 numbers, which requires little effort to come up with but the responsible person is reasonably certain and prepared to commit to an outcome being achieved somewhere within that range. This system acknowledges that estimation of work is typically inaccurate. Further, by providing an end point and range, or two end points, it is easier for a person to consider other factors which may affect their performance during the task duration, for example state of health, concurrent workload, reliance on external deliverables and other obligation/commitments that may impact on the task execution. Variables and unknowns can be accommodated in the estimation system simply by increasing the multiplier and hence range width. 25 WI00096013 2016202813 02 May 2016

It should be appreciated that the responsible person, may be an experienced project team making estimates for tasks for which they are responsible for delivering, tasks allocated to that user. The responsible person may also make estimates on behalf of other (typically less experienced or not yet allocated) team members. The responsible person may, in some circumstances, the responsible person may be a notional "responsible person" with the estimate in fact being provided and committed to by a project team. The two estimate values are input by a user, who may be the responsible person or may be another user inputting values with input or under instruction of the responsible person.

Embodiments of the methods and systems enable estimates to be made independent of an attempt to characterise or assume a probability distribution of outcomes. From historical and empirical evidence it has been observed that, typically for professional services and in particular software development, task outcome probabilities tend to show a positively skewed distribution (an example is shown in Figure 8) with a longer tail on the right of the distribution, therefore estimation theories based around normal distributions is typically flawed. Further, the distribution can change from task to task and due to the unknowns for estimation of software projects the actual distribution cannot be predicted with any accuracy in the planning phase of a project.

The disclosed methods and the systems provide a simplified estimation method robust against varying probability distributions. Estimators which may be responsible persons are asked to make a low estimate (90% sure they cannot beat it), which compels one to consider an optimistic and probably lucky low number. Then apply a multiplier, which can be referred to as an "X factor" (a multiplication factor), from which a high end estimate can be derived. In one embodiment the system restricts the multiplier value to being an integer value. The reason an integer value is preferred for a multiplier is because prediction with better accuracy is unlikely without the benefit of hindsight. For example, it may be shown that a correct multiplier was 2.1 with the benefit of hindsight. Flowever, when trying to make predictions humans do not estimate with accuracy. In 26 WI00096013 2016202813 02 May 2016 invoking a predictive and subjective heuristic for coming up with a number, and the method does not suffer the side-effects of the illusion of accuracy and does not suffer from needing historical data. Figure 8 is an example of a skewed probability distribution indicative of likely time taken for a software project task, the low end (LE) estimate, 85% to 90% confidence a better result would not be achieved, and high end (HE) estimate, 85% to 90% confident the work can be done by this time, are easier to predict and commit to achieving than the mean, median, mode, deviation and skew of the distribution.

An advantage of the disclosed embodiments is that the estimation for a task only requires two numbers, indicative of a range without making any commitment to a "most likely" outcome within that range or assumption of a particular statistical distribution.

Empirical test evidence shows that this estimation system does not seem to suffer as badly from human factors as known previously methods. The reason that it works is that it encourages a responsible person to simultaneously consider the optimistic and pessimistic outcome and give a rating, indicative of a degree of confidence they have in their number. If it is a tight skew, it will have a low multiplier. If it is a long skew, it will have a high multiplier. Thus, a qualitative assessment of the median is provided whilst also providing a qualitative assessment of the spread. So from two numbers, the disclosed systems and methods can determine the range endpoints and width. From these values a fourth value can be calculated, which is the average of the high and the low (the standard estimate). This centre value for sub-tasks is aggregated to provide the consolidated estimate for the task.

Additionally, from empirical test evidence illustrated in Figure 9, it has been found that the standard estimate is likely to be slightly higher than the median and the mode. The empirical test evidence of the standard estimate provides a slightly more paranoid estimate, closer to the likely mean probability. 27 WI00096013 2016202813 02 May 2016

The applicant has found from test data that even for relatively small sample sizes, around 12-24 people, even though there may be high variety in optimism and pessimism between individual estimators, the aggregated consolidated estimate value has been shown to give a reasonable prediction of the task effort outcome. Test evidence indicates that projects that are estimated using the disclosed methods and systems have been shown to be much easier to bring in on time, than projects estimated using a statistical factor method. The problem with the three or four point statistical estimation methods is that people don't have the data to enable an accurate estimate, but the method provides an (unreliable) illusion of accuracy which can, in turn, lead to unrealistic expectations and frustration.

The disclosed estimation methods and systems starts from a presumption of inaccuracy and acknowledgement of subjectiveness of estimates. By asking for estimators to identify a range that they have high confidence of being able to achieve an outcome somewhere within that band, there is no requirement to specify any "most likely" outcome. The range or band is nominated based on either an optimistic or a pessimistic outcome estimate and an integer multiplier - indicative of variability of the work being estimated. Thus, the estimation values are input independent of any particular probability distribution shape or requirement to commit to any particular value within the band.

The width of the band can be indicative of how confident the estimator is to estimate the work. For example, a low value multiplier is a narrow band indicating low variability between the high and low estimates, whereas a sub-task with many unknowns may have a high multiplier value indicating low confidence in the ability to accurately estimate the required effort. By aggregating mid points of the bands for the consolidated estimates this assumes inaccuracies will "even out" in the end. This method has been found to produce much more commercially useable numbers than any other method the applicant has observed. Further the applicant has used retrospective data to identify estimators who are typically pessimistic and those who are typically optimistic and observed 28 WI00096013 2016202813 02 May 2016 that there is a normalising effect. The optimists are happy to consider the low estimate and a "risky factor", whereas the pessimists are happy to consider the high estimate and a "lucky factor".

Further, empirical evidence has shown that network effects are typically accommodated within the estimates, as the estimates are subjective and estimators can instinctively adjust estimates based on anticipated parallel or serial tasks. For example, allowing extra time between optimistic and pessimistic estimates for tasks that are likely to be worked on in parallel or have some dependency.

Examples of estimation methods and systems have been discussed above with reference to project planning, work task scheduling and tracking which typically use time based estimates. Flowever, the described estimation methods and systems may be employed for estimating values other than time, for example monetary values for professional services where deadlines may be fixed but costs dependent on the resources applied to the tasks. For example, planning deadline based services such as legal or contract services. In another example, for example for delivery or logistics planning estimates may be based on anticipated speed and distance, for example for sea or air freight enabling alternative routing and speed based on environmental factors to be accommodated for in a planning process. It should be appreciated that embodiments of the systems and methods described above may be utilised in a variety of planning and tracking systems.

The disclosed systems and methods can be retrofitted into current or existing scheduling systems making those systems more robust. Current or existing systems may have additional parameters providing computations specific to the industry in which they are applied. Utilising the same or different hardware, the disclosed systems and methods can enhance those systems as a retrofit, improving their results.

In a manufacturing environment or plant, where for example a customisation unit assembles products for specific orders, the products need to move through the manufacturing plant for assembly, and preferably do so in the most efficient and productive manner. Customisation is 29 WI00096013 2016202813 02 May 2016 common, for example, in the computer industry where a buyer orders a computer with a customised specification. In preparing for delivery of that computer, the manufacturer will build the computer for the customer. Tasks for customisation may be without an established time history.

Customisation is common in many businesses and industries where a larger task including sub-tasks or different smaller tasks may be required on short notice and where a history of the time taken for one or more of the sub-tasks is not available. While this example is related to a high tech industry, the same would hold true of any industry. One can consider the same discussion for custom furniture building, framing, construction, landscaping, and so on that may have existing scheduling systems specific to their industries.

In a manufacturing environment, while tasks can be repetitive, their initial establishment can require the time estimation as described herein. The disclosed systems and methods, for example, may be used prior to establishing a history. The history may be found to be equal to the time estimate in accordance with the disclosed systems and methods.

Many different tasks may be involved in a manufacturing process. In the example of custom computer building, the task of building a computer to specification, the sub-tasks may include fetching a component, positioning the component into a computer casing, connecting the component to other components, securing the component within the casing, moving the computer to the next assembly station, and so on. For specific customised orders as described immediately above, different combinations of previously time estimated sub-tasks may be required so the aggregation of those time estimations can be provided by the systems and methods described herein. In this way, the disclosed methods and systems can be retrofitted into existing scheduling systems, changing an existing system to having the capability to build in time estimates and the aggregation in the manner that is described herein, and ultimately, providing a robust outcome for time estimation where history is unavailable. 30 WI00096013 2016202813 02 May 2016

It may be found in some circumstances that the step of establishing a time history is not necessary when a particular scheduling system is retrofitted with the disclosed time estimation systems and methods. The robustness of the disclosed systems and methods may replace the need to monitor time to establish a historical value. A transformation of an existing scheduling system with a retrofit of the disclosed time estimation systems and methods may eliminate the need for the step of establishing a time history and replacing that with the estimated time based upon the retrofitted system.

It will be understood to persons skilled in the art that many modifications may be made without departing from the spirit and scope of the invention. It should be appreciated that in the context of the present specification the terms "module" and "component" are used to refer to a system component implementing defined functionality. The system component can be implemented as a software program executable using a processor or as a software routine integrated into a software program providing additional functionality. The system component may be equally implemented using a combination of hardware and software. The disclosed embodiments may be implemented using any suitable combination of hardware, software and firmware, and may utilise a combination of shared and dedicated data processing hardware and memory resources. For example, a dedicated hardware circuit, such as an application specific integrated circuit (ASIC) for programmable logic such as a field programmable gate array (FPGA) or programmable logic controller (PLC), may be used to implement some system functionality. This hardware circuit may be used in a data processing system having at least one processor, memory and other resources for executing cooperating firmware and software to support the full functionality of the system and integrate with external systems such as user terminals. It should be appreciated that many alternative system architectures could be used to implement the system and all such alternatives are envisaged within the scope of the present application. 31

Claims (26)

1. CLAIMS:

   1. A computer implemented method for task time estimate re-assessment in a task scheduling system, the method comprising: a. determining a remaining task time for a task which has been initiated, the task having been allocated to a resource, and determining a minimum review threshold; b. on a display, displaying a request for a confirmation by the resource of an expectation that the task will be completed within the remaining task time; c. if the confirmation is not received, displaying a request for an expected optimistic range of time from the current time that the task will be completed; d. receiving the optimistic range of time as a new value for the remaining task time; e. calculating the midpoint from the current time to the end of the new value for the remaining task time; f. storing the midpoint time; and g. determining when the midpoint time is the current time wherein the remaining time is half the new value of remaining task time, and h. repeat steps b-h to determine a revised new value for midpoint time, until the remaining task time is less than the minimum review threshold.
2. 2. The method of claim 1 further wherein the task is initiated when delivered to a task buffer.
3. 3. The method of claim 1 wherein the task time is established by an x-factor method.
4. 4. The method of claim 1 further comprising delivering the new value for the remaining task time to determine a mix of tasks for distribution to resources prior to releasing downstream tasks to a task buffer.
5. 5. The method of claim 1 further comprising delivering the midpoint time for the remaining task time to determine a mix of tasks for distribution to resources prior to releasing downstream tasks to a task buffer.
6. 6. The method of claim 1 wherein the remaining time is a midpoint of an initial task time.
7. 7. A computer implemented method for task time estimate re-assessment in a task scheduling system, the method comprising: a. determining a remaining task time for a task which has been initiated, the task having been allocated to a resource, and determining a minimum review threshold; b. on a display, displaying a request for a confirmation by the resource of an expectation that the task will be completed within the remaining task time; c. if the confirmation is not received, displaying a request for an expected optimistic range of time from the current time that the task will be completed; d. receiving the optimistic range of time as a new value for the remaining task time; e. determining a particular percentage of time from the current time to the end of the new value for the remaining task time; f. storing the particular percentage of time; and g. determining when the particular percentage of time is the current time wherein the remaining time is an amount of time related to the particular percentage of the new value of remaining task time, and h. repeat steps b-h to determine a revised new value for a particular percentage of time until the remaining task time is less than the minimum review threshold.
8. 8. The method of claim 7 further wherein the task is initiated when delivered to a task buffer.
9. 9. The method of claim 7 wherein the task time is established by an x-factor method.
10. 10. The method of claim 7 further comprising delivering the new value for the remaining task time to determine a mix of tasks for distribution to resources prior to releasing downstream tasks to a task buffer.
11. 11. The method of claim 7 further comprising delivering the midpoint time for the remaining task time to determine a mix of tasks for distribution to resources prior to releasing downstream tasks to a task buffer.
12. 12. The method of claim 7 wherein the remaining time is a midpoint of an initial task time.
13. 13. A computer implemented method for task commencement time estimate re-assessment in a task scheduling system, the method comprising: a. determining a remaining task commencement time for a task which has been initiated, the task commencement having been allocated to a resource, and determining a minimum review threshold; b. on a display, displaying a request for a confirmation by the resource of an expectation that the task will be commenced within the remaining task time; c. if the confirmation is not received, displaying a request for an expected optimistic range of time from the current time that the task will be commenced; d. receiving the optimistic range of time as a new value for the remaining task commencement time; e. determining a particular percentage of time from the current time to the end of the new value for the remaining task commencement time; f. storing the particular percentage of time; and g. determining when the particular percentage of time is the current time wherein the remaining time is an amount of time related to the particular percentage of the new value of remaining task commencement time, and h. repeat steps b-h to determine a revised new value for a particular percentage of time, until the remaining task commencement time is less than the minimum review threshold.
14. 14. A task scheduling system including a sub-system for task time estimate re-assessment, comprising: a. means for determining a remaining task time for a task which has been initiated, the task having been allocated to a resource, and determining a minimum review threshold; b. on a display, means for displaying a request for a confirmation by the resource of an expectation that the task will be completed within the remaining task time; c. if the confirmation is not received, means for displaying a request for an expected optimistic range of time from the current time that the task will be completed; d. means for receiving the optimistic range of time as a new value for the remaining task time; e. means for calculating the midpoint from the current time to the end of the new value for the remaining task time; f. means for storing the midpoint time; and g. means for determining when the midpoint time is the current time wherein the remaining time is half the new value of remaining task time, and h. means for repeating processes of b-h to determine a revised new value for midpoint time, until the remaining task time is less than the minimum review threshold.
15. 15. The system of claim 14 further wherein the task is initiated when delivered to a task buffer.
16. 16. The system of claim 14 wherein the task time is established by an x-factor method.
17. 17. The system of claim 14 further comprising delivering the percentage relating to the particular percentage of time as the new value for the remaining task time to determine a mix of tasks for distribution to resources prior to releasing downstream tasks to a task buffer.
18. 18. The system of claim 14 further comprising delivering the midpoint time for the remaining task time to determine a mix of tasks for distribution to resources prior to releasing downstream tasks to a task buffer.
19. 19. The system of claim 14 wherein the remaining time is a midpoint of an initial task time.
20. 20. A task scheduling system including a sub-system for task time estimate re-assessment, comprising: a. means for determining a remaining task time for a task which has been initiated, the task having been allocated to a resource, and determining a minimum review threshold; b. on a display, means for displaying a request for a confirmation by the resource of an expectation that the task will be completed within the remaining task time; c. if the confirmation is not received, means for displaying a request for an expected optimistic range of time from the current time that the task will be completed; d. means for receiving the optimistic range of time as a new value for the remaining task time; e. means for determining a particular percentage of time from the current time to the end of the new value for the remaining task time; f. means for storing the particular percentage of time; and g. means for determining when the particular percentage of time is the current time wherein the remaining time is an amount of time related to the particular percentage of the new value of remaining task time, and h. means for repeating processes of b-h to determine a revised new value for a particular percentage of time, until the remaining task time is less than the minimum review threshold.
21. 21. The system of claim 20 further wherein the task is initiated when delivered to a task buffer.
22. 22. The system of claim 20 wherein the task time is established by an x-factor method.
23. 23. The system of claim 20 further comprising means for delivering the new value for the remaining task time to determine a mix of tasks for distribution to resources prior to releasing downstream tasks to a task buffer.
24. 24. The system of claim 20 further comprising means for delivering the percentage relating to the particular percentage of time as the remaining task time to determine a mix of tasks for distribution to resources prior to releasing downstream tasks to a task buffer.
25. 25. The system of claim 20 wherein the remaining time is a midpoint of an initial task time.
26. 26. A task scheduling system including a sub-system for task commencement time estimate reassessment, comprising: a. means for determining a remaining task commencement time for a task which has been initiated, the task commencement having been allocated to a resource, and determining a minimum review threshold; b. on a display, means for displaying a request for a confirmation by the resource of an expectation that the task will be commenced within the remaining task time; c. if the confirmation is not received, means for displaying a request for an expected optimistic range of time from the current time that the task will be commenced; d. means for receiving the optimistic range of time as a new value for the remaining task commencement time; e. means for determining a particular percentage of time from the current time to the end of the new value for the remaining task commencement time; f. means for storing the particular percentage of time; and g. means for determining when the particular percentage of time is the current time wherein the remaining time is an amount of time related to the particular percentage of the new value of remaining task commencement time, and h. means for repeating processes b-h to determine a revised new value for a particular percentage of time, until the remaining task commencement time is less than the minimum review threshold.