A system and method for updating project status in real time based on deliverable status.

Abstract

To provide a system and method for updating a real-time project status based on a deliverable status.SOLUTION: A method updates a status of a project with a plurality of tasks. Each task has at least one deliverable. The project status is updated in real-time based on a deliverable status of at least one task deliverable. For each project task with at least one deliverable, a plurality of deliverable lifecycle states to be tracked are defined. Each tracked deliverable lifecycle state is mapped to a percentage completion of a project task. A weightage is assigned to each deliverable according to an importance of the deliverable. A changed lifecycle state is received for a deliverable, and the project task percentage completion status is automatically adjusted according to a product of the changed lifecycle state and the assigned weightage.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] Cross - reference to Related Applications This application claims the benefit of priority to U.S. Provisional Patent Application No. 63 / 047,772, filed Jul. 2, 2020, entitled "Method for Updating Real - Time Project Status Based on Deliverable Status". The disclosure of the prior application is hereby incorporated by reference in its entirety.

[0002] Field of the Invention The present invention relates to project management tools, and more particularly, to automatically incorporating deliverable status updates into project status updates.

Background Art

[0003] Background of the Invention In project management, projects are typically managed by breaking them down into many tasks, and the completion of each task is monitored by manually updating task parameters (e.g., task percentage complete and / or task maturity status). As product development and production become increasingly automated and decentralized, managing complex task interdependencies becomes difficult, and resource scheduling and allocation become more complicated. This results in additional activities that do not create value, such as providing project status during situation changes. In particular, when the status of the first task deliverable changes, it becomes difficult to track and accurately reflect the resulting direct and / or indirect impact on the second deliverable, and significant time may be required. Moreover, manually prepared project status may be based only on process data, which may not be up - to - date, and thus the resulting status may be based more on perception than on fact. Therefore, there is a need in the industry to address one or more of these problems. [Overview of the project] [Means for solving the problem]

[0004] Summary of the Invention Embodiments of the present invention provide a system and method for updating project status in real time based on deliverable status. Briefly, the present invention is intended for application to updating the status of a project involving a large number of tasks, each task having at least one deliverable. The project status is updated in real time based on the deliverable status of at least one task deliverable. For each project task having at least one deliverable, a large number of deliverable lifecycle states to be tracked are defined. Each tracked deliverable lifecycle state is mapped to the percentage completion of the project task. Weights are assigned to each deliverable according to its importance. Changes in the lifecycle state for a deliverable are received, and the project task percentage completion status is automatically adjusted according to the product of the changed lifecycle state and the assigned weight.

[0005] Other systems, methods, and features of the present invention will be apparent or will become apparent to those skilled in the art upon examination of the following drawings and detailed description. All such additional systems, methods, and features are included in this description, fall within the scope of the present invention, and are intended to be protected by the appended claims.

[0006] Brief explanation of the drawing The accompanying drawings are included to provide a further understanding of the present invention and are incorporated into and constitute part of this specification. The drawings illustrate embodiments of the present invention and, together with the description, serve to illustrate the principles of the present invention. [Brief explanation of the drawing]

[0007] [Figure 1] This is a block diagram 100 showing the structure of a project under an exemplary first embodiment of the present invention. [Figure 2] This is block diagram 200, showing the relationships between objects in the project in Figure 1. [Figure 3] This is a screenshot of an exemplary task deliverable table under the first embodiment. [Figure 4] This is a screenshot showing the weighting of editable artifacts under the first embodiment. [Figure 5] This is a schematic diagram illustrating an example of a system for performing the functionality of the present invention. [Figure 6] This is a flowchart illustrating an exemplary method for automatically updating project status according to the first embodiment. [Figure 7] This is a schematic block diagram of an exemplary embodiment of a system for automatically updating project status. [Modes for carrying out the invention]

[0008] Detailed explanation The following definitions are useful for interpreting terms applicable to the features of the embodiments disclosed herein and are intended solely to define elements within this disclosure.

