PRODUCTIVITY THROUGH AUTOMATED WORK BALANCING

Methods and systems for scheduling include comparing a time commitment for a scheduling request, belonging to a scheduling category, to a difference between an invitee's existing time commitments for the scheduling category and a maximum time limit for the scheduling category. The scheduling request is entered if a sum of the time commitment for the scheduling request and the invitee's existing time commitments for the scheduling category falls below the maximum time limit. The scheduling request is entered if the scheduling request matches one or more override rules.

BACKGROUND

Technical Field

The present invention relates to workload balancing and, more particularly, to meeting scheduling.

Description of the Related Art

In many large companies, a significant amount of employee time is spent in meetings, leaving little time for actual work during the day. As a result, many workers end up working after hours or over the weekends to complete their tasks. The requester of the meeting may not be aware of already-committed workloads for people being invited to attend the meetings, which may be especially problematic for workers who are expected to bill a certain number of billable hours per week.

This reflects a modern-day tragedy of the commons, referring to an economic theory in which individuals, acting independently and rationally according to each one's self-interest, behaves contrary to the whole group's long-term best interests by depleting some common resource. In this case, the common resource is time, and an overabundance of meetings cuts sharply into the amount of man-hours available to the company for productive work.

Existing solutions to this problem include individuals blocking out a set number of hours on their calendar for meetings. However, this may decrease the overall productivity of teams for the benefit of individual productivity if it makes the person inaccessible. This can be a particularly difficult problem in globally distributed teams. Another option is for an individual to decline the meeting invitation, which may make the individual appear rude to co-workers and management.

SUMMARY

A method for scheduling includes comparing a time commitment for a scheduling request, belonging to a scheduling category, to a difference between an invitee's existing time commitments for the scheduling category and a maximum time limit for the scheduling category. The scheduling request is entered if a sum of the time commitment for the scheduling request and the invitee's existing time commitments for the scheduling category falls below the maximum time limit. The scheduling request is entered if the scheduling request matches one or more override rules.

A method for scheduling includes comparing a time commitment for a scheduling request to a difference between an invitee's existing time commitments for a scheduling category that includes the scheduling request and a maximum time limit for the scheduling category. The scheduling request is entered if a sum of the time commitment for the scheduling request and the invitee's existing time commitments for the scheduling category falls below the maximum time limit. The scheduling request is entered if the scheduling request matches one or more override rules. The override rules include a rule that enters scheduling requests that come from external users that are external to the invitee's organization, a rule that enters scheduling requests that come from a member of a group shared by the invitee, a rule that enters scheduling requests that come from an executive or other person of authority in the invitee's organization, and a rule that enters scheduling requests that are marked as being urgent.

DETAILED DESCRIPTION

Embodiments of the present invention allow invitees (alternatively called “users” herein) to set a limit for the number of hours per week to be allocated to meetings. The user can further configure the settings to override the limit when the meeting request is from important stakeholders, such as clients, or when meeting requests are related to billable work. In this manner, the user can increase the number of hours available for productive work, while still being responsive to meeting requests that have a high importance.

The present embodiments may be integrated with existing scheduling software, for example through the use of a plugin. It is particularly contemplated that the present embodiments may be implemented as a software module using a portable programming language. The present embodiments allow a user to improve their productivity and work-life balance by setting a limit on meetings that are not directly related to currently committed deliverables. This process is performed automatically, according to pre-set priorities, allowing a user to filter meeting requests automatically. When a meeting request passes through the filter, either because there are sufficient unallocated hours for it, or because it matches one or more override criteria, the user is given the option of accepting or declining the request manually.

Referring now toFIG. 1, a method for scheduling a meeting is shown. Block102receives a meeting request for the user. The request may come from a co-worker, a boss, any other third party, or even from the user themselves. Block104determines whether the request would put the user over their limit for meetings. The limit in this case may represent a set number of hours allocated for meetings in a week, a percentage of the week to be so allocated, a set number of meetings, or some other threshold meant to place a limit on how much time the user spends in meetings relative to more directly productive types of work. It should be noted that the meeting request may also be categorized according to a meeting type, and so there may be multiple limits pertaining to different meeting types. For example, meetings with clients may have more time allotted to them in a week than meetings with co-workers. If the request does not put the user over their limit, block106enters the meeting request and presents the request to the user for a decision as to whether to accept or decline the request.

