U.S. patent application number 11/844903 was filed with the patent office on 2008-01-31 for system and method for automatic financial project management.
Invention is credited to Joseph GENDLER.
Application Number | 20080027861 11/844903 |
Document ID | / |
Family ID | 38950951 |
Filed Date | 2008-01-31 |
United States Patent
Application |
20080027861 |
Kind Code |
A1 |
GENDLER; Joseph |
January 31, 2008 |
SYSTEM AND METHOD FOR AUTOMATIC FINANCIAL PROJECT MANAGEMENT
Abstract
A system and method for providing project management tools to
support construction, renovations, maintenance and other projects.
The system automates the creation, processing and approval cycles
of the numerous documents involved with each project. The system
provides standardized work processes through processing templates.
The system provides automated control and management of the
process. The system allows project initiation and funding approval
by clients throughout the corporation via a desktop browser coupled
to a corporate Intranet. A software application embodying the
present invention and its underlying technology are appropriate for
a paper intensive area. It reduces the approval cycle of projects.
It automates the creation, processing and approval cycle of
documents by routing documents electronically for on-line
approval.
Inventors: |
GENDLER; Joseph; (Fairlawn,
NJ) |
Correspondence
Address: |
HUNTON & WILLIAMS LLP;INTELLECTUAL PROPERTY DEPARTMENT
1900 K STREET, N.W.
SUITE 1200
WASHINGTON
DC
20006-1109
US
|
Family ID: |
38950951 |
Appl. No.: |
11/844903 |
Filed: |
August 24, 2007 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
09705486 |
Nov 3, 2000 |
|
|
|
11844903 |
Aug 24, 2007 |
|
|
|
60163506 |
Nov 4, 1999 |
|
|
|
Current U.S.
Class: |
705/40 |
Current CPC
Class: |
G06Q 10/06312 20130101;
G06Q 10/063114 20130101; G06Q 10/063118 20130101; G06Q 10/06
20130101; G06Q 10/10 20130101; G06Q 20/102 20130101; G06Q 10/06313
20130101 |
Class at
Publication: |
705/040 |
International
Class: |
G06Q 40/00 20060101
G06Q040/00; G06Q 10/00 20060101 G06Q010/00 |
Claims
1-67. (canceled)
68. A construction payment management system comprising: a server
that stores an application, the application receiving information
from a participant in a construction project; and a database server
connected to the server, the database server storing the
information of the participant, the application accessing the
information of the participant in order to transfer to the
participant a payment associated with the construction project.
69. The construction payment management system of claim 68, further
comprising a notification module.
70. The construction payment management system claim 69, wherein
the notification module is an inbox for timely communications of
messages and documents to the participant.
71. The construction payment management system of claim 68, wherein
the participant is a vendor.
72. The construction payment management system of claim 71, wherein
the vendor is a construction entity.
73. The construction payment management system of claim 68, wherein
the information is an invoice relating to the construction
project.
74. The construction payment management system of claim 68, further
comprising a web server, wherein the participant accesses the
construction project through the web server.
75. The construction payment management system of claim 68, wherein
the construction project is associated with a document collection
and the document collection is maintained in the database
server.
76. The construction payment management system of claim 75, wherein
the document collection has a plurality of documents, each of the
plurality of documents in the document collection being associated
with a respective electronic notebook, the documents in the
document collection being electronic documents, each electronic
notebook including associated categories, for each electronic
notebook the categories provided including: a comment category that
includes general notes; a status category that includes a status of
the construction project ; and a published notes category, the
method including publishing notes in the published notes category
to a team working on the construction project.
77. The construction payment management system of claim 68, wherein
the received information is encrypted during transmission.
78. The construction payment management system of claim 68, wherein
the construction project being a contract and the document
collection including contract documents.
79. The construction payment management system of claim 68, wherein
the construction project is engineering related.
80. The construction payment management system of claim 68, wherein
the construction project is architectural related.
81. A method of managing a construction payment process implemented
by a computer, the method comprising: receiving by an application
an invoice and a lien waiver from a participant in a construction
project; approving the invoice; and transferring monetary funds to
the participant.
82. The method of claim 81, further wherein transferring monetary
funds to the participant is achieved by one of the following:
giving a credit to the participant's Demand Deposit Account (DDA),
issuing a check, or using Electronic Data Interchange (EDI)
remittance.
83. The method of claim 81, wherein the construction project is
associated with a document collection and the document collection
is maintained in the database server.
84. The method of claim 83, wherein the document collection has a
plurality of documents, each of the plurality of documents in the
document collection being associated with a respective electronic
notebook, the documents in the document collection being electronic
documents, each electronic notebook including associated
categories, for each electronic notebook the categories provided
including: a comment category that includes general notes; a status
category that includes a status of the construction project ; and a
published notes category, the method including publishing notes in
the published notes category to a team working on the construction
project.
85. The method of claim 84, wherein approving the invoice further
comprising: identifying approvers that comprises an approval
hierarchy, the approval hierarchy being a series of approvers;
automatically forwarding a notice requesting approval of at least
one electronic document, in the document collection, from a
previous approver to a successive one of the approvers upon
approval of the at least one electronic document by the previous
approver in the approval hierarchy.
86. The method of claim 81, wherein the construction project being
a contract and the document collection including contract
documents.
87. The method of claim 81, wherein the construction project is
engineering related.
88. The method of claim 81, wherein the construction project is
architectural related.
89. A construction payment management system comprising: a server
that stores an application, the application receiving information
from a participant in a construction project, wherein the
information is encrypted during transmission; an inbox allowing
timely communication of messages and documents to the participant;
a web server, wherein the participant accesses the construction
project through the web server; and a database server connected to
the server, the database server storing the information of the
participant, the application accessing the information of the
participant in order to transfer to the participant a payment
associated with the construction project, wherein the construction
project is associated with a document collection and the document
collection is maintained in the database server, wherein the
document collection has a plurality of documents, each of the
plurality of documents in the document collection being associated
with a respective electronic notebook, the documents in the
document collection being electronic documents, each electronic
notebook including associated categories, for each electronic
notebook the categories provided including: a comment category that
includes general notes; a status category that includes a status of
the construction project ; and a published notes category, the
method including publishing notes in the published notes category
to a team working on the construction project.
Description
[0001] The present invention is related to and claims priority to
U.S. Provisional Patent Application No. 60/163,506 entitled
AUTOMATED FINANCIAL PROJECT MANAGEMENT SYSTEM, filed Nov. 4, 1999,
the contents of which are incorporated herein by reference.
FIELD OF THE INVENTION
Background of the Invention
[0002] Project management, especially in the area of corporate real
estate project management, is traditionally a process which is
driven by paper forms and documents. These paper documents include
for example, purchase orders, work orders, contracts, Requests for
Assistance (RFA), Requests for Proposals (RFPs), commitments, bids,
invoices, messages (generic correspondence), meeting announcements
and minutes, project close outs, complete punch lists, project
evaluations, and departmental statistics.
[0003] The processing of all of these various documents is very
labor intensive, error prone and subjects the proposed projects to
needless delays. For example, if the manager in charge of approving
commitments is on a business trip for two weeks, a commitment
requiring his or her signature might be delayed for an additional
six weeks, which in turn delays another vendor's initiation of work
and so on.
[0004] Furthermore, an increase in the number of requests for new
construction or engineering projects increases the volume of
documents that are processed by the project administration group
and the accounting operations group. This in turn requires an
increase in processing capacity through an increase in staff levels
or overtime. Conversely, a decrease in volume of requests lowers
the productivity of the groups, as the staff levels are maintained
to support the processing at the peak operations volume.
SUMMARY OF THE INVENTION
[0005] The present invention was originally designed to automate
the project management process for the Corporate Real Estate and
Facilities Department of the assignee of the present invention.
Although originally designed for this type of real estate and
facilities department, it is readily seen that the project
management method and system of the present invention has wide
applicability to most types of project management.
[0006] The system is a collection of process and business objects
that provide project management tools to support construction,
renovations, maintenance and other projects. One primary function
of the system is to automate the creation, processing and approval
cycles of the numerous documents involved with each project. The
system and method of the present invention provides automation to
support the following business processes.
[0007] Strategic Space Planning. This function is responsible for
determining how much space is required, demographic and market
analysis of locations, and owned versus leased funding
strategies.
[0008] Client Management. The system allows project initiation and
funding approval by clients throughout the corporation via a
desktop browser coupled to the system via a corporate intranet.
This concept facilitates self-service delivery. The request
component allows clients to specific requirements for construction,
renovation, relocation or office furniture.
[0009] Project Support. The system assists the real estate
department staff in creating budgets and controlling how budgets
are dispensed though purchase orders, work orders and contracts.
This includes the table maintenance involved in vendor
authorization, workload, reassignment of tasks, security access and
security registration, and changes to processes. Project support is
provided for the administrative processes such as administering
roles and responsibilities, which includes signing authority.
[0010] Project Management. The business objects of the system of
the present invention assist a project manager in creating a
project budget and controlling how that budget is dispensed through
purchase orders, work orders and contracts. Invoices are processed
against the commitments and are paid through an electronic accounts
payable interface. The underlying system structure provides
standardized work processes through processing templates. The
system provides automated control and management of the process.
This methodology is expandable because it is template based,
thereby providing an environment for financial based project
management. Additionally, Project Management includes phases of
project initiation, predesign, schematic design, design
development, construction documents, procurement, preconstruction,
construction, and post construction. The system includes project
management functionality to assist in: Tracking Project Milestones;
Corporate Cost Center Allocations for identifing how project
expenses should be charged; Messages which are generic
correspondence; Meeting Announcements and Minutes; Creation and
approval of commitments; Approval of invoices; Project Close Outs;
Complete Punch Lists; Project Evaluations; and Departmental
Statistics.
[0011] Vendor Management. The system allows direct access via the
Internet to provide extensive functionality for managing approved
vendors in relationship to specific projects. This functionality
allows an approved vendor to author Bids, Requests for Quotes
(RFQs), Invoices, Punch Lists, Lien Waivers and Messages. Other
documents can be received and processed with more limited
functionality. These documents include Request for Proposals,
Contracts, Work/Purchase Orders, Change Orders, Payment
Confirmations and Meeting notices. In addition, an in-box allows
for timely communications of messages and documents.
[0012] The present invention automates the creation, processing and
approval cycles of numerous documents involved in project
management. It allows project initiation and funding approval by
clients throughout the corporation via a desktop browser coupled to
a corporate Intranet. A software application embodying the present
invention and its underlying technology are appropriate for a paper
intensive area. It reduces the approval cycle of projects. It
automates the creation, processing and approval cycle of documents
by routing documents electronically for on-line approval.
[0013] Other objects, features, and advantages of the present
invention will be apparent to one skilled in the art from the
following description of the invention with reference to the
accompanying drawing.
BRIEF DESCRIPTION OF THE DRAWING
[0014] For the purposes of illustrating the present invention,
there is shown in the drawings a form which is presently preferred,
it being understood however, that the invention is not limited to
the precise form shown by the drawing in which:
[0015] FIG. 1 is an illustration of the structure of the system of
the present invention;
[0016] FIG. 2 depicts the process flow of the present
invention;
[0017] FIG. 3 illustrates the tree structure organization of
project management data;
[0018] FIG. 4 depicts a user interface input screen for inputting a
Request for Assistance;
[0019] FIG. 5 shows an approval hierarchy structure according to
the present invention;
[0020] FIG. 6 illustrates a budget template and an example
budget;
[0021] FIG. 7 depicts an On-call commitment to a vendor;
[0022] FIG. 8 shows a Purchase Order commitment;
[0023] FIG. 9 illustrates the creation of a bid package;
[0024] FIG. 10 illustrates the bid opening processing;
[0025] FIG. 11 depicts the processing of bid responses from
vendors;
[0026] FIG. 12 shows the processing of a vendor invoice;
[0027] FIG. 13 illustrates a funding document generated by the
system of the present invention;
[0028] FIG. 14 depicts the close out information available to a
project manager;
[0029] FIG. 15 illustrates a close out ledger; and
[0030] FIG. 16 depicts a partial closeout.
DESCRIPTION OF THE PREFERRED EMBODIMENT
[0031] FIG. 1 illustrates the system 100 of the present invention.
The various parties to the project managed by the system 100
communicate via a corporate Local Area Network (LAN) 105. Connected
to the LAN 105 are various servers 110-120 on which reside the
applications and databases supporting the system 100. Server 115
contains the applications that enable the clients to initiate and
approve project requests and approve funding for such projects.
Work flow server 110 contains the applications which enable the
project staff to create and route project documents and manage
information. In a preferred embodiment, the workplace server 110 is
accessed through an icon on the staffs' work stations 120 which
operates in a windows environment. The applications can be
developed using C, Powerbuilder.TM., SQL, Cold Fusions.TM., or
other similar software development languages and tools.
[0032] Database server 120 provides access to database 122 that
contains the various databases housing the details of all of the
projects under management. In a preferred embodiment, the databases
on server 110 are relational database such as is available from the
Oracle.TM. corporation. Illustrated in FIG. 1 is a work station
125, such as a personal computer (PC), laptop computer or other
such workstations for use by project managers. Clients (employees
of the corporation initiating projects) access system 100 through a
corporate intranet 130 and client work stations 135. Vendors access
system 100 using a vendor In workstation 140 connect to the
corporate LAN 105 preferably through the Internet 145 using a
browser. The vendor workstation 140 uses a "thin" client technology
meaning that the majority of the software for the vendor access
resides on LAN 105 (servers 110, 115). The firewall 150 provides
all of the requisite security such as password protection,
authentication and encryption (if necessary).
[0033] System 100 provides security functions based on roles,
signing authority and access rights. Security access is defined
through a Role-Business Object-Function relationship. In addition,
the ability to perform a function on an object (e.g., a document to
be approved) depends on the state of the object. For example, as
further described below, if a document has been approved, that
document can no longer be modified so as to protect the integrity
of the approval.
[0034] Database 122 contains various tables that support the
security function and allow definitions such as: Roles to Person
table that identifies all the roles a person can perform; a
Functions to Business Object table that identify all the functions
and menu items available to a Business Object; a Tree-views to Role
table that identifies all the tree views (described below)
available for a role; a Functions to Role table used to classify
the functions and menu items as enabled or disabled for each
business object within a role; a Function Exceptions table that
overrides the classification for functions and menu items for each
business object within a role identified at the person level (in
other words, include or exclude a specific function in this
business object for a person playing this role). A further table
contains the state of all of the objects being managed by the
system. A history of the revisions to an object (e.g., the changes
in state during the approval process of a document) is maintained
for auditing purposes. An object in the present invention can have
multiple documents associated therewith. For example, if the object
is a bid, some of the documents associated with the bid could be a
list of vendors (requiring approval) and a commitment (requiring
its own separate approval).
[0035] FIG. 2 illustrates a overview of the project process managed
by the present invention. The process begins with a client 160
determining that there is a need for the creation of a project. In
the preferred embodiment the project is a construction project. The
client 160 initiate the project by generating a Request for
Assistance (RFA). The Request For Assistance is typically generated
by the client 160 with the assistance of a project manager 170. The
process of generating an RFA with the aid of a project manager 170
is an iterative one that involves preparation, negotiation,
performance and acceptance. The RFA contains the nature and scope
of the project, the funding available for and required by the
project, and the schedule by which the project must be complete.
Although the RFA can be communicated by telephone call or e-mail,
in a preferred embodiment of the present invention, the RFA is
generated by the client 160 using system 100. Specifically, the
client uses its workstation 135 to connect to LAN 105 through the
corporate intranet 130 (FIG. 1). The applications on web server 115
prompt the client 160 for all of the necessary information required
to complete the RFA 165. The data contained in the RFA 165 is
stored in database 122 in separate files associated with the
project.
[0036] After the client 160 and the and project manager 170 have
finalized the RFA, it goes through an approval process (described
below) within the client management chain 162. Once the RFA has
been approved by client management 162 is it automatically
forwarded to facilities management 172 for approval and assignment
of a project manager 170. Once the project manager 170 has been
assigned and receives the approved RFA, the project manager 170
uses the RFA as a blueprint. As shown in loop 173, the project
manager 170 can typically delegate portions of the project to other
groups (e.g., design work and its management can be delegated to a
design group within the organization). As will be further described
below, the project manager 170 creates bid packages, purchase
orders and or contracts 175 which are used to solicit the work from
vendors 180. Typically project managers 170 work with the various
vendors 180 in refining the nature and scope of the project. The
project managers 170 receive proposals from the vendors 180 who are
bidding on the whole or pieces of the project under consideration.
The communication between the project managers 170 and the vendors
can occur using the telephone or e-mail, but preferably the vendors
180 communicate with the project managers using their workstations
140 through the Internet 145 and firewall 150.
[0037] For larger projects, the result of the bidding and proposal
process is a contract 175 which defines, in detail, the tasks to be
preformed by the vendors 180 in completing the projects. The
specific tasks to be accomplished can be defined via a Purchase
Order, a facilities agreement or a service agreement. Typically,
contract 175 is a master contract which defines the general nature
of the project as well as the general nature of the relationship
between the corporation and the vendors 180. Pursuant to the
contract 175, the project manager 170 will generate specific
commitments to vendors 180 to pay for specific tasks performed by
the vendors 180. The contract 175 further provides for the ability
of the project managers 170 to issue change orders to the vendors
180 as the scope of the project changes during the evolution of the
project.
[0038] Upon completion of a task, the vendors 180 issue an invoice
185 to the corporation. The invoice 185 can be transmitted to the
corporation via tradition paper method, but preferably is
transmitted in an electronic form compatible with system 100. If
received in paper form, an invoice 185 is scanned so that it is
rendered in electronic form which can be incorporated into system
100 in database 122. The invoice 185 is reviewed by a project
analyst 190 for comparison with the contract and the commitment to
the vendor 180. The invoice 185 then goes through an approval
process by the project manager 195 according to the business rules
for the project as further described below. Once approved, the
payment on the invoice goes through an accounting process 200 in
which the payment is validated and charged against the appropriate
portions of the contract. The payment is then remitted 205 to the
vendor either through a credit to the vendor's Demand Deposit
Account (DDA), via check or via Electronic Data Interchange (EDI)
remittance.
[0039] FIG. 2 has depicted the general process of how a project is
initiated and managed. The remainder of the Figures will illustrate
how system 100 facilitates the initiation management and closure of
the project process. As previously described, the workstations for
managing the project process (120, 125 in FIG. 1) operate in a
windows environment although any other suitable network operating
system (e.g., Unix) can be employed. System 100 includes security
procedures, such as sign-on procedures, as known by those skilled
in the art. FIG. 3 illustrates a typical user interface screen 250
which will help explain the structure and functions of system
100.
[0040] Information concerning projects managed by system 100 are
preferably organized in folders 255 by projects. In a preferred
embodiment, the folders 255 are organized in a tree structure 260.
User interface 250 illustrates one tree structure 260 of a
particular project 270. System 100 contains various predefined tree
views of folders 255 which are selected using list box 265.
Specifically illustrated in FIG. 3 is a tree view entitled "My
Projects" in list box 265. The tree view of "My Projects"
illustrated in FIG. 3 is the standard default view of system 100.
The "My Projects" tree view is most frequently used by project
managers and other support staff. Other tree views access
information in a variety of ways. Other tree views include: a close
out master view that lists all of the closed projects; a major
expenditure plan view that lists all of the major projects; "my"
major expenditure plan view which lists the major projects which a
particular project manager is managing; a personal view that is an
information folder for use by the user to store data for activities
not related to specific projects; a projects by business sector
view that lists all of the projects, sorted by major business
division; a project by facilities division view that lists all
projects sorted by a specific facilities department within the
corporation; a view of projects by location that lists all of the
projects sorted by location; a view of projects by project manager
that lists all of the projects sorted by the project manager
managing the project; a projects being supervised view that lists
all of the projects being managed by the staff of a manager within
the corporation; a view of recently approved documents that lists
all of the documents that a user has approved within a
predetermined period of time (e.g., two weeks); a view of system
tables that lists various categories of system data such as roles,
user profiles, and signing authorities; and a vendor view that
lists all of the vendors sorted by several categories. Although the
above is not an exhausted list of all of the views capable of
creation in the system 100 of the present invention, it is a
preferred list of the views.
[0041] Each of the user interface screens of the system 100 include
toolbars 275, 280 containing icons that provide short cuts to the
functionality of system 100. In a preferred embodiment, the icons
on toolbar 275 are consistent across the user interface screens of
system 100. These icons provide basic functionality to all screens
such as a button for returning the user to default tree view, a
print button which prints the screens, a close button which closes
a screen in which the user is currently operating, a tile up button
that returns the screen to the standard screen format with the tree
view 260 on the left hand portion of the screen and the selected
item on the right hand portion of the screen, and an exit button
that is used to exit the system.
[0042] The icons on toolbar 280 change from screen to screen,
depending on the function being performed by the user. Some of the
toolbar 280 icons illustrated in FIG. 3 include a new document icon
281 that produces a new document menu; a view notes button that
produces a list of all notes created using the notebook feature of
the present invention as further described below; a refresh button
that renews and updates the tree view after completing an activity;
a toggle tree button that toggles between the tree view and a full
screen view of the selected item on the right hand portion of the
screen; and a create note button that activates the notebook
feature of the present invention. The icons on toolbars 275, 280
and other functions of the present invention are accessed using a
standard input device of the user's workstation such as a mouse.
The mouse is used to click on a button to activate a specific
function, to select an item and to drag and drop items of
information.
[0043] As previously described, information is preferably presented
to the user in a tree view 260. The specific tree view illustrated
in FIG. 3 illustrates the folders 255 associated with the project
270. The user illustrated in FIG. 3 only has a single project 270,
otherwise the other projects associated with the user would be
illustrated in the tree view area.
[0044] Eleven folders 255 are shown as being associated with the
project 270. The project directory folder 282 contains a listing of
all of the project team members as well as the project vendors. The
list is populated from database 122 (FIG. 1) as individuals or
vendors are identified on the project. The Request For Assistance
folder 284 contains the approved RFA form as described above. The
budget and funding folder 286 contains all budget worksheets and
funding documents. These documents include a preliminary funding
document, a supplemental funding document and surrogate funding
documents. Project task folder 288 contains the project tasks that
are set up to assign portions of the approved budget to specific
trades (e.g., plumbing) in preparation for creating commitments to
vendors. Commitments by trade folder 290 lists all of the
commitments that have been prepared for a project (including draft,
unapproved and approved commitments). The approved commitments
folder 292 contains all of the approved commitments. The payments
folder 294 contains all approved invoices from vendors for which
payment has been made. The bid documents folder 296 contains all
information related to bids and bid waivers. Each bid listed in
this folder is assigned a unique number for accounting tracking
purposes. Reports folder 298 contains a tracking report with
respect to the project which lists all commitments and payments.
This folder can also be used to store copies of other reports.
Projects attachment folder 300 contains sub-folders for storing
scan documents or electronic files of plans, specifications,
correspondence, schedules and furniture/finishes information for
example. The close out folder 302 contains partial and final close
out information with respect to the project. Again, the above list
of folders 282-302 is not exhaustive and any folders can be created
which suit the needs of the particular project being undertaken or
the corporate system in which the system of the present invention
operates.
[0045] The right hand portion of screen 250 depicts the information
associated with the folder selected on the left hand portion of the
screen. In this particular example, the project 270 has been
selected and accordingly, a profile 304 of the project is displayed
on the right hand portion of screen 250. The project profile 304
contains information related to the category of the project, the
project number, the project name, the location of the project, the
division for which the project is being conducted and the cost
center associated with that division as well as the current phase
of the project. The project profile further includes a brief
project description 306 as well as an area 308 for the project
status.
[0046] Although not specifically illustrated in FIG. 3, every
document within system 100 has its own notebook in which is
recorded comments, issues or status information associated with the
project. The notebook feature can be activated at any time, such as
while preparing a document, during the approval process, or even
after final approval. Notes can be saved generally in three
different categories. A first category is a comment which includes
general notes for the facility staff. A second category of notes is
the status of the project which contains on going project status
information. This status information from the notebook is displayed
in the status area 308 in the project profile area. The final
general category of notes contains specific notes to be published
to other members of the team such as the clients. The published
notes are available to the clients as previously described through
the corporate intranet 130.
[0047] As previously described, the project management process
initiated by a Request for Assistance (RFA). FIG. 4 illustrates an
initial user interface screen 350 for creating an RFA. The RFA is
prepared either directly by a requestor or by a coordinator within
the business unit requiring the project. There are generally two
types of information required on an RFA, requestor information 352
and information related to the project requested 354. The input
screen 350 allows the user to input all of the required information
into an electronic RFA form. In a preferred embodiment, the
electronic form is used for projects over a predetermined dollar
amount (e.g., $10,000). If the project total is less than the
predetermined amount, the user can e-mail the project and requestor
information to the facility staff. The facility staff can then
prepare an internal RFA on behalf of the requester so that the
request can be inputted and managed within the system 100 of the
present invention.
[0048] Once the RFA has been completed, the user saves the document
and clicks on a button (not shown) to send the RFA for approval.
This action brings up a client hierarchy screen 360 illustrated in
FIG. 5. This screen represents one of the unique features of the
present invention. On screen 360, the user is able to identify the
proper personnel required to approve the RFA. In the specific
example depicted in FIG. 5, three separate approvals are required
for the RFA. The first approval is a business unit manager 362, the
second approval by a business unit controller 364 and the final
approval by a business executive 366. Different rules are capable
of being set in the database 122 of system 100 such that depending
on the scope of the project (typically the total dollar amount) the
number of approvals will change. For example, for larger projects
(e.g., above $100,000) a business unit executive 366 will be
required to approve the RFA. In area 368, the user is able to
select the actual person who is fulfilling the role required for
approval. The database of system 100 contains all of the relevant
information with respect to each person in each business unit that
can fulfill each role (e.g., name, e-mail address, title, etc.).
The user can select the appropriate person from a drop down menu by
selecting the down arrow on each box in area 368.
[0049] Once the appropriate people have been selected for the
approval roles with respect to the RFA, the user clicks on the
submit button 370. This action automatically forwards the
electronic RFA to the person fulfilling the role of the first level
of approval required for the RFA. A notice of the pending RFA
requiring approval is added to the workflow list of pending tasks
of the approver. This workflow list is accessed by the approver
using button 375. When activated, this button provides a list of
all of the documents requiring the persons' approval. The approver
is then able to click on the notice which will bring up the actual
electronic RFA document for review by the approver. After the
review is complete, the reviewer is able to type any notes into a
comment area of the RFA document and select one of several actions.
If the approver approves the RFA, the electronic RFA is sent to the
next individual in the approval hierarchy. System 100 enables
electronic signatures as is well known to those skilled in the art.
The approver can also return the RFA for clarifications to the
previous approver or to the requester. Such an action should be
accompanied by the approver including notes in the comment area
which further define the clarifications required. The approver can
also disapprove the RFA which sends the form directly back to the
requestor or client coordinator. Again, if the RFA is disapproved,
the approver should include notes in the comment area including
reasons for the disapproval. Finally, the approver can discontinue
the review of the RFA and come back to complete the review at a
later time. In this action, the notice of the pending RFA will
remain in the approver's work list. If the RFA is approved by the
final approver in the client hierarchy, the form is automatically
routed to a dispatcher in the project management staff. At this
point, the approved RFA is assigned a project number and a project
manager.
[0050] The automatic approval process of the present invention has
several distinct advantages. First, the process is instantaneous.
Once a document has been submitted for approval, notice of the
receipt of the document for approval is immediately sent to the
approver and the document is immediately available for review. This
is in sharp contrast to the prior art method of approval in which
documents typically were rerouted using interoffice mail. Apart
from the delay associated with such a mail system, documents were
often lost or misplaced. Tracking the status of approvals using the
present invention is as simple as clicking on a button on the
user's screen. The prior art required someone to conduct a series
of phone calls, e-mails and personal visits to the approvers.
Another advantage of the approval hierarchy of the present
invention is that it recognized the corporate reality that people
often change jobs, responsibilities, and locations. If such a
change occurs, the database 122 of system 100 is easily modified to
reflect the change. For example, if someone having the role of an
approver is promoted and another person takes over the role, the
database can be easily modified to replace the promoted person with
the successor. Any subsequent approvals will then be automatically
forwarded to the successor. Similarly, if someone having a role is
on a temporary leave or absence, any task assigned to that person
(e.g., approvals) can be easily and temporarily reassigned to a
substitute person.
[0051] Additional functionality provided to the clients of system
100 is the ability to view a list of RFAs for its business unit by
clicking button 378. This button will bring up a window containing
all of the RFAs of the business unit. The list will include the
project name, the date prepared, the status of the RFA and the
status of the funding of the project. In a similar manner, a client
is able to view a list of all of the finding documents by clicking
on button 380. The finding list will display all of the funding
documents for projects on which the user is involved. Once a list
is displayed in the system 100 of the present invention, the user
is able to view the actual documents associated with the item by
selecting the particular item.
[0052] After the approved RFA has been received by the project
staff, one of the first tasks for the project staff is to create a
budget and funding documents for the project. FIG. 6 illustrates a
user input screen 400 for creating budgets and funding documents.
In a preferred embodiment, budgets are created using predefined
templates. Area 402 allows the user to view a list of all of the
budget templates available within system 100. These templates can
either be global (general formats available to all personnel) or
private (i.e., templates that the user has personally created for
his or her own use). Once a template is selected, the template is
displayed in area 403 on the left hand portion of screen 400. In
the preferred construction embodiment of the present invention, the
templates contain three levels of project information, including
individual trades (e.g., lighting fixtures), trade categories
(e.g., electrical) and summary categories (e.g., construction, 404
in FIG. 6). The templates in area 403 can be viewed in the standard
view as illustrated in FIG. 6, or a tree view as previously
described, that shows summary categories in expandable folders.
[0053] Once the template is displayed, the user is able to create
the unique budget for the project in area 406 by dragging and
dropping the items from the template area 403 into the budget area
406. For each item in the budget, the user is required to input the
unit 408, quantity 410 and price 412. Once these items 408-412 have
been input by the user, system 100 automatically calculates the
cost of the item 414. Additionally, system 100 allocates the cost
as a capital item 416 or an expense item 418. System 100
additionally calculates an allowed contingency amount 420 which can
be set in the system as a percentage of the cost (e.g., 10% of the
capital cost). The user is able to increase or decrease this
contingency amount in area 422.
[0054] If the creation of the budget document lasts longer than the
user session, the user can save the budget as a worksheet and come
back at a later time and complete the budget. Once the budget has
been finalized, it is saved in a final form. The budget is then
used to create a funding document that requires approval. The
budget is a very complex and detailed document(s) that potentially
includes hundreds of trades, capital items, expense items, etc.
Rather than have the client and facilities management approve the
very detailed budget, the system of the present invention generates
a funding document for approval. An example of a funding document
is depicted in FIG. 13. The funding document of FIG. 13 was
generated by a template accessing data from the database containing
the budget. It is appreciated that any template can be used to
generate any type or form of funding document desired. As seen in
this Figure, the funding document summarizes the capital items for
the project 700 as well as the expense items 705. These summaries
700, 705 provide the approvers with an overview of the total
spending for the project without the complexity of the details of
the entire budget. Further shown in FIG. 13 are the names of the
approvers of the funding document as well as the dates of the
approval. The funding document indicates approval by both the
facilities department 710 as well as the management of the business
unit 715.
[0055] As previously described with the approval process for an
RFA, the project staff member submits the funding document for
approval which is automatically forwarded to the facilities
hierarchy for approval. Again, the first person in the facilities
hierarchy receives a notice in his or her work list regarding the
funding document to be approved. The same automatic forwarding of
approved documents is follows as described above with respect to an
RFA. Again, if at any level of the approval process the reviewer
denies approval or requests further clarification, the funding
document is automatically returned to the previous approver with
notes in the comments section providing reasons for the disapproval
or the required clarification. Once the funding document has been
approved by all levels of the facilities hierarchy, it is
automatically forwarded to the client hierarchy for its approval.
In a preferred embodiment, the client business unit has a similar
level hierarchy for approvals, depending on the scope and size of
the project. The same approval process is repeated within the
client business unit including automatic forwarding of approved
funding documents. Once the funding document has received final
approval from the client hierarchy, it is automatically forwarded
to the assigned project manager who acknowledges the approved
funding document. The funds are now available for commitments and
the process of managing the project begins.
[0056] With the approved RFA and budget in place, the project
manager is able to begin the actual project management. This
process starts with the project manager generating commitments to
vendors for various aspects of the projects. In the preferred
construction embodiment of the present invention, the commitments
include: architectural/engineering on calls; Purchase Orders; bids;
bid waivers; contracts; change orders; and work orders.
Architectural/engineering on-calls are commitments for on-call
consultant services which typically result in the generation of a
purchase order. A Purchase Order is a commitment for goods,
materials, equipment or services, typically up to a predetermined
dollar amount (e.g., $25,000). In the preferred embodiment,
commitments over the predetermined amount (e.g., $25,000), require
competitive bids. Again, these bids result in purchase orders for
goods, materials and equipment or contracts for the provision of
services. Alternatively, for commitments over the predetermined
dollar amount, biding can be waived pursuant to a special bid
waiver approval process. Work orders are commitments made against a
master contract with a vendor for certain services of any dollar
amount and for other trade services up to a predetermined amount
(e.g., $10,000). Change orders are amendments to previously
approved purchase orders or contracts, either increasing or
decreasing the dollar amount. The change order results in a revised
purchase order or a revised contract.
[0057] The commitments are created against the previously approved
funding and begin with the creation of a project task that assigns
a portion of the approved budget to a specific trade. In order to
create a project task for a commitment, the project manager selects
the new document icon (281 in FIG. 3) to create the task.
Activation of this icon 281 displays a document selection menu
which includes the various documents which the project manager is
able to create. A selection exists for each of the above-identified
types of commitments (e.g., an on-call commitment). By selecting
one of the items, the project manager is required to complete a
description of the project task including the trade, the protocol
for the commitment (e.g., source, bid, waived bid, negotiated,
national contract), the type of commitment (e.g., purchase order,
contract, work order) the tax status of the commitment (e.g.,
taxable, nontaxable) and a detailed description of the scope of
work to perform pursuant to the commitment.
[0058] The project manager is further required to complete a trade
code details section. All of the trade codes that are contained
within the approved budget are displayed (e.g., electrical). The
project manager is able to drag and drop the applicable trades from
the project budget to the trade code portion of the project task.
The project manager then types in the dollar amount for each
applicable trade for the commitment. Once the project manager has
completed the above, the project manager saves the project task and
is then able to generate the actual commitment.
[0059] FIG. 7 illustrates a complete commitment request 450 for an
architectural/engineering on-call. In creating this commitment 450,
the project manager was prompted to enter information related to
the project 455, information related to the consultant (vendor)
460, the scope of the job and the square footage affected and the
fees associated therewith 465, as well as a summary of the funding
and financial commitments 470, both with respect to this particular
commitments and the project in total. Many of the items found on
this on-call commitment were obtained from pull down menus (not
shown) such as the consultant. Other items such as the cost center
to be changed for work performed are provided by system 100 as a
default once the project number is inputted by the project manager.
Once the on-call commitment has been completed by the project
manager, the project manager submits the commitment for approval to
the project staff. As previously described, the approval process is
automatic, with each level of approval being able to approve the
document, disapprove the document or return the document for
clarification.
[0060] In addition to the electronic commitment, system 100
provides the project manager with the capability of scanning in
additional documents that are associated with the commitment or
creating any attachment such as spreadsheets, JPEG files, drawings.
In the preferred embodiment, such attachments are created using
Object Linking and Embedding (OLE) compliant software. Additional
documents attached to a commitment may include proposals from the
consultant or vendor. These attachments are available for review by
the approvers at their work stations by selecting a view menu and
selecting the attachments choice on the view menu (not shown).
[0061] Once an on-call commitment request has received final
approval, system 100 automatically generates a purchase order
number and notifies the project manager (electronically) of the
purchase order number. A hard copy of the purchase order is issued
by the project staff to the vendor. Preferably, the vendor is also
able to obtain an electronic copy of the purchase order through the
Internet interface previously described with respect to FIG. 1. The
purchase order contains all of the basic information contained in
the on-call commitment request as illustrated in FIG. 7. In the
preferred embodiment, when the vendor opens the electronic purchase
order (or other document such as a contract or a change order), the
vendor is presented with a set of appropriate functions. For
example, for contracts, a command button will be provided to Agree
to the terms or Not Agree with an opportunity to comment or create
addendum. The Agree function invokes an electronic signature
process. Some functionality may not be available based on the stage
of a particular process. For example, invoices cannot be created
until a work document has been accepted.
[0062] In the preferred embodiment, records relating to a vendor
remain available in system 100 for a period of at least one year
following the job's completion. Documents the vendor can author
include Bids, RFQs, Invoices, Punch Lists, Lien Waivers and
Messages. Documents the vendor can receive and process with limited
functionality are Request for Proposals, Contracts, Work/Purchase
Orders, Change Orders, Payment Confirmations and Meeting notices.
In this preferred embodiment, the vendor is only allowed to view
documents they authored or documents intended for them. The ability
to delete documents are limited from a vendor's perspective and may
only be allowed depending on the state of a document. This will
provide for a document draft feature prior to posting to the
workflow.
[0063] The generation of a project task for purchase orders is the
same as described above with respect to on-call commitments. FIG. 8
illustrates a request for a purchase order commitment 475 generated
by system 100 of the present invention. The project profile
information 455 is the same as described above with respect to the
on-call commitment. The commitment information 480 includes the
trade involved, the type of commitment (a purchase order in this
example) and the protocol for the commitment. The vendor
information 485 describes the vendor to which the Purchase Order is
to be issued. Again, this information can be input by the project
manager using drag and drop methods previously described from a
master list of vendors for the selected trade. The selection of
vendors can either by from all of the vendors contained in the
system or from vendors with which the corporation has a master
contract. The cost associated with the purchase order is entered in
area 490 and the summary of the financial commitments is again
listed in area 470. As with the on-call commitment described above,
the project manager is able to scan non-electronic documents into
the system for attachment to the purchase order. Once the purchase
order request has been saved, it can be submitted for approval and
proceeds through the approval hierarchy as previously described.
Upon final approval, the purchase order is issued to the vendor
with notification being made to the project manager
electronically.
[0064] A project task for a bid is again created as described
above. Once the project task has been created, the project manager
is then able to create a bid package 500 as illustrated in FIG. 9.
System 100 automatically assigns a bid number 502 to the bid
package as well as assigning the bid status 504 of
"initialization". As previously described, a bid is an object that
can have many documents associated therewith. Each document can
have a separate approval process as described above. There is not
necessarily a one to one relationship between documents and the
object with which they are associated. The trade 506 is obtained by
the system from the information provided by the project manager in
the creation of the project task. The project manager then inputs
the invitation and bid due dates 508 and 510 as required by the
project. The contract type 512 is selected by the project manager
from a pull down menu (not shown). The project manager further
inputs any special instruction in area 514. The bid package total
518 is automatically calculated by the system as the sum of the
tasks 520. The tasks 520 are initially populated by system 100 from
the entries input the project manager when creating the project
task. The project manager can add additional tasks in area 520 that
he or she desires to be bid upon. The task can relate to the same
project number or be associated with different projects, The price
options 522 defaults to a base price, but the project manager can
select alternative pricing options from a pull down menu (not
shown). The documents supporting the bid are listed in area 524 and
include such documents as architectural or engineering drawings as
well as equipment specifications.
[0065] Once the bid package has been saved. The project manger is
provided with a bid package vendor selection screen that allows the
project manger to choose the vendors from which bids will be
requested. Again, the project manager is able to select the vendors
from a list complied from the database 122 in system 100. Once the
project manager has finished selecting the vendors from which bids
will be requested, the list is saved and submitted for automatic
approval as described above. Once the list of proposed bidders has
been approved, the bid package is sent to each of the bidders in
hard copy form and preferably in electronic form.
[0066] Prior to the bid due date, the bidders submit their bid
proposals in response to the bid package. Due to legal concerns, it
its preferable that the bids be opened and witnessed by two and
preferably three witnesses. FIG. 10 illustrates an input screen 550
used for conducting the bid opening. As illustrated in this Figure,
three witnesses 552 are provided. System 100 requires these
witnesses 552 to input their IDs and passwords when conducting the
bid opening. As each bid is open, the information from each vendor
is input into area 554. The vendor name and the price options are
defaulted by the system 100 from the approved proposed bidder list
previously described. The amount 556 is obtained from the vendors
bid and is input into the system by the project staff.
Additionally, the actual bid documents are scanned into system 100
and linked as attachment to the project. Once all of the bids from
the selected bidders have been entered, the bid responses on screen
550 is saved and the bid opening is officially closed. The project
manager is now able to perform an evaluation of the bids.
[0067] In performing the bid evaluation, the project manager
selects the bid documents folder (296 in FIG. 3) to view the
various bids. The bid documents folder contains all of the bids
associated with the selected project. Selecting a modify button
(not shown) activates a bid evaluation screen 560 as illustrated in
FIG. 1l. As seen in screen 560, each of the bidding vendors is
displayed. The project manager is able to enter a qualified price
562 which is either the bid amount submitted by the vendor during
the bidding process or an adjusted amount due to clarifications
with the vendor after the bid has been opened. The project manager
is additionally able to enter any comments on the pricing in area
564 with respect to each of the vendors. The project manger is then
required to rank the vendors in area 566 and provide a reason for
selecting a particular vendor in area 568. If addition documents
have been submitted by the vendors, they can be scanned in and
attached to the data for project as well as other attachment such
as drawings. Once the project manager has completed his or her
ranking 556, the bid evaluation is saved and submitted for
approval. The automatic approval process proceeds as described
above with respect to the approval hierarchy.
[0068] The above has described a process for creating and approving
three types of commitments, namely architecture/engineering on
calls, purchase orders and bids. Similar processes are performed
for the creation and approval of bid waivers, work orders and
change orders. These processes shall not be specifically described
herein, those skilled in the art appreciated how such processes are
accomplished.
[0069] After the commitments have been made to the various vendors
and the work has been completed, the vendors submitted invoices for
the services and materials provided pursuant to the commitments. In
a preferred embodiment of the present invention, the invoices are
electronically transmitted from a vendor workstation 140 (FIG. 1)
through the Internet 145 and the firewall 150 for receipt by system
100. Alternatively, paper invoices may be submitted, scanned and
the data entered into the system either manually or through drag
and drop methods. The project manager reviews the invoice data
contained in system 100 against the scanned copy and makes any
necessary adjustments in the payment amount, retainage,
freight/delivery or tax, based on the actual goods or services
provided.
[0070] FIG. 12 illustrates an example of an invoice data entry
screen 600. After an invoice has been received, the purchase order
number 602, the invoice number 604 and the invoice date 606 are
entered. System 100, using the purchase order number 602,
automatically fills in the commitment information 608 as well as
the vendor information 610. The amount of the invoice including the
material amount, the freight amount and the taxable amount are
entered in area 612. Once the data has been entered on invoice data
entry screen 600, the data is saved and submitted for approval. The
invoice approval process follows the approval hierarchy described
above with respect to the other documents generated by the system.
In a preferred embodiment, if the invoice amount does not exceed
the commitment amount, the project manager alone can approve the
invoice. If the invoice amount does exceed the commitment amount,
the project manager can prepare a change order. The change order
requires approval through the hierarchy and the issuance of a
revised purchase order reflecting the adjusted commitment amount.
Once the invoice has been approved, the payment can be made to the
vendor either through the issuance as by check, crediting of the
vendors demand deposit account, or through other EDI means.
[0071] One further advantage of the present invention is the
automatic nature of the tracking of the accounting information. A
general rule is that any required accounting information (e.g., the
business unit to which items will be charged) is captured by the
system as soon as possible and thereafter carried through
throughout the project. For example, once the client identifies the
business unit to be charged, this identification is automatically
carried into the templates for the project, commitments and
invoices. All documents created from these templates will therefore
automatically carry the identification of the business unit to be
charged.
[0072] As briefly described above, one of the features of the
present invention is the ability to automate the close out process.
The process of closing out a project has historically been an
arduous and manually intensive process. As previously described,
the preferred embodiment of the present invention relates to
construction projects, and the close out process will be described
in terms of this embodiment. The closeout procedures of the present
invention automate the financial transactions associated with the
following two processes: handling of a project's CIP
(construction-in-progress) account balance; and the final closing
of a project.
[0073] The CIP account is a holding account that captures a
construction project's capital expenditures. At the end of the
project, the balance in the CIP account is passed to a fixed asset
(F/A) account for depreciation. Until the asset has been thus
transferred, it cannot be depreciated. After the balance is passed
to a fixed account it starts depreciating thus creating
depreciation expenses for portion of the corporation that is
benefitting from the project. There is no hard requirement for the
construction project to be 100% complete in order to commence
depreciation. Depreciation can start with the payment of the first
invoice with respect to the project. Typically, financial
accounting rules governing construction projects employ an 80%
threshold for commencing depreciation (i.e., 80% of the project
must be complete before depreciation is started). The specifics of
a project might require for the depreciation to be started both
before or after an 80% threshold is reached.
[0074] As previously described, many of the processes of the method
and system of the present invention are driven by the documents
related to the project. The final closing of a project in the
system of the present invention is a system controlled procedure
that starts with automatic examination of various states of the
project documents. As a result of this thorough examination, the
system produces an on-line diagnostics which highlights all
inconsistencies detected by the process. The problems are
categorized and displayed for the project manager.
[0075] The system performs several types functions related to close
outs, including a partial close out, a full close out, abort a
close out and cancel a close out. A partial closeout is a type of
closeout that is done when there is a need to move a portion of CIP
balance to a F/A account. On larger projects, either in terms of
funds and or the period of time for completing the entire project,
having multiple partial closeouts is a very useful function
practical. A full closeout is a type of closeout that is performed
by the project manager only once. After successful completion of
full closeout the project is closed to any further activity
(including commitments and payments). A Cancel closeout is a type
of closeout that is performed by the project manager in a case
where a project was initiated in the system of the present
invention but, before any commitments were issued to the vendors or
any invoices were paid, the decision was made to stop it. An abort
closeout is a type of closeout that is performed by a project
manager when the client requested to stop the project after the
funding was approved, commitments were issued and/or invoices were
paid.
[0076] A trigger built in the system initiates the first partial
closeout for a project when the payment of a particular invoice
meets the 80% threshold. The 80% threshold is with respect to the
entire project. This trigger for a partial close out can be set to
occur with respect to any event that is kept track of in the
system. For example if there are several phases of a project, the
trigger can cause a partial closeout at the completion of a
particular phase. The trigger initiates a workflow process gets
started that opens a closeout session. The system automatically
links all of the paid invoices for the project to the closeout
session created by the trigger. The system also generates a
substantial number (sometimes hundreds) of financial transactions
that will be sent to the General Ledger (G/L).
[0077] The work flow process sends the generated transactions to an
analyst in the financial area. After reviewing the transactions,
the analyst approves the session. This single automated procedure
alone replaces a substantial manual effort (document collection,
data entry, data validation, etc.,) which would take weeks or even
months to complete. The financial analyst can request that the
system start a partial closeout if needed. In the preferred
embodiment, there is no system-imposed limit on the number of
partial closeouts that can be processed by the system.
[0078] FIG. 14 illustrates the close out information that the
system makes available to the project manager. As previously
described with respect to FIG. 3, the tree structure of folders in
the project manager's directory includes a close out folder 800.
Opening the close out folder brings up the screen 802 seen in the
left hand portion of FIG. 14. Close out screen 802 contains six
tabs 805-830 for viewing further information with respect to the
status of the various close outs with respect to a project.
[0079] As illustrated in screen 802 in FIG. 14, the Financial
Summary tab 805 displays a summary of the overall financial status
of the project. Information in area 835 provides identification of
the project, while the information in area 840 summarized the
actual financials. The financial information in area 840 includes
the budget for the project, the amount of the budget that has been
committed, the amount of the commitments that have been paid, the
percentage of the budget that has been paid, the retainage held and
the retainage paid. On this single summary screen 802, the project
manager is quickly able to obtain a summary of the progress, from
the financial point of view, of the project.
[0080] Each of the other tabs, commitments 810, unapproved budget
815, unapproved commitments 820, change orders 825 and invoices 830
respectively bring up screen that detail the status of the subject
matter related to the items associated with the tab. For example,
the commitments tab 820 brings up a screen (not shown) that shows
in detail all of the commitments that were created in the system.
For each commitment, the screen shows the vendor to which the
commitment has made, the category (e.g., construction, move) the
amount of the commitment, the amount paid to date and the remaining
balance of the commitment. The remainder of the tabs 810-830 bring
up similar screens that list all of the items associated with the
tab.
[0081] The folders Closeout Ledger 850 and Partial 860 in the
project manager's tree directory contain further information
related to the closeout status. The closeout ledger folder 850
bring up a screen 900 as illustrated in FIG. 15. This ledger screen
900 includes a summary are 905 and a detailed area 910. Within the
detailed area 910, there is an entry for each of the closeouts
associated with the project. In the particular example depicted in
this Figure, only a single partial closeout has been executed with
respect to the project. FIG. 16 illustrates the details associated
with a partial closeout. Area 950 lists the project information and
the project details are listed in area 955. Area 960 contains the
details as to the G/L accounts to which the items in the partial
closeout were assigned. Area 970 details the different G/L accounts
to which items were posted as well as the depreciation schedule
that is assigned to the items.
[0082] When a project has been completed, the project manager
initiates a final closeout. Again, the full level of automation
associated with the partial closeout as described above is applied
to the full close out. In contrast to a partial closeout though,
additional tests are performed to make sure that no unfinished
business associated with the project is left unattended. For
example, one test is performed to expose any unpaid invoices.
Another test is performed to identify any commitment that is not
fully paid. A further test is performed to identify any credit from
a third party (e.g. a real estate) due to the project that is not
collected. And so on. A full diagnostic of the state of the project
is presented to the project manager in a manner of seconds and a
list of actions required is fully identified. In the prior art
manual process, this undertaking would have required days if not
weeks to complete.
[0083] To close projects that were canceled before they were
started and those that were stopped after they were started, two
other types of closeout processing are performed as previously
described, Cancel closeouts and Abort closeouts. Various tests are
performed by the system to help the project manager to handle these
exceptional conditions correctly.
[0084] Although the present invention has been described in
relation to particular embodiments thereof, many other variations
and other uses will be apparent to those skilled in the art. It is
preferred, therefore, that the present invention be limited not by
the specific disclosure herein, but only by the appended
claims.
* * * * *