[0009] Where used in this disclosure, “project” refers to a set of tasks to be completed in order to achieve a specific outcome. A project can be defined as a set of inputs and outputs required to achieve a particular goal. Projects can range from simple to complex and can be managed by one or many people. Projects are typically described and delegated by a project manager.

[0010] Where used in this disclosure, “task” refers to a single unit of work, such as an action performed within a project or a single step in a multi-step project. A task is completed by a set deadline and contributes to a work-related objective. Just as project management is the harmonious integration of individual tasks, a task can be further subdivided into subtasks, each of which may also have a clear start and end date for completion.

[0011] Where used in this disclosure, “Deliverables” refers to products or services delivered to an internal or external client as part of a task. Deliverables are typically tangible, measurable, and specific, with deadlines. Deliverables meet milestones or deadlines created and generated in the project plan. Examples of deliverables include software products, design documentation, training programs, 3D designs, requirements specifications, engineering or manufacturing artifacts, or other assets as defined in the project plan.

[0012] Where used within this disclosure, “State” refers to a unit of progress used to measure the completion of a deliverable. Each state can be assigned a credit that defines a “maturity level” for the deliverable, which indicates the percentage of completion of the associated deliverable. For example, after the first state is completed, the deliverable may be credited as 25% complete. Credits can be assigned to states, for example, by the project manager.

[0013] Where used in this disclosure, “Terminal” refers to a data entry device used to enter product data and process data for use in the embodiments described herein. Examples of terminals include, among others, personal computers, network-connected computers, smartphones, and tablet computers. A terminal may communicate directly with one or more system entities or through one or more servers.

[0014] Embodiments of the present invention are described in detail here, examples of which are shown in the accompanying drawings. Wherever possible, the same reference numerals are used in the drawings and description to refer to the same or similar parts.

[0015] Figure 1 is a block diagram 100 showing the structure of a project under an exemplary first embodiment of the present invention. Project 110 consists of one or more tasks 120a-120d. Each task includes one or more deliverables 130a-130c. As shown in Figure 4, each deliverable 130a-130c is assigned a weight (weighting) 135a-135c, for example, by the project manager, indicating the relative importance of the deliverables 130a-130c of the associated task 120 to project 110. The minimum weight is 1%. The sum of each weight 135a-135c for all deliverables 130a-130c of task 120a-120d is 100%. The maturity of each deliverable 130a-c is measured by a series of maturity states 234-237.

[0016] Every project task has one or more tangible deliverables. Under the first embodiment, product data 711 (Figure 7) and process data 712 (Figure 7) can be stored in a single database, thereby enabling interaction between related objects. For example, project 110 may have an associated project database 710 (Figure 7) that contains objects and relationships between objects. Examples of objects include a deliverable business object 260, a global project deliverable object 230 (Figure 2), page objects and automation objects that provide input / output access to at least one other object (e.g., project deliverable object 230, document object, part object). The project deliverable object 230 stores task deliverable types 231 (Figure 2). Each deliverable 130a-c is represented by an associated global project deliverable object 230 (Figure 2). Storing product data 711 (Figure 7) and process data 712 (Figure 7) in a single database 710 (Figure 7) facilitates the transition from manually generated, perception-based reports at the completion level to more fact-based, automated, and up-to-date reports.

[0017] Previously, task percentage completion values ​​were updated based on the task contractor manually updating the task percentage completion, as well as manually updating the task maturity status in the task lifecycle status, for example. This was problematic because the task lifecycle status values ​​were subjective and, in some cases, inconsistent across different tasks in a project and / or similar tasks in different projects.

[0018] Under the first embodiment, a new object of the global project deliverable object 230 (FIG. 2) is created to track the deliverable percentage completion. The global project deliverable object 230 (FIG. 2) defines a task deliverable type 231 and associated deliverable maturity states 234-237 (FIG. 2). Each task deliverable type has a template. Examples of the deliverable type 231 include, among others, documents, PDF files, and technical engineering designs. The deliverable maturity states 234-237 indicate the measure of deliverable completion (e.g., corresponding to 25%, 50%, 75%, 100%). The project percentage completion is calculated based on each deliverable maturity state 234-237 (FIG. 2). As shown by FIG. 3, the deliverable task status can be displayed, for example, in an editable task deliverable table.