Otherwise, block108determines whether the request triggers an override. The overrides are a set of user-configurable rules that determine whether a request will be allowed despite running over a user's limit. The overrides thereby provide a way to prioritize important meeting requests, so that they do not get ignored accidentally. The overrides may include one or more of the following rules:

1. Internal vs. external rule. This rule determines whether the meeting requester is internal or external to the company. One way of accomplishing this would be to compare a domain name of the requester to a list of approved internal addresses. External requests are more likely to be from clients, for example, and therefore more likely to be high-priority requests. Implementing this rule would therefore override the limit to allow the user to accept or reject the request.

2. Group rule. The user can create specific groups of users that will have override capability. In one example, these groups might represent teams or committees that the user belongs to, where meeting requests from such people are more likely to be particularly relevant to the user or to be directly related to the user's productivity. In this case, members of the same team would then be able to issue meeting requests that exceed the user's limits.

3. Executive rule. If the meeting request is from an executive of the user's company, the invitee's supervisor, or other person of authority, then an override may be triggered so that the user may personally review requests they will be held accountable for.

4. Urgency rule. If the meeting request is marked urgent, then an override may be triggered. An urgency rule may furthermore be configured with exceptions for particular parties in the event that the user receives many invitations from some party that are needlessly marked as being urgent.

5. Customizable rules. Users may have the ability to develop override rules of their own based on a wide variety of conditions or combinations of conditions. For example, the user might select one or more customizable conditions (e.g., a source country for a request) and set parameters that determine when the condition is triggered (e.g., allow overrides for meeting requests from China). These conditions may also include temporal conditions, relating to a time of day, week, or month that the request is for, geographic conditions (e.g., where the meeting is to be located), conditions relating to the type of meeting (e.g., in-person versus teleconference), and so on. Through a combination of such conditions, the user has substantial flexibility in controlling the portion of their time spent in meetings.

If the request triggers an override, block106enters the meeting request to go to the user for personal review. If not, block110declines the meeting request using, for example, a standard template or form message. The user may have the option of personalizing the automated message for block110and may use more than one template in accordance with one or more criteria.

Referring now toFIG. 2, a scheduling system200is shown. The system200includes a processor202and memory204. The processor202is a hardware processor, and it is contemplated that one or more software modules may be stored in memory204and may be executed using the processor202. Alternatively, the modules may be implemented as hardware in the form of, e.g., an application-specific integrated chip or a field-programmable gate array. The memory204stores a user profile206which includes the user's scheduling information. The scheduling information may include, for example, a calendar that represents existing commitments as well as a user-settable time limit for meetings in one or more categories. The memory204also includes one or more override rules208that provide conditions under which a scheduling request may override a user's time limit for meetings.

A scheduling module210then accepts new scheduling requests and determines whether to allow them to pass to the user for review or to deny them based on the user's time limit, the user's existing commitments, and the override rules208. The scheduling module210may be, for example, a plugin to an existing mail client or groupware application that provides the above functionality on an existing calendar system, or alternatively the scheduling module210can be a standalone application configured to manage users' calendars. The scheduling module210determines whether or not to present a given request to the user. If the scheduling module210determines that the request should be declined, it automatically declines the request in accordance with settings stored in the user profile206. A user interface212allows the user to make changes to the user profile206and override rules208and furthermore allows the user to make direct decisions as to whether to accept or decline a scheduling request that has made it through the scheduling module210. The user interface212may be local to the scheduling system200or may be on a separate device that accesses the scheduling system through a network.

Referring now toFIG. 3, a block/flow diagram of an overview of the present principles is provided. Block302blocks an incoming meeting request if it exceeds a number of hours that a user has allotted for meetings (or a number of such hours remaining). Block304then overrides the block if the request meets one or more rules as described above.