Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q10/00—Administration; Management
  • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q10/00—Administration; Management
  • G06Q10/10—Office automation; Time management
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
  • H04L63/029—Firewall traversal, e.g. tunnelling or, creating pinholes
• • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
  • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
  • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
  • Y10S707/00—Data processing: database and file management or data structures
  • Y10S707/99931—Database or file accessing
  • Y10S707/99933—Query processing, i.e. searching

Definitions

• the present invention relates to computer-implemented systems and methods for project management. More particularly, the present invention relates to improved computer- implemented techniques for facilitating collaborative project development and communication among the project participants.
• a manager in automobile company X may need to track the delivery of cast cylinders (in terms of quality, quantity, delivery date, or the like) from supplier Y. That manager may also need to set up a schedule to ship the cast cylinders received from supplier Y to honing contractor Z for honing. To ensure that the shipment of cast cylinders was not lost after being shipped out to contractor Z, that manager may also need to set up a separate schedule to confirm, perhaps a few days after shipping, that honing contractor Z had indeed received the cast cylinders.
• Automobile company X may wish to grant supplier Y access to the project management software, or at least to some portion of it, so that supplier Y can tick off its own action item (e.g., shipping a quantity of cast cylinders to automobile company X on a certain date). Such access by supplier X is beneficial since an employee in automobile company X may wish to be notified of the shipment in order to ready the quality control group for inspecting the incoming cast cylinders and/or to notify honing contractor Z of the upcoming honing order.
• supplier Y may wish to grant supplier Y access to the project management software, or at least to some portion of it, so that supplier Y can tick off its own action item (e.g., shipping a quantity of cast cylinders to automobile company X on a certain date).
• Such access by supplier X is beneficial since an employee in automobile company X may wish to be notified of the shipment in order to ready the quality control group for inspecting the incoming cast cylinders and/or to notify honing contractor Z of the upcoming ho
• automobile company X may also wish to grant honing contractor Z access to the project management software, or at least some portion of it, so that honing contractor Z can receive information pertaining to when and how many of the cast cylinders were actually shipped to him from automobile company X so that contractor Z can more efficiently manage its resources to service the honing order (such as to arrange to rent honing equipment in anticipation of the arrival of the cast cylinders).
• honing contractor Z would also benefit automobile company X since honing contractor Z may in turn be able to use the project management software to notify the interested employees within automobile company X of the honing progress, whether and when the honed cylinders were shipped back to automobile company X, and so forth.
• Honing contractor Z may also want to have the ability to inform to automobile company X, or the employees of automobile company X that are interested in the honing process, that it has perfected a new honing technique and may be able to hone to a closer tolerance if automobile company X can extend the deadline for the delivery of honed cylinders by a few weeks. All these communications are preferably implemented in a single software package to facilitate record keeping and integration with progress tracking.
• a scenario is very simplistic.
• a project In the real world, it is not uncommon for a project to require dozens or hundreds of geographically remote participants, each contributing to a portion of the project at various time periods, and many of whom need to work and communicate collaboratively if the project is to be completed timely and efficiently.
• software programs that may be employed for project management.
• Gantt charts in either the hardcopy version or the software version, have long been employed by project managers to track tasks and dates relevant to a particular project.
• Fig. 1 illustrates a Gantt chart 100, including thereon bars representing tasks and deadlines.
• Gantt chart 100 Although only a few tasks are shown on Gantt chart 100, it should be kept in mind that the example has been vastly simplified to facilitate discussion. In reality, a typical real world Gantt chart may involve thousands or tens of thousands of tasks and may very well fill an entire wall, or even more, if displayed on paper.
• bars 102 and 104 represent the major tasks that need to be undertaken.
• Bar 102 may represent, for example, the cylinder development phase
• bar 104 may represent, for example, the engine assembly phase.
• a dependency line 106 connects the end of bar 102 to the beginning of bar 104, signifying the fact that cylinder development has to be completed before engine assembly can begin.
• a milestone 108 marks the completion of the engine assembly phase.
• a major task such as cylinder development may be subdivided into subtasks.
• Gantt chart 100 tracks these subtasks by the use of subtask bars, such as bars 112 and 114 under cylinder development task bar 102.
• Bar 112 may represent, for example, the subtask of obtaining cast cylinders
• bar 114 may represent, for example, the subtask of getting the cylinders honed.
• Subtasks may also have relationships, one of which is illustrated in Fig. 1 by a dependency line 116.
• Dependency line 116 connects the end of bar 112 to the beginning of bar 114, signifying that cylinder honing can not begin until after the cylinders are casted.
• Gantt charts both on paper and in their software versions, have been employed successfully in bringing many projects to completion, there are disadvantages.
• one of the weaknesses of the traditional Gantt chart approach is the inability to allow a project participant to easily filter through the voluminous data related to a project in order to focus in only on data and/or deadlines that are relevant to that particular user in a specified time period.
• an employee of automobile company X who are involved in or interacting with multiple departments (e.g., cylinder development, clutch ordering, paint testing, etc.).
• the traditional Gantt chart approach does not allow this employee to easily find out, for example, what action items he needs to take on a specified day or a specified week across the multiple departments involved.
• a Gantt chart typically deals with only tasks (and subtasks), the task commencement dates, and deadlines.
• tasks and subtasks
• deadlines During a project, they are many times when a project participant needs to communicate different types of information, other than tasks and dates, with other project participants.
• a project participant may wish to employ the project management software to communicate to those interested that a new piston design has been selected and also include a drawing of the newly designed piston in the communication.
• the redesign of the piston may impact those in cylinder design (including our supplier Y and honing contractor Z).
• the typical Gantt chart does not provide a facility to allow project participants interested in or impacted by the piston design change to be alerted of this fact, to view the new piston design, to determine how their own delivery schedule may be impacted, and to communicate their concerns with other project participants (e.g., the manager in charge of engine assembly, who depends on timely delivery of finished components to perform his job).
• project participants e.g., the manager in charge of engine assembly, who depends on timely delivery of finished components to perform his job.
• project participants must switch to other communication modalities outside of the project management software environment to communicate, e.g., switch to email, phone, facsimile, or the like. When that happens, it becomes very difficult to centralize record keeping of the communications and/or integrate the communications with progress tracking.
• the typical Gantt chart does not readily provide a way for a project participant to track the actual performance on a particular task (e.g., the number of cylinders actually honed) and compare the actual performance with the expectation in order to generate a notification or an alert.
• a data item is modified (such as when the piston design is changed).
• Typical collaborative Gantt charts also lack the aforementioned annotation capability, making it difficult for project participants to communicate the reasons or explanation behind the data.
• Collaborative spreadsheets represent another class of software programs that have been employed to facilitate collaborative project development.
• the data pertaining to the items to be tracked are stored in cells, which are arranged in a matrix arrangement and are accessible to the project members.
• Collaborative spreadsheets also have disadvantages.
• the typical collaborative spreadsheet also does not readily provide a way for a project participant to filter through vast amount of data in order to focus in on items, data, or dates that are relevant to that particular project participant.
• the cell structure is fairly limiting in that each cell typically tracks only one value of one type of data (e.g., text, number, date, and the like). If a trackable event involves multiple values that need to be monitored simultaneously (e.g., both date and quantity), the cell of a typical collaborative spreadsheet does not accommodate such a requirement well.
• a typical collaborative spreadsheet cell also lacks the ability to track the change in the cell's value over time.
• the delivery date of the honed cylinders may be revised many times during the project, due to problems encountered by honing contractor Z or due to events outside of his control (such as late receiving of the raw cast cylinders).
• the cylinder development manager Unless a history is kept of the change, it would be difficult for the cylinder development manager to go back in time to audit the changes and find out when the date was changed, by whom, and perhaps why.
• the matrix-like architecture of a typical spreadsheet makes it difficult to partition groups of cells to implement access control.
• a collaborative project management environment based on computer-implemented constructs known as trackpoints, whose flexible construct permits substantially any type of trackable item or communication to be stored therein.
• a trackpoint can simultaneously track multiple attributes and functions that employ attributes as arguments, can be annotated with multimedia content, and can be represented by metadata (which is descriptive of the trackpoint, its genesis, and/or its evolution) for indexing and searching purposes.
• a trackpoint can also explicitly or implicitly reference other trackpoints, thereby facilitating the establishment of arbitrary project teams from the common database of trackpoints pertaining to the project.
• a project participant can author (i.e., create or modify) a trackpoint, can freely and efficiently search for data that is of particular interest to that project participant, can send and/or receive communication through text, drawings, annotations, markups on text/graphics, multimedia content, and other types of data, and can even request to be notified upon the occurrence of certain events.
• the project participant can advantageously create a customized and/or filtered view that focuses in only on the data relevant to that user, irrespective of whether that data comes from a single trackpoint, from multiple trackpoints, or even multiple trackpoints that are created at different times and by different functional groups of the project.
• Fig. 1 illustrates a typical Gantt chart to facilitate discussion of some of the challenges that exist in the management of projects.
• Fig. 2 is a simplified diagram illustrating the architecture of the inventive trackpoint- based collaborative project management and communication software.
• Fig. 3 illustrates an implementation of the inventive trackpoint-based collaborative project development and communication system that involves the internet.
• Fig. 4 is a conceptual depiction of the various kinds of components that a trackpoint may have.
• Fig. 5 depicts an exemplary interest profile, representing a tool that may be provided to the project participant to facilitate data sharing, communication, and collaboration.
• Fig. 6 depicts an exemplary briefing book page, representing another tool that may be provided to the project participant to facilitate data sharing, communication, and collaboration.
• Fig. 2 is a simplified diagram illustrating the architecture of the inventive collaborative project management and communication software 200, in accordance with one embodiment of the present invention.
• a trackpoint database 202 represents the database containing the collection of trackpoints pertaining to a particular project.
• Trackpoint database 202 may be implemented in according with any conventional database technology, and may be implemented in accordance with a relational database methodology.
• the invention also applies even when trackpoint database 202 is implemented simply as an unstructured collection of trackpoints, managed in files, for example.
• trackpoint database 202 there are shown trackpoints 204, 206, 208, 210, 212, and 214, representing some of the trackpoints created by the project participants to facilitate tracking events/items pertaining to the project and to communicate with one another. Although only six trackpoints are shown to simplify the discussion, it should be borne in mind that there may be any number of trackpoints in a project.
• the trackpoints may reference one another, as shown conceptually by exemplary lines 216, 218, 220, and 222. Trackpoint structure and trackpoint referencing will be discussed in detail later herein.
• an authoring tool 230 may be provided to allow a project participant to create a new trackpoint or to modify an existing trackpoint.
• Authoring tool 230 may be implemented in any manner suitable for creating a trackpoint or changing its attributes/links/metadata and for storing that trackpoint in trackpoint database 202.
• authoring tool 230 is implemented using object-oriented technology in which the project participant fills in the trackpoint's metadata, selects the links, selects the attribute fields of interest, and fills in the trackpoint's attributes as if he is creating and filling in a form.
• a searching tool 232 may also be provided.
• Searching tool 232 permits a project participant to search through the trackpoints in trackpoint database 202 by specifying a set of search criteria.
• the search criteria may relate to one or more attributes of the trackpoints, the links that reference trackpoints among themselves, or the metadata that describes a trackpoint.
• a notification tool 234 permits a project participant to request that he be notified when a certain notification criteria is satisfied.
• the notification criteria like the search criteria, may relate to one or more attributes of the trackpoints, the links that reference trackpoints among themselves, or the metadata that describes a trackpoint.
• a project participant can also specify that he be notified upon the creation of a trackpoint whose metadata, links, or attributes satisfy some set of notification criteria since the creation of a trackpoint itself may be an event of interest to a project participant.
• a customized filtering and viewing tool referred herein as a briefing book page, may also be provided.
• the briefing book page (236) represents, in one embodiment, a custom viewing panel with which a project participant may select and view only the attributes and data that are of interest to that participant.
• the attributes and data may be obtained from one or more trackpoints or even from other briefing book pages.
• data presentation techniques e.g., graphs, mathematical operations, warning lights, gauges, timelines, or the like
• the preselected data may be presented in the format that is most preferred or most appropriate.
• the trackpoint-based architecture of the inventive collaborative project development and communication software does not impose any limitation on the tools that may be created and employed by the project participants.
• the simplicity and flexibility of the architecture illustrated in Fig. 2 allows a project participant to create and/or employ any tool that can take advantage of the rich set of attributes of the trackpoints, the metadata provided with the trackpoints, and the annotation capabilities of the trackpoints in order to facilitate communication, data analysis, and collaboration on the project.
• the inventive collaborative project development and communication system may be implemented on any computer network, including proprietary private networks, virtual private networks (VPNs), or over public networks such as the internet.
• Fig. 3 illustrates an implementation of the inventive trackpoint-based collaborative project development and communication system that involves the internet. With reference to Fig.
• a collaborative project development and communication system 300 includes a data repository 302, which includes the trackpoint database as well as indexed databases (of any sort, e.g., relational object, file-based, etc.) supportive thereof.
• the indexed databases implement the indexing of trackpoints using various index keys.
• the various fields of the trackpoint metadata are employed as index keys to create indices. Project participants may search through the indices to identify the trackpoint(s) of interest prior to accessing the trackpoint content.
• Data repository 302 is accessed by a server computer 304, whose processor services access, search, data retrieval, data storage, and other requests issued by the project participants through client computers, of which client computers 306 and 308 are shown.
• server-client architecture is well known and will not be discussed in great detail here for brevity's sake. Although only two client computers are shown, any number of client computers may be involved, depending on the size of the project.
• a security firewall may be provided between server 304 and computer network 310.
• a commonly owned co-pending US patent application entitled “Techniques For Improving Index Searches In A Client-Server Environment,” filed on even date by Eugene E. Bouchard, Varma Kunaparaju, and John Page (and incorporated herein by reference) discusses in detail some exemplary techniques for improving the efficiency of index searching in a client- server network.
• Optional security firewalls 314 and 316 may also be provided to safeguard access to client computers 306 and 308 respectively.
• FIG. 4 is a conceptual depiction of the various kinds of components that a trackpoint may have. Although many different components are conceptually depicted in Fig. 4 to facilitate discussion, it should be kept in mind that the specific metadata fields, attributes, links, and annotations shown in Fig. 4 are only exemplary and not limiting of the scope of the present invention.
• a trackpoint may be represented by metadata, which describes the trackpoint as a whole.
• the metadata 402 may include, for example, a unique trackpoint ID (which is a unique number assigned by the server computer for the purpose of uniquely identifying the trackpoint), author, date of trackpoint creation, date of last revision (of any of the components of the trackpoint and/or of the trackpoint definition).
• the metadata may also include keywords, subject, abstract, and other descriptive and/or bibliographic data pertaining to the trackpoint.
• a project participant may search for a trackpoint of interest using many different search techniques.
• a project participant may conduct full searches through the attribute values of all the trackpoints in the trackpoint database to identify the trackpoint(s) of interest.
• the project participant may conduct a search through the content of all trackpoints to identify any trackpoint whose content includes the words "honing contractor Z.”.
• a project participant may conduct searches through the content of all trackpoints to identify trackpoint(s) of interest by their links (e.g., by link type, link origination and/or link termination).
• the metadata furnishes the project participants with yet another way to search for trackpoint(s) of interest.
• a project participants may, for example, search for trackpoints created by a specific author, trackpoints having some specified keywords or subjects, and/or trackpoints that were revised before or after a certain date.
• search methodologies that are current state of the art, including the use of Boolean operators and/or employing a natural language searching technology.
• the metadata may be indexed against the trackpoints in advance by the server. That is, the server computer may create in advance indices that index particular search keys (e.g., keyword or author) against the identity of the trackpoints. These indices may be updated upon trackpoint creation or upon subsequent trackpoint updates. Thus a project participant may quickly search through the indices to determine, for example, that trackpoints 206 and 212 contain the keyword "piston" without having to undertake a more time- consuming search through the content trackpoints.
• search keys e.g., keyword or author
• the metadata for a particular trackpoint may be entered by the project participant upon trackpoint creation or by user modification or may be automatically updated when the trackpoint is created (or modified).
• the date of last revision field of the metadata may be automatically entered from the computer system's clock when the attribute values, the metadata, and/or the definition of the trackpoint is changed.
• Each trackpoint may have any number of attributes 404 to enable it to track the various pieces of information relating to a particular trackable item or trackable event. It is not necessary or even required that two trackpoints have the same attribute set since different trackpoints may be employed to track different kinds of trackable items or events.
• the attributes of a trackpoint may include, for example, the due date (both expected and actual), status, quantity (both expected and actual), the identity of the person performing the task, and the like.
• the data type of an attribute may be dates, numbers, boolean, typed data, or any other types of data structures that may be employed to store information.
• a trackpoint set up by the honing contractor for tracking the status of a cylinder honing order may involve an attribute for the status itself (e.g., on schedule, behind_schedule, not_started, ahead of schedule, and the like), an attribute for the number of cylinders expected to be completed by the end of the day, an attribute for the number of cylinders actually finished by the end of the day, and an attribute for the estimated completion date, etc.).
• a simple trackpoint may have a single attribute field that is text (e.g., in the case of a trackpoint that is employed to provide explanation for another trackpoint that references it).
• the values of the attributes of a trackpoint may be entered manually via user entry, may be derived by the use of a mathematical function (whose arguments may include constants or other attributes within the same trackpoint or within other trackpoints). In the latter case, a project participant may set up a function for sending a notification or warning if certain conditions are met (e.g., if the actual number of cylinders received is smaller than the number of cylinders expected).
• An exemplary function is shown by reference number 406 in Fig. 4 in which one of arguments of the function (e.g., cylinder_quality) comes from another trackpoint and two of the arguments comes from the same trackpoint.
• a history of the values of each attribute are maintained to allow examination of trends. The history can be explored manually, or can be used in trigger conditions, for example, to provide a warning only when certain adverse trends are present. An example may be when an anticipated completion date has slipped more than twice.
• the value of an attribute may be obtained by the use of a data sensor.
• a data sensor is a piece of software code attached to an attribute that polls or interrogates other trackpoints or external data stores (irrespective whether the data store poled is associated with the project management software program) to obtain data to fill out the value of that attribute.
• the "cylinders_completed_today" attribute value may be automatically updated when a data sensor attached to that attribute polls the production database (e.g., a data store associated with the computer-controlled honing machines) or polls another trackpoint that has been set up to track production specifically .
• the sensor can be activated periodically or upon the occurrence of a certain triggering activity or event.
• the triggering activity or event may be, for example, the fact that someone wants to use or view the attribute value associated with the data sensor or any other arbitrarily defined activity or event.
• Activator code may also be attached to an attribute field.
• the activator code may specify, for example, that if the attribute value meets a certain criteria, some predefined action would take place.
• activation code may be attached to the
• Security classification is an attribute that provides a mechanism for restricting trackpoint access.
• individual trackpoints and project participants may be assigned security classifications in order to allow a project manager to limit a particular project participant's access to the pool of trackpoints available in the trackpoint database.
• security classifications By appropriately assigning the security classifications to the trackpoints and project participants, a project participant may be limited only to trackpoints within the assigned security container and will not have access (or typically will not even know) of trackpoints for which authorized access is not granted.
• the security classification attribute of trackpoint 400 is indicated by reference number 412.
• each project participant may be assigned a security classification. If a project participant attempts to search for or access trackpoints to which he has no authorized access, those trackpoints (either all or part of their content) will not be returned in the search result and/or that project participant will not have viewing, updating, or referencing privilege relative to the restricted trackpoint(s).
• supplier Y When supplier Y is not included, supplier Y is precluded from make entries, through the project management software, of data which may be useful to other project participants. With the aforementioned security feature in place, supplier Y now can be granted a security classification which allows supplier Y access to only certain trackpoints dealing with cast cylinders ordered from supplier Y, and supplier Y is free to update such trackpoints to inform interested employees of automobile company X of its progress.
• a trackpoint or briefing book page references trackpoints or briefing book pages which the user has no permission
• several reasonable policies may be employed according to the preference of the implementator.
• the implementator may allow information may be presented since this approach allows a tracking point to be used to summarize and sanitize more private internal information for external consumption. For example, it may be fine to let a honing supplier know the total number of cylinders which are scheduled at any one time, but not provide information about the distribution of those cylinders over a set of casting suppliers.
• a history may be kept for some or all attributes of a particular trackpoint. This option may, for example, be specified by the project participant for each attribute field when creating or modifying the trackpoint.
• a history for the attribute "cylinders_fmished_today" is depicted conceptually by table 430 of Fig. 4A.
• the change over time in the value of an attribute may be documented by time- stamping either the old or new attribute value at the time of change, by noting the person changing the attribute value, or the like. If the attribute value is automatically obtained via a data sensor, there may be no person responsible but documenting the change via timestamping is still possible.
• the history of an attribute may include textual explanation of why the value was changed. This textual explanation may be entered by the person causing the change, for example.
• the invention makes it possible for a project participant to audit a particular attribute and perhaps spot problems or trends in ways that are not possible in the absence of a historical record.
• the availability of a historical record that details changes in the attribute's value also gives project participants confidence in the data present in a trackpoint. Without such a historical record, this confidence may be lacking, especially if it is known that many people have access to the attribute under consideration. This is because without an attribute history, a project participant can never be certain whether the value in a trackpoint attribute field is indeed valid (i.e., has not been inadvertently or fraudulently modified by someone having write access to the trackpoint).
• the attribute history permits a project participant to readily verify the timing of any change, and optionally the identity of the person causing the change, should there be any question.
• Trackpoint relationships may be accomplished by the reference mechanism.
• the relationships between trackpoints may be implicitly or explicitly defined.
• a trackpoint may be implicitly referenced by another trackpoint if the later trackpoint has a function that employs as an argument an attribute value tracked in the earlier trackpoint.
• each trackpoint may have one or more links, which are typed data, explicitly specifying its relationship to the other trackpoint being referenced. There is no limit to the number of links that a trackpoint may have.
• links can furnish a search key to allow a project participant to search for trackpoints based on the type of link, the origination or termination of a specified link, or the like.
• An exemplary link is illustrated in Fig. 4 by reference number 408.
• a link may establish, for example, a formal time dependency between two trackpoints whereby a project participant explicitly specifies that the commencement of the task tracked by a given trackpoint depends on the completion of another task tracked by another trackpoint.
• Another type of formal relationship between trackpoints may be cause-and-effect.
• Other types of relationships may also be possible.
• a project participant can link a given trackpoint A to a trackpoint B, which contains textual material that documents or explains some aspect of trackpoint A.
• Trackpoint referencing permits project participants to flexibly and easily establish impromptu working groups, join an existing one for the purpose of receiving or sending communication, or simply take advantage of the data existing in other trackpoints for one's own use. Since a trackpoint can reference to or be referenced by many trackpoints, there is substantially no limit to the flexibility with which the project participants can be organized for the purpose of exchanging information and/or work collaborative on the tasks and subtasks of the projects.
• a trackpoint may also offer an annotation capability, which permits multimedia content to be attached to a trackpoint.
• an exemplary annotation button 410 is depicted.
• the specification of the piston may be attached to a trackpoint employed to track piston ordering to provide to the project participant responsible for receiving the pistons a readily accessible way to verify whether the pistons received conform to the specification.
• a trackpoint may also be provided with one or more text or graphics areas in which comments, explanations, or other useful information may be posted.
• One such text area is indicated in Fig. 4 by reference number 412.
• a plurality of tools may be provided to allow project participants to take advantage of the trackpoints.
• authoring tools for creating and or modifying trackpoints have been discussed in connection with Fig. 3 hereinabove.
• Another tool that may be provided is a notification tool or an interest profile.
• a notification tool a project participant may request that a notification be received when certain notification criteria are met.
• a project participant may request that a notification be sent to the project participant if the attribute value(s) of a specified trackpoint or groups of specified trackpoints meet some notification criteria.
• the notification criteria may include a function based on attribute values.
• the notification criteria may be based on the values of the metadata or may be link-based, e.g., based on the type of link, the destination or origination of a link.
• Exemplary notification criteria are depicted in Fig. 5 wherein the project participant may select various notification criteria of interest (502) and filling out their values within an interest profile 504.
• the notification itself may take any form, including electronic notification through the project management software itself, through email, page, phone, facsimile, or the like.
• a project participant may not only specify that the notification be sent when any of the existing trackpoint or trackpoints meet the notification criteria, but may also specify that he be notified upon the creation of a trackpoint that meets the specified notification criteria (since the creation of such a trackpoint itself may represent an event that the project participant may be interested in).
• an engine assembly manager may specify an interest profile (i.e., a notification criteria) that he be notified whenever a trackpoint having to do with engine component is created.
• Any project participant may specify, through an interest profile, to be notified when an event of interest is recorded in one of the trackpoints. Since there is no limit to the type of data that may be stored in a trackpoint, a given project participant may publish information in a trackpoint and be assured that the published information is accessible by project participants who have set up an interest profile to monitor for trackpoints containing such information. Of course, communication may also be accomplished in other ways using the inventive trackpoint-based project management software.
• a customized filtering and viewing tool known as a briefing book page, which allows the project participant to filter through the massive volume of data contained in the trackpoints associated with a project and to generate a view that allows that project participant to quickly focus in only on the data specified to be of interest to that project participant.
• a briefing book page may be personal to a particular project participant, or may be set up for sharing, with or without access control.
• briefing book pages 602, 604, and 606 each of which represents a customized viewing panel
• a briefing book page allows a project participant to filter through the data contained in trackpoints 204-214 within trackpoint database 202 and/or from other briefing book pages to present only data of interest to the project participant in the format preferred.
• a briefing book page may contain functions that employ trackpoint attributes as their arguments.
• a project participant may create a function to monitor the number of cast cylinders delivered from a supplier and the expected number and generate a warning if the number of cast cylinders received falls short of expectation.
• a project participant may wish to plot out the rate of rejection of honed cylinders for various honing contractors (the data for which may come from multiple trackpoints created by quality control personnel) versus the price charged (the data for which may come from other trackpoints created by accounting personnel) in order to select the best price point for getting the cylinders honed.
• any form of data presentation may be employed (e.g., text, graphs, gauges, warning lights, icons, or the like) to present the selected data or the result derived from the selected data in the format preferred by that project participant.
• Briefing book pages may be multi-level. With reference to Fig. 6, briefing book pages
• briefing book page 604 and 606 represent briefing book pages that obtain their data directly from the trackpoints whereas briefing book page 602 represents a briefing book page that depends on other briefing book pages for its data.
• a function or graph in briefing book page 602 may reference the value calculated by a function in briefing book page 604 and/or briefing book page 606.
• briefing book page 604 may represent a briefing book page that tracks the overall progress of piston development
• briefing book page 606 may represent a briefing book page that tracks the overall progress of cylinder development
• briefing book page 602 may represent a briefing book page that tracks the overall progress of engine development based on the progress of piston development and cylinder development.
• a properly authorized project participant may be able to take advantage of the work done by others in existing briefing book pages and create an even higher level of data abstraction to help that manager focuses in on the data of interest and analyze it in ways unavailable with the prior art collaborative project management software.
• a briefing book page permits a project participant to "drill down" on a particular item on the briefing book page to access the trackpoint(s) and/or briefing book page(s) that underlie the selected item.
• a project participant monitoring engine development may wish to drill down (e.g., by clicking on a mouse or performing a predefined user input) on the status attribute field in order to, for example, ascertain why the current status for engine development is "behind schedule.”
• drilling down on an attribute value or data in a child briefing book page (such as briefing book page 602 in the example of Fig.
• the viewer may bring the viewer to the trackpoint(s) or parent briefing book page(s) (such as briefing book pages 604 and 606 in the example of Fig. 6) from which the attribute value or data under examination is obtained or derived.
• the identity of the trackpoint(s) or parent briefing book page(s) may be ascertained, for the purpose of drilling down, by following the explicit or implicit link between the child briefing book page and the underlying trackpoint(s) and/or parent briefing book page(s).
• the viewer can further drill down on the attribute value of a parent briefing book page (e.g., briefing book page 604) to allow the viewer to follow the link further down to the underlying attributes, which may exist in trackpoint(s) or grandparent briefing book page(s).
• a briefing book page or trackpoint may be provided with an "automatic annotation" field.
• Data in the automatic annotation field is automatically passed up to any briefing book page or trackpoint that references the trackpoint/briefmg book page that contains the automatic annotation field.
• the annotation in a child briefing book page would include all the annotations that exist in the automatic annotation fields of the trackpoint(s) briefing book page(s) that are parent or grandparent to that child briefing book page.
• a link map tool may be provided which provides the project participant with a map of relationships (established via links or implicitly via functions) between the trackpoints.
• a glossary or a taxonomy may be provided to assist the project participant in filling out the attribute values (e.g., the metadata or the typed data within the attribute fields).

Landscapes

• Engineering & Computer Science (AREA)
• Business, Economics & Management (AREA)
• Entrepreneurship & Innovation (AREA)
• Human Resources & Organizations (AREA)
• Strategic Management (AREA)
• Economics (AREA)
• Tourism & Hospitality (AREA)
• Theoretical Computer Science (AREA)
• Operations Research (AREA)
• Quality & Reliability (AREA)
• Marketing (AREA)
• Physics & Mathematics (AREA)
• General Business, Economics & Management (AREA)
• General Physics & Mathematics (AREA)
• Data Mining & Analysis (AREA)
• Development Economics (AREA)
• Educational Administration (AREA)
• Game Theory and Decision Science (AREA)
• Management, Administration, Business Operations System, And Electronic Commerce (AREA)
• Information Transfer Between Computers (AREA)

Applications Claiming Priority (13)

Publications (2)

Family

ID=27556836

Family Applications (1)

Country Status (4)

Families Citing this family (189)

Citations (5)

Family Cites Families (13)

• 1998
  • 1998-10-01 EP EP98952033A patent/EP1090366A4/de not_active Withdrawn
  • 1998-10-01 WO PCT/US1998/020771 patent/WO1999018530A1/en not_active Ceased
  • 1998-10-01 AU AU97830/98A patent/AU9783098A/en not_active Abandoned
  • 1998-10-01 US US09/164,946 patent/US6334124B1/en not_active Expired - Fee Related
  • 1998-10-01 US US09/164,947 patent/US6212549B1/en not_active Expired - Fee Related
• 2001
  • 2001-01-19 US US09/766,134 patent/US6370562B2/en not_active Expired - Fee Related

Patent Citations (5)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events