[0019] FIG. 2 shows a block diagram associating the task life cycle state of task 120 of the deliverable business object D1 260 with the maturity state of an associated deliverable 130 (FIG. 1) as represented by the global project deliverable object 230. Examples of the deliverable business object D1 260 include, but are not limited to, Word documents, PDF files, technical engineering designs, manufacturing plans, or requirement specifications. The drop-down of the state names in the task deliverable table 300 (FIG. 3) corresponds to 100%, 75%, 50%, 25% and follows the life cycle states 261-264 in the policy for managing the type of deliverable. "In work" cannot be 100% and "release" cannot be 75%. However, "release" can be 100% and "in work" can be 75%.

[0020] Each task 120 has one or more artifacts 130 (Figure 1) represented by an associated project artifact object 230. Each project artifact object 230 has an artifact type 231, a task artifact policy 232 such as "Document Release", a task maturity state 233 having a set of task artifact maturity states 234-237, and an automation enable flag 238. If the automation enable flag 238 is set, task 120 contributes to a portion of the project artifact percentage calculated by multiplying the task artifact percentage completion 240 by the artifact weight 135.

[0021] The deliverable business object D1 260 includes a deliverable business object lifecycle state 270, and the deliverable business object lifecycle state 270 can be one of the lifecycle maturity states S1 to S4 261 to 264. When the deliverable business object lifecycle state 270 is S1 261, which is the same task maturity state 233 as the deliverable maturity state 234, and it indicates that the definition of the deliverable maturity state 234 should be 25% completion of the deliverable, the deliverable percent complete is set to 25%. When the deliverable business object lifecycle state 270 is S2 262, which is the same task maturity state 233 as the deliverable maturity state 235, and it indicates that the definition of the deliverable maturity state 235 should be 50% completion of the deliverable, the deliverable percent complete is set to 50%. When the deliverable business object lifecycle state 270 is S3 263, which is the same task maturity state 233 as the deliverable maturity state 236, and it indicates that the definition of the deliverable maturity state 236 should be 75% completion of the deliverable, the deliverable percent complete is set to 75%. When the deliverable business object lifecycle state 270 is S4 264, which is the same task maturity state 233 as the deliverable maturity state 237, and it indicates that the definition of the deliverable maturity state 237 should be 100% completion of the deliverable, the deliverable percent complete is set to 100%. In the case of this embodiment, there are four maturity states, but it should be noted that other embodiments may have fewer maturity states, and all except the 100% maturity state are optional.

[0022] A user (e.g., a project manager) can edit the individual deliverable weighting 135 for each deliverable 130, and the weighting 135 is displayed in the task deliverable table. The cumulative deliverable weighted percentage value is calculated based on the deliverable maturity states 234 to 237 and the deliverable weighting 135 to generate the percentage complete value 240 for the task 120.

[0023] The artifact maturity states 234-237 can be associated with text descriptors, including, among many others, "Prepared," "Ready," "In Progress," "Under Review," and "Completed." The task percentage completion value is updated based on the task maturity state. For example, the task percentage completion value is typically 0% in the prepared state and 100% in the completed state. If the average percentage completion value of each task artifact 230 is 100%, task 120 is automatically promoted to the completed state. If the average percentage completion value is less than 100%, task 120 is automatically demoted to the "In Progress" state if the task has been promoted to the under review or completed state. The automatic promotion / demotion state for task 120 is configurable and defined in the page object.

[0024] When a deliverable is added to or removed from a task, the weighting of the deliverable is automatically distributed so that the sum of all weights equals 100. In this way, the impact of changes in the number of deliverables in a task is evenly distributed across all deliverables in the task. Subsequently, the task contractor or project leader can manually change the weighting to define the importance of the deliverables in the task (as long as the sum equals 100), and this change in the deliverable weighting is then taken into account by the software until the deliverable is added to or removed from the task.

