 |
Description  |
|
|
BACKGROUND
1. Cross-references to Related Applications
A patent search revealed no patent under the categories, Automatic Project
Management, or under Electronic Mail based Project Management or Groupware
Project Management.
The category Project Management revealed two patents:
(1) U.S. Pat. No. 4,451,067, A Comprehensive Central Scheduling Folder for
Project Management offers a non-computerized method for planning and
tracking projects. This has no similarity with the proposed electronic
network based project management system, as it does not involve computers.
(2) U.S. Pat. No. 4,875,162, An Automated Interface of Design Software with
Project Management Software. The scope of this is narrow, focuses on
design organizations only and involves automatic status update of files
between design software and project Management software. This is not for
general purpose management of multiple work-groups. Also it does not
address the design of a general purpose auto-server for project
management, which will perform automatic project database creation,
project follow-up, multi-project resource planning and project reporting.
2. Field of Invention
The invention described here is the design and application of an electronic
network based project management server system. The product termed in this
application as an `AUTO MULTI-PROJECT SERVER`. The use of the product will
result in an improved organizational process for compiling, tracking and
managing multiple projects within an organization.
The goal of the `Auto Multi-Project Server` is to act as an automated
computer based project coordinator to manage the goals of multiple
organizational work-teams. Activities of the automated computer based
server comprise of collating/compiling project data, flagging
inconsistencies, follow-up with work-team members, obtain updated project
tracking data, communicate project progress to work-team, resolve
inter-project conflicts by re-allocation of critical resources based on
project priorities and generate management reports for flagging time and
cost overruns and critical path information.
Future re-engineered corporations will demand heavy computing needs for
managing large number of work-teams with different project goals,
schedules, dependencies and priorities running simultaneously. The present
techniques for static project-management tools and for limited
project-management groupware technologies will no longer be adequate.
3. Discussion of Prior Art
Presently the following types of project management systems are available:
1. Project planning tools, with software for generating charts such as
Gantt, Pert/CPM etc. Many of the techniques were invented during the
Second World War Majority of project management is perceived as belonging
to this area. These are static standalone tools and do not impose any
particular process in the organization. Organizations have to figure out
methods for input, tracking and report distribution. Typically a project
coordinator is hired by organizations to manually compile input data, run
the tools and distribute progress reports.
Examples: Commercial tools such as PRIMAVERA and MICROSOFT-PROJECT offer
computerized static software approach to planning projects, i.e. a person
has to supervise the input data collection and output report generation,
and there is no automatic process specified by the manufacturer.
A survey of existing project management tools showed no use of electronic
mail or faxing methods to do any automatic creation, updating, planning or
reporting. (Reference: DATAMATION--Oct. 1, 1993, Article: Project
Management Software that's IS friendly, has a survey of the capabilities
of Project Management tools and there is no mention of any automatic
server based tools, driven by electronic messaging.)
2. Group collaboration and Work flow management tools, provide technologies
to automate the flow of documents. These are directed at a wide variety of
needs such as facilitating group conferences, meetings' management,
project database management, information flow control and other custom
mail enabled applications. The tools by themselves do not impose any
organizational process, but offer an underlying technology to build
applications, including the design proposed by this patent.
Example (1): U.S. Pat. No. 5,168,444 for a Work-flow shipment system,
including processing of document images. This is not related to automatic
project management for multiple work-groups.
Example (2) Lotus NOTES is a leading groupware product offering the
necessary technology to build organizational processes including Project
Tracking examples. The system is not designed to handle large
multi-project/multi-priority environments. There is no automatic system
proposed by the manufacturer and it is left for each organization to
design its own process or system of project management.
Example (3) The nearest commercial product design is a product called
SYZYGY from Information Research Corp., which builds on inherent
capability of local area networks (LAN) to tie workers together. The
system has a central database on organizational projects and can be
automatically be programmed by managers to broadcast reminder messages.
(Reference: Personal Computing, Volume 14, Issue 4, Date: Apr. 27, 1990,
Page: 152), The differences I see between this product and the invention
under this patent:
Syzygy is not ideal for managing large or complex projects since it lacks
critical path analysis. The invention under this patent includes a
complete computation engine for computing critical path activities,
Syzygy does not do complex inter-task dependency computations.
Syzygy is not targeted for multiple work-teams with inter-conflicting
priorities.
Syzygy does not attempt any resources leveling or resource re-allocation.
Objects and Advantages
The product in this patent application the `Auto Multi-Project Server`
consists of a centralized automatic project management server software,
based in a computer and accessible via electronic mail or fax messages.
No Programming is involved by people using the system, the `Auto
Multi-Project Server` automatically computes task completion/start dates
and triggers messages based on data mailed to it. Thus the data itself is
used to program the `Auto Multi-Project Server`.
The `Auto Multi-Project Server` reads electronic mail or fax messages, such
as project plans and flags project data inconsistencies. It then compiles
project management data into a usable project database with information to
include details on goals, milestones, budgets etc.
The `Auto Multi-Project Server` follows-up with task leaders on pending
tasks by reminding them on task start and finish dates
The `Auto Multi-Project Server` includes extensive dependency calculations,
such as taking into account complex inter-task dependencies and
start/finish lags between dependent activities.
The `Auto Multi-Project Server` goes beyond just reminding people about
their start and finish dates, it also serves as a project information
system by informing the group team members on their inter-dependencies.
The `Auto Multi-Project Server` includes resolution of multi-project
priorities, which is an essential component for managing multi-groups with
divergent priorities. It allows for example a program or general manager
to examine multiple-projects under his program and assign priorities for
completion. Individual task deadlines and resource usage would be
controlled by the priorities assigned to the completion of the project.
The `Auto Multi-Project Server` will re-allocate critical resources based
on project priorities and re-compute completion dates. The project
database would automatically be updated with the new dates. Thus there is
automatic resolution of priority conflicts. The project leader does not
have to have to constantly escalate issues up the management hierarchy for
resolution.
Security issues are handled by the authorization of ell input mail or
faxes, prior to processing. For electronic mail and faxes the incoming
mail is checked against a valid list of passwords prior to processing.
Also each project is assigned a unique identifier to prevent mix-up of
information between projects.
In summary the `Auto Multi-Project Server` is a necessary requirement for
the needs of future HORIZONTAL CORPORATIONS where the information to
manage multiple projects will be too complex to be done via manual
present-day tools.
Further objects and advantages of my invention will become apparent from a
consideration of the drawings and ensuing description.
DESCRIPTION OF DRAWINGS
FIG. 1--Architecture drawing to show the different components of an `Auto
Multi-Project Management Process`, which is required for implementing the
`Auto Multi-Project Server`.
FIG. 2--Internal architecture of the `Auto Multi-Project Server`.
FIG. 3--Project database example, format to serve as the primary
communication and storage format for information on the different
project(s).
FIG. 4--Build Program Flowchart, to compile together data on
inter-dependent tasks for each project and build a reference database
(with all necessary project information). To compute completion dates
based on resource limits and inter-project dependencies.
FIG. 5--Dependency computation flowchart, to compute task start and finish
dates based on relationship to dependent predecessors.
FIG. 6--Reminder program flowchart, to track pending tasks and remind task
owners on a pre-determined frequency on when to start/finish tasks. To
update task owners on status of dependencies.
FIG. 7--Inform flowchart, to track task completion and inform dependent
tasks on start or finish status of their predecessors, thus acting as a
formal channel of communication eliminating the chance of misinformation.
Also to inform project and task leaders on re-computed completion dates
based on resource re-allocation between projects (based on project
priorities).
FIG. 8--Update flowchart, to update the `build` file with status changes in
task details or task inter-dependencies or inter-project priorities.
FIG. 9--Inter-project priorities and resource allocation flowchart. To
allocate common resources based on inter-project priorities and re-compute
task duration.
FIG. 10--Reports flowchart, to generate project management reports for
reporting progress of projects(s).
LIST OF REFERENCE NUMERALS
FIG. 1
10 Project(s) databases, contains information on the project, also referred
to as the `BUILD` file. Format for this file is shown in FIG. 3.
20 Auto project management server. This software system is the heart of the
process and its workings are explained in the flowcharts contained in FIG.
4 through FIG. 10.
30 Messaging system such as Fax or Email (Electronic Mail)
40 Network Operating System, is a general term used to refer to the
communication protocol used to allow users communicate with the `Auto
Project Server`.
50 Fax, LAN (local area network), WAN (wide area network) or telephone
network is the media for communication.
60 Work-team members communicating to the `Auto Multi-Project Server`,
these may be program managers, project leaders, task leaders etc.
FIG. 2
10 Project updates, module to parse and read project updates,
20 Database updating, module to update the project database with new
information.
30 Database creation, module to open a new database project file.
40 Project data computation, module to compute all project data, (Dates
etc.)
50 Project creation, module to parse and read in project data on new
projects.
60 Project database, centralized complete information on the project.
70 Resource re-allocation, re-assigns critical resources if limit exceeded.
80 Database access, to retrieve task information from project database.
90 Reminder processing, to send out reminders to pending task owners.
100 Inform status, to communicate status of dependencies.
110 Project reporting, to generate and send out project progress reports.
SUMMARY
The design and implementation of an `Auto Multi-Project Server` for
Automatic Multiple Project Management is described in this patent. This
involves a self-running software system running on a central server
computer system with capabilities for automatic data compilation, tracking
and management, handle multiple projects, resolve inter-project resource
conflicts and communicate with users via electronic mail or fax mail.
DESCRIPTION OF INVENTION
FIG. 1 shows the overall process of using the invention in an organization
to manage multiple projects vi an automatic computer server. FIG. 2 shows
the internal architecture of the invention which is an `Auto Mult-Project
Server`.
FIG. 1, Part 10--refers to the set of project database files stored, one
for each project. These files are also referred to as the `build` file.
Refer FIG. 3 for a sample format. This file contains information about the
project, such as the start date and other global information such as the
project leader's name, mail identity, holidays, weekends etc. It also
contains detailed information about each task such as the description,
task leader's name/mail identity, task duration or planned completion
date. In addition it contains information about the dependencies for each
task, in terms of the predecessor task id, the type of dependency whether
FS(predeceseor finishes and task starts), FF(predecessor and task finish
together) or SS (predecessor and task start together), and the lag between
the predecessor and task activities. Finally the database contains
information about which resources, amount of resources and budget for
resources required for doing the task.
FIG. 1, Part 20 is the `Auto Multiple Project Server`. This is a software
system which is the head of the new process. Details of its internal
architecture are contained in FIG. 2. Its workings are explained in the
flowcharts contained in FIG. 4 through FIG. 10. The server is a software
process that runs at fixed intervals (example: at the end of the day) and
performs the task of project management coordination by performing date
compilation, data validation, database update, follow-up reminders to task
leaders, inter-project resource conflict resolution and allocation and
management reports generation on critical tasks and overruns. The main
modules of the server software are described below:
Creation functions consisting of:
Project creation module to read and check for consistency, project data on
new projects. (Component 50, FIG. 2)
Data computation module, to compute completion dates for all activities in
the project based on dependency information and project start date.
(Component 40, FIG. 2)
Database creation, this module creates a new database project file.
(Component 30, FIG. 2).
Project database, holds centralized complete information on the project.
(Component 60, FIG. 2).
Conflict-resolution functions consisting of:
`Resource` module, to check for resource usage and to re-allocate resources
on the basis of inter-project priorities, if resource are limits exceeded.
Project database has to be re-created if resources are
re-allocated.(Component 70, FIG. 2).
Updating functions consisting of:
`Project Update` module, to receive and parse updates from project/task
leaders (Component 10, FIG. 2)
Database updating, module to update the project database with new project
status information.(Component 20, FIG. 2).
Information functions consisting of:
Database access, to retrieve task information from project database.
(Component 80, FIG. 2).
`Remind` module, to send auto reminders to task leaders of pending tasks.
(Component 90, FIG. 2).
`Inform` module, to inform task leaders on completion of dependent
activities. (Component 100, FIG. 2)
Project reporting, to generate and send out project progress reports.
(Component 110, FIG. 2)
The server software system has been implemented in C language, making it
easier to port to different machines and also providing the necessary
performance for handling the largest projects. The server system has to
work closely with the Messaging system and the Network Operating System,
the components of which are described below.
FIG. 1, Part 30--Messaging system is used to refer to the communication
protocol used to allow users communicate with the `Auto Multi-Project
Server`. This has to work under and is closely related to FIG. 1, Part 40
which is the Network Operating System. The network operating system
controls the network operation.
The `Auto Multi-Project Server` has to be configured separately for each
type of messaging system/network operating system. The following are some
of the example environments, they are provided for clarity and do not
exclude other environments:
UNIX mail system running under a UNIX server machine such as a 486 PC,
PENTIUM PC, SUN Workstation, DEC workstation, IBM RS6000 workstation etc.
and communicating to other machines via an electronic network (Part 40).
Users send electronic mail to the server machine on new project
information and status updates, which is processed by the `Auto
Multi-Project Server`. The `Auto Multi-Project Server` in turn sends back
electronic mail reminders and management reports.
Mail system running on a network of PCs'. The mail system may be LOTUS
CCMAIL or LOTUS NOTES or MICROSOFT MAIL etc. The Network Operating System
may be NOVELL NETWARE or VINES or PC-NFS etc.
Fax based communication system, based on fax board inside PC coupled with
OCR software to read fax messages. Here the fax board and software
functions as the messaging system, as well as the network operating
system. The fax system must have automatic transmission, automatic receipt
and optical character recognition capability.
FIG. 1, Part 50 is the communication network, which may be Fax, LAN (local
area network), WAN (wide area network) or telephone network is the
physical media for communication. This is generally transparent for the
`Auto Multi-Project Server`, as it is handled by the Network Operating
System (Part 40).
FIG. 1, Part 60 are the different Project Work-team members communicating
to the `Auto Multi-Project Server`, these may be program managers, project
leaders, task leaders etc. The program manager assigns inter-project
priorities, the project leader creates the first plan for the project and
the task leaders update the project database with progress of project.
Operation of Invention
The `Auto Multi-Project Server` is designed to change the organization
process of planning, tracking and management of work-team projects. The
entire process is planned to be automated with managers focusing only on
the exceptions and crisis situations. I describe below the process of
using the `Auto Multi-Project Server`, as well as the logic used by the
Invention to manage projects.
Step 1--Set up the environment, this involves creating an environment
configuration file with an entry in it to show the command string to be
used in submitting an input file for electronic mail or for faxing it out.
Also the command string to be used in reading an electronic mail or fax,
and the input file name. The environment file is also used to indicate
week-ends, holidays and default reminder frequency and default reminder
window.
In addition a separate file containing authorization information is
required for `project leaders to allow them to create new projects. The
authorization will consist of a list of `user names` and valid passwords`.
The above environment configuration files are the only manual operation and
is a one time operation. These can be performed by a Systems Manager, who
does not require to have any knowledge of `Project management processes`.
Based on the configuration values the appropriate communication procedures
are invoked.
Step 2--The project leader creates a project plan in the format as per FIG.
3. This has information on the project, tasks, dependencies and resources
to be used.
Step 3--The `Auto Multi-Project Server` reads the project plan and invokes
the `Build` Procedure as per flowchart in FIG. 4. The first step is to
validate the user/password and then parse the input for errors such as if
names, descriptions, mail ids etc. are missing. Based on dependencies, the
server computes the completion dates for each task. Completion dates are
based on work-days only, so the software accounts for week-ends and
holidays. Refer FIG. 5--Dependency Comput | | |