[0025] Each time an artifact is added to or removed from a task, the weights are distributed evenly among all artifacts. In scenarios with an indivisible number of artifacts, the weights of each artifact are rounded to an integer so that the weights for all artifacts are integers. For example, with two artifacts, the system automatically distributes the weights as 50 each, while with three artifacts, the weights are distributed as 34, 33, and 33.

[0026] When an artifact with no defined or disabled automation is added to a project task, the calculated values ​​in the task artifact table are cleared, and the task's percentage completion is updated manually by the task contractor, not triggered by the artifact's lifecycle state maturity. Whenever an artifact with no defined or disabled automation is added to a task, the user adding the artifact is presented with a message stating that automation is not possible to update the task's percentage completion because automation is not defined or disabled for the artifact being added. For each artifact object, the task artifact table has a column indicating whether automation is defined, disabled, or not defined for that artifact type. Furthermore, when a task artifact with no defined or disabled automation is removed from a task, it is determined whether automation can be applied to the remaining artifacts of the task. If so, all values ​​in the task artifact table are recalculated, and the project task's percentage completion is updated based on the artifact's lifecycle status.

[0027] Figure 6 is a flowchart 600 of a method for updating project status in real time based on deliverable status. Any process description or block in the flowchart should be understood as representing a module, segment, part of code or step containing one or more instructions for implementing a particular logical function of the process, and it should be noted that, as will be understood by those skilled in the art, alternative implementations are included within the scope of the invention, and functions can be performed in any order (including substantially simultaneously or in reverse order) than those shown or discussed, depending on the functionality involved. The method updates project status in real time based on deliverable status for a project having a large number of tasks, each task having at least one deliverable. As shown by block 610, a large number of deliverable lifecycle states are defined for each deliverable. As shown by block 620, each tracked deliverable lifecycle state is mapped to the percentage completion of the project task. As shown by block 630, weights are assigned to each deliverable according to the importance of the deliverable. As shown by block 640, the changed lifecycle state for the deliverable is received. As shown in block 650, the project percentage completion status is automatically adjusted according to the product of the changed lifecycle state and the assigned weight.

[0028] Figure 7 is a schematic block diagram 700 of an exemplary embodiment of a system for automatically updating project status. The system 700 includes a task artifact relationship manager 740 for associating product data 711 and process data 712 in a project database 710. The project artifact manager 730 receives real-time project status entered into one or more terminals 760, for example, via a project server 750. The project artifact manager 730 maintains a task maturity status machine 733 and an artifact business object lifecycle status machine 770. The project artifact manager 730 and the task artifact relationship manager 740 communicate with the terminals 760 and the project database 710. Although Figure 7 shows a distributed embodiment, in an alternative embodiment, two or more of the project database 710, task artifact relationship manager 740, and project artifact manager 730 can be hosted within the same facility.

[0029] The project artifact manager 730 can create and manage global project artifact objects 230 (Figure 2), while the task artifact relationship manager 740 calculates a cumulative artifact weighted percentage value based on artifact maturity states 234-237 (Figure 2) and artifact weighting 135 (Figure 2) to generate a percentage completion value 240 (Figure 2) for task 120 (Figure 2).

[0030] Previous project management systems rolled up percentage completion from the task level to the stage level and then to the project itself, but the embodiments described herein automate how percentage completion is applied to the task itself based on the task's deliverable status. Under these embodiments, if a deliverable is considered 50% complete, it means that the deliverable is actually in a certain maturity lifecycle state and its importance to the task is incorporated. This results in factual reporting instead of perception-based reporting. For example, here the project leader does not necessarily have to communicate with team members who generate deliverable statuses and then subjectively update the project status. This subjective update involves manually applying percentage completion to project tasks and compiling this information for reporting, and this information may not be up-to-date because the deliverable status may have changed since the previous communication with the team member.

[0031] Previous project management tools could not automatically update project status in this manner based on changes in lifecycle deliverables because, unlike under this embodiment, deliverables (product data and documents) and project information were not managed in a single system that retrieved and worked with data from a single database, and therefore these items were not directly connected to each other. This embodiment leverages this direct connection between deliverable status and project information by introducing automation to update project task percentage completion based on deliverable lifecycle status. This eliminates additional, non-value-adding activities such as following up on and updating project status for both project leaders and task contractors. This allows task contractors to focus on completing deliverables instead of spending time updating project task status.

[0032] Under this embodiment, project tasks themselves are not weighted. Instead, the deliverables of the tasks are weighted. Project tasks can be defined to occur linearly in series based on task dependencies (i.e., Task B cannot start until Task A is completed), or to occur in parallel, depending on how the project leader models the project schedule.

[0033] Embodiments of this system for performing the functionality described in detail above can be implemented via a computer, an example of which is shown in the schematic diagram of Figure 5. System 500 includes a processor 502, a storage device 504, a memory 506 containing software 508 that defines the functionality described above, input and output (I / O) devices 510 (or peripherals), and a local bus or local interface 512 that enables communication within System 500. The local interface 512 may be one or more buses or other wired or wireless connections, such as, but not limited to, those known in the art. The local interface 512 may have additional elements such as controllers, buffers (caches), drivers, repeaters, and receivers to enable communication, but these elements have been omitted for simplicity. Furthermore, the local interface 512 may include address, control, and / or data connections to enable appropriate communication between the aforementioned components.

[0034] The processor 502 is a hardware device for executing software (in particular, that stored in memory 506). The processor 502 may be a custom-made or commercially available single-core or multi-core processor, a central processing unit (CPU), an auxiliary processor between several processors associated with the system 500, a semiconductor-based microprocessor (in the form of a microchip or chipset), a macroprocessor, or any device in general for executing software instructions.

[0035] Memory 506 may include one or a combination of volatile memory elements (e.g., random access memory (RAM such as DRAM, SRAM, SDRAM, etc.)) and non-volatile memory elements (e.g., ROM, hard drive, tape, CD-ROM, etc.). Furthermore, memory 506 may incorporate electronic, magnetic, optical, and / or other types of storage media. It should be noted that memory 506 may have a distributed architecture in which various components are installed remotely from one another (but accessible by processor 502).

[0036] Software 508 defines the functionality performed by the system 500 according to the present invention. Software 508 in memory 506 may include one or more separate programs, each program including an ordered list of executable instructions for performing the logical functions of the system 500 as described below. Memory 506 may include an operating system (O / S) 520. The operating system essentially controls the execution of programs in the system 500 and provides scheduling, input / output control, file and data management, memory management, and communication control and related services.

[0037] The I / O device 510 may include input devices, such as, but are not limited to, keyboards, mice, scanners, and microphones. Furthermore, the I / O device 510 may also include output devices, such as, but are not limited to, printers and displays. Finally, the I / O device 510 may further include devices that communicate via both inputs and outputs, such as, but are not limited to, modulators / demodulators (modems for accessing other devices, systems, or networks), radio frequency (RF) or other transceivers, communication interfaces, bridges, routers, or other devices.

[0038] While the system 500 is operating, the processor 502 is configured to execute software 508 stored in the memory 506 in order to communicate data to and from the memory 506, as described above, and to control the operation of the system 500 in accordance with the software 508.

[0039] While the functionality of system 500 is operating, processor 502 is configured to execute software 508 stored in memory 506 in order to communicate data to and from memory 506, and generally to control the operation of system 500 according to software 508. The operating system 520 is read by processor 502 (possibly buffered within processor 502) and then executed.

[0040] When System 500 is implemented in software 508, it should be noted that the instructions for implementing System 500 may be stored by any computer-related device, system, or method, or in any computer-readable medium for use in connection with any computer-related device, system, or method. Such a computer-readable medium may, in some embodiments, correspond to either or both of memory 506 and storage device 504. In the context of this document, computer-readable medium is an electronic, magnetic, optical, or other physical device or means that contains or can store computer programs for use by or in connection with any computer-related device, system, or method. The instructions for implementing the system may be embodied by a processor or other such instruction execution system, apparatus, or device, or in any computer-readable medium for use in connection with a processor or other such instruction execution system, apparatus, or device. Although processor 502 is mentioned as an example, such an instruction execution system, apparatus, or device may, in some embodiments, be any computer-based system, a system including a processor, or other system that can fetch instructions from an instruction execution system, apparatus, or device and execute those instructions. In the context of this document, “computer-readable medium” may also be any means capable of storing, transmitting, propagating, or transporting a program for use by or in connection with a processor or other such instruction execution system, apparatus, or device.

[0041] Such computer-readable media may include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, devices, or propagation media. More specific examples of computer-readable media (a list that is not exhaustive) may include, one or more wired electrical connections (electronic), portable computer diskettes (magnetic), random access memory (RAM) (electronic), read-only memory (ROM) (electronic), electrically erasable programmable read-only memory (EPROM, EEPROM, or flash memory) (electronic), optical fibers (optical), and portable compact disk read-only memory (CDROM) (optical). Note that since a program can be electronically captured, for example, via optical scanning of paper or other media, and then compiled, interpreted, or otherwise processed in an appropriate manner as needed, and then stored in computer memory, the computer-readable medium may even be the paper on which the program is printed or another appropriate medium.

[0042] In alternative embodiments in which the system 500 is implemented in hardware, the system 500 may be implemented in any or a combination of the following technologies, each well known in the art: discrete logic circuits having logic gates for performing logic functions on data signals, application-specific integrated circuits (ASICs) having appropriate combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0043] As described above, it is advantageous for the platform to manage product and process data within a single database. The out-of-the-box (OOTB) "Task Artifact" relationship is important because it is a link between project tasks and products (such as 3D designs, PDF documents, or requirements specifications). This product data, through the "Task Artifact" relationship, becomes an artifact for the project task. Each artifact is managed by a policy that has a lifecycle state. Percentage completion is updated on the task so that the artifact advances or regresses in its lifecycle between states. Artifact policies are defined globally; therefore, for example, all Word files have a first policy, and all CAD files have a second policy. However, multiple policies can be associated with each type of artifact, meaning that a Word file can be managed by either the first or second policy. When a Word file is saved on the platform, the user selects the appropriate policy. For example, the first policy may have only four lifecycle states, and the second policy may have six lifecycle states, and the user can choose either according to their desired business needs / rules. Word files (and in that sense, all IP on the platform) are always managed by a single policy, at any given time. Therefore, the combination of the type of deliverable (Word, CAD, etc.) and the management policy (first policy or second policy) defines the automation.

[0044] In summary, it will be apparent to those skilled in the art that various modifications and changes can be made to the structure of the present invention without departing from the scope or spirit of the invention. With that in mind, the present invention covers the modifications and changes to this invention provided, which are intended to fall within the scope of the following claims and their equivalents. [Explanation of symbols]

[0045] 110 Project 120 tasks 130 deliverables 135 weight 230 Project Deliverables 231 Task deliverable types 232 Task deliverable policy 233 Task Maturity Status 234 Status 235 Status 236 Status 237 Status 238 Enable Automation 240 Deliverables % Completed 260 Deliverable Business Objects 261 Lifecycle State 262 Lifecycle State 263 Lifecycle State 264 Lifecycle States 270 Deliverable Business Object Lifecycle State 502 Processors 504 Storage device 506 memory 508 Software 510 Input / Output Devices 512 Local Bus 711 Product Data 712 Process Data 730 Project Deliverables Manager 733 Task Developing Machine 740 Task Deliverables Manager 750 Project Servers 760 devices 770 Deliverables Business Object Lifecycle State Machine

Claims

1. A system for updating and maintaining the project status of a project in real time, wherein the project comprises a number of tasks, each task further comprising at least one deliverable, and the system A memory device configured to store a project database including product data and process data, wherein the project database consists of project artifact objects for each of the at least one artifact and artifact business objects, The project deliverable object further includes a task deliverable type comprising multiple task deliverable types, a task deliverable policy comprising multiple lifecycle stages, and a deliverable maturity state indicating a measure of completion for at least one deliverable according to the task deliverable policy, wherein each of the multiple task deliverable types has a corresponding task deliverable template. The aforementioned deliverable business object further includes a memory device containing multiple deliverable lifecycle states, which will be tracked for one of the corresponding tasks among the numerous tasks. A computer-based task artifact relationship manager configured to associate the product data and the process data, comprising a task artifact relationship manager communicating with the project database, A computer-based project artifact manager further comprising a task maturity state machine and an artifact business object lifecycle state machine, wherein the project artifact manager communicates with the task artifact relationship manager and the project database, Receiving real-time project status, Based on the real-time project status, the task maturity status machine, the deliverable business object lifecycle status machine, and the project database are updated. A project artifact manager configured to perform the following actions The system is equipped with, For each task that has at least one deliverable, define the numerous deliverable lifecycle states to be tracked, Mapping each of the traceable artifact lifecycle states to be tracked to a corresponding percentage completion of one of the numerous tasks, Assigning weights to each project deliverable object according to the importance of one of the deliverables mentioned above, Receiving the aforementioned deliverable whose lifecycle state has been changed, The project task percentage completion status is automatically adjusted according to the product of the changed deliverable lifecycle state and the assigned weight. A system configured to perform the following actions.

2. The system according to claim 1, further comprising the memory device, the task artifact relationship manager, and the project artifact manager, and a project server communicating with the project artifact manager.

3. The system according to claim 2, further comprising a terminal communicating with the project server, which is configured to transmit the real-time project status to the project deliverable manager.

4. The system according to claim 1, wherein the task deliverable relationship manager is configured to update the product data and the process data.

5. A computer-based method for updating the project status of a project in real time, wherein the project comprises a number of tasks, each task further comprising at least one deliverable, and the real-time updated project status is based on the deliverable status of at least one task deliverable, and the method is: A step of providing a system for updating and maintaining the project status of a project in real time, wherein the project comprises a number of tasks, each task further comprising at least one deliverable, and the system A memory device configured to store a project database including product data and process data, wherein the project database consists of project artifact objects for each of the at least one artifact and artifact business objects, The project deliverable object further includes a task deliverable type comprising multiple task deliverable types, a task deliverable policy comprising multiple lifecycle stages, and a deliverable maturity state indicating a measure of completion for at least one deliverable according to the task deliverable policy, wherein each of the multiple task deliverable types has a corresponding task deliverable template. The aforementioned deliverable business object further includes a memory device containing multiple deliverable lifecycle states, which will be tracked for one of the corresponding tasks among the numerous tasks. A computer-based task artifact relationship manager configured to associate the product data and the process data, comprising a task artifact relationship manager communicating with the project database, A computer-based project artifact manager further comprising a task maturity state machine and an artifact business object lifecycle state machine, wherein the project artifact manager communicates with the task artifact relationship manager and the project database, Receiving real-time project status, The task maturity status machine, the deliverable business object lifecycle status machine, and the project database are updated based on the real-time project status. A project artifact manager configured to perform the following actions The steps include providing a system that includes, A computer processor receives a number of artifact lifecycle states to be tracked for each task having at least one artifact, The processor performs the steps of mapping each of the artifact lifecycle states to be tracked to a corresponding percentage completion of one of the numerous tasks, The processor receives a weight for each project artifact object according to the importance of one of the corresponding artifacts. The processor receives a modified artifact lifecycle state for one of the artifacts, and automatically adjusts the project task percentage completion status according to the product of the modified artifact lifecycle state and the weighting. Methods that include...

6. The method according to claim 5, wherein each lifecycle state represents the completion percentage of the corresponding project task.

7. The method according to claim 5, wherein at least one project task deliverable includes project data.

8. The method according to claim 5, wherein at least one project task deliverable includes a document.

9. The method according to claim 5, further comprising the step of mapping a switch to one of several deliverables and determining whether the deliverable is included in or excluded from the project task percentage completion calculation.

10. The method according to claim 5, further comprising the step of automatically assigning weights to 100% of the deliverables, wherein the project task has exactly one deliverable.

11. The method according to claim 5, wherein the project and the numerous tasks share a common database.

Images