WO2001037145A1 - Computer-based system and method for implementing and managing prjects - Google Patents

Computer-based system and method for implementing and managing prjects Download PDF

Info

Publication number
WO2001037145A1
WO2001037145A1 PCT/US2000/031891 US0031891W WO0137145A1 WO 2001037145 A1 WO2001037145 A1 WO 2001037145A1 US 0031891 W US0031891 W US 0031891W WO 0137145 A1 WO0137145 A1 WO 0137145A1
Authority
WO
WIPO (PCT)
Prior art keywords
project
information
idea
recited
resource
Prior art date
Application number
PCT/US2000/031891
Other languages
French (fr)
Other versions
WO2001037145A9 (en
Inventor
Greg Art
Deborah Penny
Richard K. Lee
Jeff O'halloran
Takashi Mizuno
Kevin Danehy
Cyril Gaydos
Original Assignee
Value Innovations, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Value Innovations, Inc. filed Critical Value Innovations, Inc.
Priority to AU19238/01A priority Critical patent/AU1923801A/en
Publication of WO2001037145A1 publication Critical patent/WO2001037145A1/en
Publication of WO2001037145A9 publication Critical patent/WO2001037145A9/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/06Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling

Definitions

  • Embodiments of the invention are directed to a method and computer system for managing steps of a project development and management process.
  • a project development and management process may involve the progression of an idea from a project idea evaluation step to a preliminary project feasibility step.
  • the project idea evaluation step requires the evaluation of the idea by one or more reviewers for a decision on whether to proceed from the project idea evaluation step to a preliminary project feasibility step.
  • An idea submission document having information fields for capturing information about the idea is stored in a database associated with the system.
  • the idea submission document is provided to the reviewer(s).
  • a decision by the reviewer(s) as to whether the idea should progress from the project idea evaluation step to the preliminary project feasibility step is received.
  • a project definition document having information fields in common with information fields in the idea submission document is stored in the database, the common fields being copied automatically.
  • several additional steps are performed for each of a plurality of sequential action steps and decision steps in a defined series following the project feasibility step.
  • a set of tasks that are to be completed during an action step are stored in the database together with a list of one or more members of a committee assigned to monitor progress of the action step and to perform such review at the subsequent decision step.
  • the database also stores a list of criteria used by the committee to review the project and the tasks performed during the previous action step.
  • the committee is notified of the set of tasks to be completed during the action step, as well as the date and time of a meeting to conduct the subsequent decision step.
  • the decision step comprises the steps of determining whether the set of tasks was completed during the previous action stage, and analyzing the Go/No-Go criteria to determine whether the project should proceed to the next step. In response to determination of the committee, whether progression to the next action step in the defined series has been approved or rejected is stored.
  • one or more of the steps in a project development and management process includes assigning and managing the tasks to be completed to one or more human resources.
  • Each resource has a predetermined role for each task and possesses a set of skills useful in performing that role.
  • Information associated with each resource is stored in a database provided to a computer system. The information includes identification of the resource, roles that can be performed by that resource, and a set of skills possessed by that resource.
  • For each task one or more roles and one or more skills required for completion of that task are established and input into the system. The required roles and skills for each task are compared in the system with the information associated with each resource in order to identify one or more resources for completion of the task.
  • each identified resource has available a full-time equivalent workload and each task is accomplished over a time period made up of time period intervals.
  • Planning information on the full-time equivalent workload is established for each resource for each time period interval as well as the share of the full- time equivalent workload for each time period interval expected from that resource for each task to be completed by that resource.
  • the planning information is stored in the database and is displayed at a display device in order to plan the allocation of resources needed for completion of the tasks.
  • a method for configuring the computer system to a user organization, with information needed from one or more individuals within the user organization.
  • a computer network is provided for connecting the individuals to the computer system.
  • the names of the individuals are stored in a database associated with the system.
  • An electronic message from the computer system is sent over the computer network to the individuals requesting the configuration information. Included in the message is an electronic link may be activated by the individuals in order to provide access to a specific location within the system for entry of the needed information.
  • the computer system in which the methods of the invention may be embodied includes a storage device, at least one input device, at least one display device, a processor, and at least one communications device configured to permit the exchange of data among the other components.
  • Fig. 1(a) is a schematic diagram showing an overview of the structure of an embodiment that provides local access to an innovation management system
  • Fig. 1(b) is a schematic diagram showing an overview of the structure of an embodiment that provides access to multiple organizations to an innovation management system
  • Fig. 2 is a flow diagram illustrating the interconnection between decision steps and action steps within the system
  • Fig. 3 is an example of a home page that may be presented to users in accordance with an embodiment of the invention.
  • Fig. 4(a) is an example of a search page that may be presented to a user
  • Fig. 4(b) is an example of a page containing links to company documents
  • Fig. 4(c) is an example of a page containing scheduling information
  • Fig. 4(d) is an example of a page containing reports of project status
  • Fig. 4(e) is an example of a page containing legal statements
  • Figs. 5(a) and 5(b) illustrate an example of an idea-submission form that may be presented to an idea submitter for completion
  • Fig. 6 is a flow diagram illustrating how the system obtains and processes an idea submission
  • Figs. 7(a), 7(b), 7(c) and 7(d) illustrate an example of a project definition form that may be presented to a project leader for completion
  • Fig. 8 is a flow diagram illustrating how the system obtains and processes a project definition
  • Fig. 9 is a flow diagram illustrating various options provided by the system with respect to resource records
  • Fig. 10(a) is an example of a user registration that may be completed by a user
  • Fig. 10(b) is an example of a page that can be used to approve a new user registration
  • Fig. 10(c) is an example of a new-resource form that may be presented to a user
  • Figs. 10(d) and 10(e) illustrate an example of a page from which various resource-maintenance actions may be taken by a user
  • Fig. 10(f) is an example of a form that may be presented to a user to allocate resources to projects;
  • Fig. 10(g) is an example of a resource summary that may be presented to a user
  • Fig. 10(h) is an example of a chart that can be used to graphically illustrate resource allocation
  • Fig. 11 is a flow diagram illustrating how the system is configured during system setup
  • Fig. 12(a) is an example of a page illustrating the initiation of system setup
  • Fig. 12(b) is an example of a page further illustrating the initiation of system setup
  • Fig. 12(c) is an example of a page used for entry of general company information during system setup
  • Fig. 12(d ) is an example of a second page used for the entry of general company information during system setup
  • Figs. 12(e) through 12(g) are examples of a pages used for entry of division, business unit and market segment information during system setup ; ⁇
  • Fig. 12(h) is an example of a document that may be used for division, business unit, market segment project budgeting
  • Fig. 12(i) is an example of a page used for entering Project Hurdle Rate information during system setup
  • Fig. 12(j) is an example of a page used for entry of process facilitator information during system setup
  • Fig. 12(k) is an example of a page used for entry of field categories during system setup
  • Figs. 12(1) and 12(m) are examples of pages used for establishing Gate Review Board information during system setup
  • Figs. 12(n) and 12(o) are examples of pages used for establishing Go/No Go Criteria, an Agenda, and a Purpose for each decision step during system setup;
  • Fig. 13 is an example of a page illustrating a project's menu.
  • Fig. 14 is an example of a page showing a list of projects
  • Fig. 15 is an example of a page showing categories in which projects may be classified
  • Fig. 16 is an example of a page showing a project classified under the "Assign Project” category
  • Fig. 17 is a flow diagram illustrating how the system manages a decision step process
  • Fig. 18(a) is an example of a page showing a list of projects
  • Figs. 18(b)-18(d) illustrate an example of a project definition page
  • Fig. 18(e) is an example of a page showing project information at a decision step
  • Fig. 18(f) is an example of a page showing Gate Review Board Purpose
  • Fig. 18(g) is an example of a page showing Gate Review Board meeting information
  • Fig. 18(h) is an example of a page showing project value to business information
  • Fig. 18(i) is an example of a page showing a decision step Go/No-Go criteria
  • Fig. 18(j) is an example of a page used to enter a Gate Review Board decision
  • Fig. 19 is a flow diagram illustrating how the system manages an action step process
  • Fig. 20(a) is an example of a page showing project information at an action step
  • Fig. 20(b) is an example of a page showing defined purposes of an action step
  • Fig. 20(c) is an example of a page showing action step tasks
  • Fig. 20(d) is an example of a page a project team leader can use to enter a project recommendation
  • Fig. 21 is a flow diagram illustrating how the system configures, assigns and manages tasks within an action step
  • Figs. 22(a)-22(b) illustrate an example of a page showing task details
  • Figs. 22(c)-22(d) illustrate an example of a page a team member may use to accept or decline an assigned task
  • Fig. 22(e) is an example of a page that can be used to schedule task reminders; and Fig. 22(f) is an example of a page showing task history details.
  • Embodiments of the present invention are directed to a method and system for managing steps of a project development and arrangement process.
  • project refers broadly to any good, service, or decision making process. While the description below relates generally to goods or services that are offered (for sale or otherwise) to customers, the invention more broadly includes goods or services that may be exchanged within an organization. For example, an organization's internal procedure that may be improved falls within the scope of a project and is treated as such according to the invention. Moreover, decision making processes, such as a venture capital firm deciding to fund a company, are covered under the definition of project. An overview of the structure of the system in different embodiments is shown schematically in Figs. 1(a) and 1(b). Fig.
  • an innovation management system 100 is configured to be accessed by any of a plurality of users from individual stations 110. In the example shown, any of thirteen stations may be used to access system 100. Such access may be direct, as for stations 110-1 through 110-4, or may be through a local network 112, as for stations 110-5 through 110-13.
  • System 100 uses storage devices 102 for the storage of relevant information, which may be retrieved or updated as necessary.
  • Storage devices 102 may include any suitable storage device, for example, optical or magnetic storage media, such as disks or tape.
  • information may be provided to system 100 by the user, perhaps through a local network 112, or may be retrieved from system 100.
  • System 100 updates the information that is received from users and automatically manages the flow of information for the project management process.
  • FIG. 1(b) An alternative physical structure for using system 100 is shown in Fig. 1(b), in which multiple individual organizations 130 (shown schematically with the dashed boxes) are provided with access to system 100 through a network such as the internet 150.
  • system 100 may act as an application service provider to organizations 130.
  • each organization 130 may have its own internal network 120 that connects various user stations 124.
  • Each internal network may have access to one or more local storage devices 122, while system 100 retains access to its storage devices 102, and depending on the particular configuration, also may have access to storage devices 122.
  • information peculiar to a particular organization 130 may be stored locally while information that is more universally used by system 100 may be stored elsewhere.
  • the setup of system 100 is based on a hierarchical scheme within each organization.
  • an organization may include a four-level hierarchy based on divisions, business units, and market segments. The company or organization itself is the highest of the four levels.
  • This hierarchical scheme additionally may be reflected in access limitations to the system, with individuals at only certain levels in the organization being authorized to view and/or edit certain information in system 100.
  • a manager responsible for a given market segment could have access to projects in system 100 related only to that market segment.
  • a manager responsible for a certain business unit could have access to all projects in all market segments within that business unit.
  • a division manager could have access to all projects that fall within the purview of any business unit within that division (including all market segments).
  • Certain individuals within the organization may be superior to the entire hierarchical scheme (for example, a chief executive officer or president) and will have access to all of the projects within the organization without regard to the hierarchy. Others who may be given such wide access may include other executive managers, the organization's process coordinator, a system administrator, or the organization's patent counsel.
  • access by individuals who wish to submit ideas to system 100 is neither scrutinized nor authenticated, without requiring a login and password, but access by all other individuals is scrutinized by requiring a valid login and unique password.
  • the system implements a systematic series of two-part steps for following a project from its conception to complete development to introduction into the marketplace to inventory obsolescence in some cases .
  • the first step of each pair of steps (sometimes referred to as a "gate") requires that a designated group of individuals (which may be different for each market segment) approve continued development of the project.
  • a group is referred to herein as a "Gate Review Board” (“GRB") and may be chaired by a "Gate Review Board Chair.”
  • GRB Gate Review Board
  • the composition of the Gate Review Board and the Gate Review Board Chair may differ according to the division - business unit - market-segment hierarchy and/or according to how far the project has progressed through the series of two-part steps.
  • Each GRB has criteria by which each project under its consideration must be evaluated prior to making the determination regarding whether or not to authorize the project's continuance.
  • the second step of each pair has criteria by which each project under its consideration must be evaluated prior to making the determination regarding whether or not to
  • stage sets forth a predetermined set of tasks that should be carried out before proceeding to the next gate.
  • the GRB criteria is applied to the information obtained during the execution of the predetermined tasks, thus enabling the GRB to make the determination regarding whether or not to proceed with the project.
  • a failure to perform tasks at a given stage or to receive the required approval at a given gate may result in termination of further development of that project.
  • the system includes a series of systematic conditions that should be met in a progressive way to develop the project fully.
  • Fig. 2 presents a flow diagram summarizing this procedure.
  • Fig. 2 illustrates the process as it may be configured for five two-part steps. In alternative embodiments, the process may be configured for a different number of two-part steps.
  • the process begins with an idea 200 for development of a project. Ideas may originate with anyone inside the company, with customers, or with vendors. Once the idea is memorialized on a form within management system 100, the entire process of decision and action steps is automatically initiated and regulated. Each of the decision steps 202, 206, 210, 214, and 218 in the overall process proceeds in much the same fashion. A meeting is conducted among appropriate individuals to determine whether the business opportunity presented by the idea is attractive and consistent with the business's strategic direction. If so, the action plan for the next action step 204, 208, 212, 216, or 220 is evaluated, modified as necessary, and approved. Such approval includes earmarking appropriate funding and resources to complete the action plan for the next action step.
  • the decision-making power may be vested in a single individual so that the process proceeds in the same manner, but without actually having a meeting for each decision step. More generally, there is no requirement that the individuals who contribute to each of the decision steps be the same. Indeed, it may be preferable to vary the composition of the meeting to reflect the different emphases that each of the decision steps has.
  • Each of the decision steps after the first i.e. steps 206, 210, 214, and 218, builds on tasks performed and information obtained from the preceding action step.
  • the manner in which this information is used is illustrated schematically in the dotted box labeled 226.
  • the results of the tasks performed in the preceding action step are evaluated in step 230 to determine whether the established criteria for proceeding to the next action step have been met. If those criteria have been met, the next action step is approved in step 236. If the criteria have not been met, they are examined more closely in step 232.
  • a determination is made, based on information obtained from the previous action step, whether a revision in the previous action plan would allow the criteria to be met.
  • the plan is revised accordingly in step 234, so that the question whether the criteria have been met can be revisited at step 230 after completing the previous action step in accordance with the revised plan. If, even with the information available from previous action steps, it is determined that the criteria cannot be met, the project may be terminated and archived at step 238. Also, if it is determined that certain criteria cannot be met at that given time, the project may be put on hold for a period of time.
  • Fig. 2 provides an example of how the series of individual decision and action steps may be configured, although other configurations may be tailored for individual organizations.
  • An idea 200 is subjected to an initial evaluation at step 202 where it simply is determined whether the certain basic criteria are met: (1) whether the idea is consistent with the organization's strategic direction; (2) whether the idea appears to be technically feasible; and (3) whether successful implementation of the idea is likely to exceed established hurdle rates.
  • Hurdle rates refer to performance criteria established by the organization that should be met or exceeded upon commercialization, and may be based on such factors as net present value (NPV), market size, market penetration, gross margin at maturity, etc.
  • hurdle rates may differ for different project categories to which the idea may be assigned.
  • Examples of such project categories may include breakthroughs, product platforms, new products, new processes, line extensions, or technical services, among others.
  • the appropriate hurdle rates for evaluating an idea may depend on its classification in such a project category to reflect the different risks and expectations that the organization attributes to different project categories.
  • An assignment of the project category may be solicited from the originator of the idea, may be assigned by those who attend the idea evaluation meeting 202, or may be assigned by someone else within the organization.
  • the usual objective of the first action step 204 is to perform a cursory investigation of the technical, liability, and marketing aspects of a project idea.
  • the intention at this stage is to use inexpensive activities, such as library searches, concept renderings, and discussions with potential key users of the project to assess market size, potential, and acceptance.
  • the cursory technical assessment involves gathering information concerning the proposed project's feasibility in being developed and manufactured, including likely timeframes and costs. Possible technical, legal, and regulatory roadblocks and associated risks also may be identified.
  • This technical and marketing input permits a preliminary financial analysis to be included in a business plan and presented during the subsequent decision meeting 206.
  • This business plan is an important input to second decision step 206, in which the results of the previous cursory investigation 204 are evaluated. This evaluation of the cursory results is intended to take a deeper look at the idea to confirm that the technical, marketing, liability, and commercial risks of the project are manageable. If it is determined that they are, requirements are defined precisely in second action step 208.
  • This requirements definition step sometimes referred to as the "homework” step, is where the project team begins to specify and document the project, develops the preliminary plan for its marketing, and determines the resulting benefits expected to accrue to the organization upon its commercialization.
  • the business plan is augmented so that specific elements of it include a definition of the customer needs, wants, and preferences ("requirements"), and identifies specific features and benefits to be incorporated within the project design to meet these requirements.
  • the business plan also includes analyses of the resulting target market and positioning strategy, with a review of competitive products for services and customer responses to preliminary concepts. It incorporates technical considerations, such as the feasibility of incorporating further requirements into an economically viable solution. If the project is a "product,” the investment and cost to manufacture the product are investigated, and a schedule for the cost of goods sold, estimated capital costs for a pilot production line and full-scale manufacturing facility may be generated. A thorough legal and regulatory assessment is undertaken to identify risks and to formulate a plan for their effective management.
  • the business plan also includes a detailed financial analysis consisting of pro forma income statements, balance sheets, discounted cash flow, and sensitivity analyses.
  • a detailed project plan all the way through commercialization may also be developed from the precisely defined functional requirements.
  • This detailed business plan forms the basis for making the decision whether to develop the project that is made at third decision step 210.
  • This decision provides the last point at which a project may be terminated before relatively significant funds have been spent. If, after considering the detailed business plan, a decision is made to proceed with the project, a full multifunctional project team, typically including representatives from research and development, marketing, manufacturing, quality, regulatory, and finance departments is put in place and empowered with the appropriate authority to bring the project deliverable to market.
  • This project team undertakes development of the project at third action step 212.
  • This step is marked in particular by the implementation of the development plan, including the development of the physical product in those instances where there is to be a physical product.
  • customer input continues to be obtained to confirm and refine the design.
  • plans for production and market launch are also refined at this point.
  • Legal, patent, and regulatory issues are resolved. Improved estimates for costs of goods sold and capital costs for the pilot and full-scale manufacturing plants are generated.
  • Deliverables at the end of this step include a fully tested prototype of the product, including engineering specifications and documentation, test and validation plans to be implemented at action step 216, detailed marketing and operational plans to be implemented during action step 220, and a refined financial analysis based on additional information obtained during step 212.
  • a period of testing and validation is carried out at action step 216.
  • This step is intended to verify and validate several features about the product: its viability, including its acceptance by customers; the process by which it will be manufactured and distributed; and updated financial prospects, including, for example, pro forma income statements, balance sheets, and cash flows.
  • Typical activities undertaken to achieve such verification and validation include laboratory tests of a pilot manufacturing process to check the product for quality and performance, as well as field trials to confirm the product function, including packaging and labeling, under actual use conditions.
  • the pilot production validates the effectiveness of the production process to be used and may be used to refine production cost allocations.
  • a trial sale to test the product launch plan and better define the estimated market share may also be undertaken.
  • results of this testing and validation step are used in a final decision step 218, where the project can still be terminated if those results fail to meet established criteria.
  • the decision at this pre-launch review focuses in particular on the expected financial return of the product's introduction to the market. In addition, the suitability of operations and marketing plans, as evidenced by the results of field trials, may also be taken into consideration. If final approval is given at this decision step, commercialization of the product is fully launched at action step 220. Both the operations and marketing plans previously developed are implemented as the product is introduced into the marketplace. As a result of the systematic review that the product plans have undergone through this process, there is a good likelihood that the product will be successful in the marketplace and realize a profit for the organization developing it.
  • innovation management system 100 includes a number of features, some of which are described in detail below and some of which will be evident to those of skill in the art after reading such description. Such features are described with reference to a particular exemplary computer-based embodiment, although the invention is not restricted to that embodiment and those of skill in the art will recognize that the features may be incorporated into other computer-based embodiments.
  • the system is accessed through a web browser and presents a series of screens on which users can access system 100.
  • Navigation through the system may be accomplished through hyperlinks, in which another aspect of system 100 is accessed by selecting the hyperlink so that another page is presented to the user.
  • navigation may be accomplished with a menu-driven system, in which dropdown menus are presented to the user for selection of particular aspects of system 100.
  • a combination of hyperlinks, drop-down menus, drag-and-drop icons, and other suitable web-based technologies may be used.
  • One such embodiment that uses a combination of hyperlinks and drop-down menus is shown in Fig. 3. The view shown in Fig.
  • FIG. 3 represents a view of a "Home" page, on which various information about development projects and the allocation of an organization's resources to those projects is presented in summary form.
  • the home page may identify an organization 302 described by the summary information and the date 304 that the summary information was generated.
  • Other information 330 about system 100 also may be provided.
  • the hyperlinks provided at the bottom of the page may appear on every page presented by system 100 to provide a consistent navigation scheme that is readily recognized by the user. Such hyperlinks may include, among others: (1) a "home" hyperlink 350 for immediate navigation to the page shown in Fig.
  • FIG. 4(a) is shown a sample search page that may be used with the system 100 to search for the occurrence of terms that may appear in any document maintained by system 100.
  • Various search schemes may be provided, from those that use simple Boolean rules to those that use complex fuzzy-logic algorithms.
  • a plurality of search schemes are provided, perhaps linked to one another with hyperlinks, to accommodate different user skill levels and/or requirements.
  • Fig. 4(b) is shown an example of a page on which various company documents may be stored. Such documents may vary between different organizations, and may include statements and memoranda that define the company's policies with respect to product development or other issues.
  • documents maintained on this page may include business plans, financial plans, product design guidelines, etc.
  • One feature that is illustrated in Fig. 4(b) is the use of right-pointing triangles 382 and downwards-pointing triangles 384 to represent information in a compacted form.
  • Right-pointing triangles 382 indicate that a list of documents defined by the associated heading may be displayed by activating the triangle. After the triangle is activated, it is presented as a downwards-pointing triangle 384 and the list of available documents is presented.
  • Such triangles may be used on other pages within system 100 and function in the same manner.
  • a given document may be accessed by activating a hyperlink associated with the document.
  • Fig. 4(c) illustrates a calendar that may be provided, indicating when any meetings related to a project are scheduled, whether they be associated with action steps or decision steps.
  • the view shown is a weekly view, although daily, monthly, yearly, or other views may be provided. Hyperlinks are used to access preceding or subsequent time periods.
  • Fig. 4(d) illustrates a page that may be used to present reports summarizing the status of various projects. The reports may be organized in different fashion, for example by project leader, by division - business unit - market-segment categorization, by funding authorization, by current action/decision position, or otherwise.
  • project status is summarized by current action/decision position, with each project identified by how far along it is in the process outlined with respect to Fig. 2.
  • Fig. 4(e) provides an example of legal statements, such as copyright notices and disclaimers, that may be provided with system 100.
  • the main portion of the page referred to as the
  • “Innovation Score Board” 340 provides a snapshot summary of the status of projects and their relationship to allocated resources.
  • This summary information may include a project listing 318, which identifies each of the projects, their current action/decision position, whether the project is on time with a scheduled time-line, and the fraction of the project that is complete.
  • Each project listing may be hyperlinked to a more detailed description of the project or its related parts thereof.
  • System 100 may use various methods for determining the fraction of the project that is complete, such as by averaging the current number of completed action steps and decision steps to be completed in the process, by a weighted average of the number of defined tasks that have been completed, by comparing total expenses to what has been authorized, or otherwise.
  • the summary information also includes a resource designation 320, which indicates the total number of personnel full-time equivalents (FTEs) exist, how many are in use and how many are available. Such information indicates how efficiently project personnel are being assigned and how much unused labor remains available for allocation to projects within an organization.
  • An idea summary 326 indicates the total number of ideas that are active, have been archived, or have been submitted on the current day.
  • All of this summary information may be tailored, in certain embodiments, according to the position of the user within the division - business unit - market-segment hierarchy.
  • the summary information may be directed to the organization as a whole, with all projects and their status listed and resources in use and available derived for the organization as a whole. If instead the user is responsible only for a particular market segment, only the projects for that market segment will be displayed and the resource summary calculated for only that market segment.
  • the summary information may be calculated appropriately for that intermediate position.
  • login and password security features can be used to allow or limit access to the different projects within the system and editing capabilities in the system.
  • Other information provided within the "Innovation Score Board" may include direct hyperlinks to help information 316, a project calendar 322 that summarizes when decision-step meetings and team meetings are scheduled. In alternative embodiments, this information may be further customized to include summary information or hyperlinks to other aspects of the system 100 as may be desired by an individual organization.
  • At the top of the page shown in Fig. 3 are five drop-down menus that are also used to navigate through the system: (1) "Ideas" 306; (2) “Projects” 308; (3) “Resources” 310; (4) "Setup/Admin” 312; and (5) "Help” 314.
  • the drop-down menu under "Ideas" 306 thus may include a link to a page for submitting a new idea and may include links to pages that summarize existing ideas sorted according to criteria such as date, the identity of the idea generator, or the division - business unit - market-segment categorization. Such links may be designated to provide a summary only for active ideas, only for archived ideas, or for a combination of active and archived ideas.
  • the drop-down menu under "Projects" 308 is accordingly similar. One link in the drop-down menu may be for defining a new project while other links may be to pages summarizing existing projects, designated as active, archived, or including both active and archived projects.
  • the menu links may be more specific, such as by including links to particular pages in which the projects are sorted according to the division - business unit - market-segment categorization, by project leader, or by current (if active) or last (if inactive) step within the progression defined in Fig. 2.
  • the drop-down menu under "Resources” 310 may include links designed to administer records relating to personnel, their skills, their availability, and how they are assigned to different projects.
  • entries in the drop-down menu may include a link to a page for creating a personnel record for an individual, in addition to including links that summarize existing personnel records, such as by skill set, name, role, or location.
  • the drop-down menu under "Setup/ Admin" 312 may include links to pages that are used for configuring the system to operate according to the structure of the organization.
  • the pages accessed from this drop-down menu are used to configure an organization by defining organization information, specifying the division - business unit - market-segment hierarchy according to the actual classifications used in the organization, and defining the action and decision step criteria for proceeding through the process defined in Fig. 2.
  • the drop-down menu under "Help” 314 may include links to information that describe the system, such as a glossary of terms, training materials, frequently asked questions (FAQs), and other explanatory information.
  • Figs. 5(a) and 5(b) This page represents one embodiment of an idea-submission form 500 and permits the entry of information in a specific format to define the idea and permit system 100 to initiate various functions for evaluating the idea.
  • Fig. 5(a) is the top portion of idea-submission form 500
  • Fig. 5(b) is the bottom portion of the form.
  • Certain fields within the form may be mandatory while others may be optional.
  • An attempt to submit an idea form that fails to fill in a mandatory field will result in it being rejected and prompting the submitter to complete at least all of the mandatory fields.
  • Such mandatory fields may be marked in some way on the form to identify them clearly to the user, such as denoting them with an asterisk, displaying them in a different color, or otherwise.
  • Email field 508 is a mandatory field because system 100 relies on electronic communications to and among individuals to implement the product development process according to the invention.
  • Other mandatory fields may include an "Idea Name” field 510 and an "Idea Type” field 512, in which the submitter both provides an identifying designation for the idea and specifies the product category to which (he believes) the idea should be classified.
  • Such product categories may be defined individually to meet the needs of a particular organization, although system 100 may also include certain default categories:
  • Breakthrough a product that is new to the world and has not been marketed by any other organization
  • Product Platform a combination of designs and technologies that may be used to create a family of products that share those designs and technologies;
  • New Product a good or service that is new to the organization but has previously been marketed by at least another organization
  • New Process a new method for producing a product that is already being marketed by the organization
  • Line Extension a modification to one of the organization's existing products
  • Specification of the product category may affect how system 100 handles the idea submission, in terms of who it is directed to, and how it affects the applicable hurdle rates.
  • the product category may be used in developing certain summary information provided by system 100 to describe the allocation of funds and resources within the organization.
  • Further mandatory fields are provided for categorizing the product to which the idea is directed according to the organization's hierarchical structure.
  • a division - business unit - market-segment hierarchy there is a "Division” field 514, a "Business Unit” field 516, and a "Market Segment” field 518.
  • These fields, and the "Idea Type” field 512 may be structured with drop-down menus (shown with the arrowhead in Fig. 5), or these fields automatically may be populated by the system based on the division - business unit - market segment within which the idea submitter is employed.
  • Free-form mandatory fields 520 and 522 are provided for the idea submitter to describe the idea and how it will benefit the organization.
  • a mandatory check-box field 524 also may be provided so that the idea submitter can characterize the benefit to the organization according to predetermined criteria, such as increasing sales, reducing costs, and/or increasing quality.
  • a free form field 526 may be provided to allow the idea submitter to make any other relevant comments relating to the idea.
  • a field 530 may be provided for specifying ad hoc collaborators. When system 100 sends notifications related to the idea, it may send them to individuals specified in field 530, in addition to individuals that system 100 has determined at field 528 will be notified in light of the other information entered by the submitter.
  • the form also may be configured to permit the attachment of files at field 532.
  • External files may be made part of the idea submission by using the "Browse” 534 and "Attach File” 536 functions to search for appropriate files and to attach them to the submission.
  • the "Submit” button 540 is activated to submit the idea to the system 100. If the submitter wishes, he may also activate a "Print Idea” button 502 to produce a hard-copy record of his submission.
  • Fig. 6 The logical flow of the idea-submission process is summarized in Fig. 6.
  • the system 602 prepares the idea-submission form 500, such as described with respect to Fig. 5, for completion by the submitter. Both mandatory and optional information is obtained through the form interface at step 604.
  • system 100 determines at step 608 whether the mandatory fields have been completed. If not, an error message is displayed at step 612 and system 100 returns to step 604 to obtain the additional information. If the "Submit" button 540 has been executed with all mandatory fields completed, system 100 performs two parallel functions. First, it returns to step 602 to prepare another idea-submission form 500 for completion. System 100 also sends notifications at step 610.
  • the content of such notifications includes all the information that was entered by the idea submitter into idea-submission form 500.
  • the content of each notification is tailored according to the role of the recipient in the process.
  • One recipient may be a process facilitator, who is an individual trained in shepherding ideas from their conceptual stage until a project team leader has been assigned.
  • the facilitator may assist idea generators in completing idea-submission form 500, and may direct them to appropriate resource personnel within or outside the organization so that adequate information may be gathered and documented.
  • the assigned facilitator may vary according to the division - business unit - market-segment hierarchy, so system 100 will direct the notification according to how this information was entered on idea-submission form 500.
  • System 100 also may send a notification to the Gate Review Board Chair(s) who is responsible for presiding over the first decision-step meeting for the defined division - business unit - market-segment categorization of the idea, and perhaps also to each of the members assigned to that Gate Review Board.
  • System 100 may further notify the authority- line supervisor(s) of the idea generator(s), obtaining the identity of such individuals automatically by accessing company organization records.
  • anyone identified in the form as a potential collaborator also may be notified of the idea submission.
  • system 100 may be configured to notify a patent attorney or patent agent of the idea submission.
  • idea-submission form 500 may additionally include fields for inputting information of particular relevance to patent- application filings, such as the dates of conception, actual reduction to practice, public disclosures, or offers for sale.
  • fields may be provided for attaching any available files that describe relevant prior art.
  • System 100 may further notify the individual who developed the idea, as input into field 506, that the idea has been submitted. That individual's supervisor may also be notified that the idea has been submitted, with system 100 extracting information regarding supervisory positions from personnel records.
  • system 100 automatically generate one or more documents for the first decision-step meeting, which may include a Gate agenda and a report for completion by the Gate Review Board members.
  • Such an agenda may include reviewing the completed idea-submission form 500, discussing the criteria for approving the idea as a project, deciding whether to approve the idea as a project, and, if approval is given, staffing and funding the project up to a certain point.
  • An example of a Gate agenda and a report form suitable for completion at such a meeting is provided in the Provisional Application at pages 45 - 47.
  • agenda items can be defined in the "Setup/ Admin" portion of the system. 4.
  • system 100 If the idea is not approved as a project, a notation is made in system 100 that the idea is to be archived and it will be included in summaries that system 100 may produce describing archived projects/ideas. If the idea is approved as a project, however, information defining the project is input into system 100. Some of the information describing the project may be extracted automatically from idea-submission form 500. Other information results from the first decision-step Gate Review Board meeting and is therefore input after that meeting. It also is possible that projects may be entered into system 100 without having originated as ideas. This may happen, for example, when system 100 is adopted by an organization that already has an active research effort, so that existing projects are entered into system 100 when it is acquired.
  • a project definition form 700 that may be presented to a user is shown in Figs. 7(a) - 7(d).
  • the project number includes fields for a project name 710, project type 712, division 714, business unit 716, market segment 718, project submitter 706 and the email address of the project submitter 708, which correspond generally to the similarly named fields included on idea-submission form 500. While these corresponding fields may usually have the same entries as input on idea-submission form 500, system 100 is sufficiently flexible to allow them to be redefined in the project definition form. Such redefinition may correct a manifest error made by the idea submitter or may represent a more subtle correction that the Gate Review Board has introduced after its deliberations to account for various unanticipated considerations.
  • project definition form 700 also may include mandatory fields to identify a project leader 738, a project team 740, a description of the project 720, as well as who authorized the project 754 and who authorized funding for the project 756. Some or all of these fields automatically may be populated by system 100 based on the division - business unit - market segment within which the project is classified. There also may be various optional fields, such as a project start date 758, a project's position within the product-development scheme 742, goals and objectives of the project 744, an expected launch date for the product 748, an expected manufacturing startup date for the product 748, and a date a post-implementation review of the product is to be completed 760.
  • a project start date 758 a project's position within the product-development scheme 742, goals and objectives of the project 744, an expected launch date for the product 748, an expected manufacturing startup date for the product 748, and a date a post-implementation review of the product is to be completed 760.
  • Fields may be included for additional comments 726 and for the attachment of key documents 732 by using the "Browse" 734 and "Attach File” 736 functions in the same manner as described with respect to idea-submission form 500.
  • the form includes a field for a project reference number 704, which is assigned automatically by system 100 as described below. Buttons to print a copy of project definition form 702 and to submit the completed form 762 are included as on the idea-submission form.
  • system 100 prepares a project definition form 700 into which the information described above with respect to Fig. 7 may be input.
  • System 100 determines at step 804 whether the project to be defined corresponds to a previously stored idea. If so, information from the stored idea-submission form 500 that corresponds to fields in project definition form 700 is extracted from the stored idea-submission form 500 and preloaded into project definition form 700, where it may be modified if necessary as described above.
  • Information defining the project is obtained at step 808, such information may include a combination of mandatory and optional data as described above.
  • step 810 execution of the "Submit" key 762 is detected, at which point system 100 ascertains whether all mandatory fields in product-submission form 700 have been filled. If not, system 100 displays an error message and allows the user to enter additional information. If all mandatory fields have been completed, system 100 both returns to step 802 to prepare another project definition form and proceeds to assign a project number at step 814 and to add the now-defined project to the system at step 816.
  • resources may refer generally to personnel resources such that system 100 maintains a record of personnel identities, their skills, and their assignment to projects. There may be more than one way for resource records to be introduced into system 100.
  • system 100 uses user registration information to create the resource records automatically.
  • an individual will complete a user registration form when he requests general access to system 100.
  • An example of a user registration form is shown in Figs. 10(a) and 10(b), with Fig. 10(a) illustrating the top half of the form and Fig. 10(b) illustrating the bottom half.
  • the registration form includes fields that are useful in identifying the resource and his or her skills.
  • Such fields may include first 1002, middle 1004, and last 1006 names, a system user name 1008, the resources location 1010 and business unit 1012, a contact phone number 1014, and email address 1016, a supervisor 1018 and his email address 1020, resource skills 1022, one or more roles that the resource will perform 1024, 1026, and a login password 1028.
  • the user registration form illustrated in Figs. 10(a) and 10(b) may include a field 1030 that allows a supervisor to approve the registration information.
  • the form after the information is entered on the form, the form automatically is forwarded to a supervisor for review. The supervisor can modify the form as need and then accept it using field 1030.
  • a resource document is automatically is created by system 100 on behalf of the user.
  • a resource document may be created using the "New Resource" function described below.
  • Fig. 9 provides a flow diagram 900 involving various aspects of resource- maintenance functions that may be performed by a user. Since the functions are constructed to be interconnected, flow diagram 900 illustrates a path that may be followed by executing a "New Resource" function from the Resources drop-down menu 310.
  • Figs. 10(c) - 10(h) show examples of several pages that may be presented to a user as he executes the resource- maintenance functions. Accordingly, in the discussion below reference is made interchangeably to the figures so that the effect of functional aspects shown in Fig. 9 may be illustrated with the exemplary pages presented to the user in Figs. 10(c) - 10(h).
  • system 100 responds by preparing a new-resource form 900 at step 902.
  • An example of the new-resource form 900 is shown in Fig. 10(c). It includes fields where the user may select or enter a resource name 1032 and a default role 1034 for the resource.
  • the resource information already was entered into system 100, and new- resource form 900 only is used to select particular resources and the associated role.
  • new-resource form 900 can be used to enter in a new-resource not previously defined. In accordance with this aspect of the present invention, if a non-defined resource is entered at this page system 100 automatically will cause a resource definition to be displayed.
  • the default role 1034 field is used to define the particular function that the resource normally fills in the product-development scheme. If a resource has more than one role, the user can select the desired role using this screen. Default roles 1034 may include, for example, a Gate Review Board Chair, a Gate Review Board member, an idea generator, a line manager, a process coordinator, a process facilitator, a project team leader, a project team member, or a system administrator, among other possibilities. Skill sets are used to define the known capabilities of a user and typically are defined during the resource registration process, but can be modified at any time.
  • Skill set information generally includes an identification of both the skill that the resource possesses, as well as a designation of the resource's proficiency at that skill. Identified skills may include technical skills, administrative skills, financial skills, etc. In accordance with one embodiment of the present invention, resource skills can be categorized at three levels, approximately corresponding to beginner, intermediate, and expert levels of proficiency.
  • New-resource form 900 includes a "Print Document” button 1035 and a "Submit” button 1036, used respectively to print a copy of the document and to submit the completed document to system 100.
  • system 100 obtains information used to define the resource.
  • certain of the fields may be mandatory and some may be optional. Accordingly, after system 100 detects that the user has executed the "Submit" button 1036 at step 912, it determines at step 914 whether all of the mandatory fields have been completed. If not, an error message is displayed to the user at step 916 and the system again seeks to obtain more complete information describing the resource.
  • Resource-allocation form 960 is similar to new-resource form 900, but includes additional information.
  • resource-allocation form 960 includes a menu from which further resource maintenance functions may be performed.
  • the menu includes buttons for assigning a project 1044, refreshing the project list 1046, and viewing a workload graph 1048.
  • System 100 monitors for execution of one of these menu selections at step 920 and responds accordingly.
  • Resource-allocation form 960 additionally includes a "Print Document" button 1040 for producing a hard copy of the page, a "Submit” button 1049 for activating other aspects of system 100, and a resource table 1042, which is described in further detail below.
  • project- assignment form 970 may be generated by system 100 in a separate window from the resource-allocation form so that resource table 1042 may be consulted easily while completing project-assignment form 970.
  • Project-assignment form 970 includes fields for defining the name 1050 of the resource, the role 1052 the resource will have in the particular project, and an identification 1054 of the project. The purpose of project-assignment form 970 is to use these fields to define the specific role a resource will have in a given project and to provide an estimate of how much time the resource will spend on the project.
  • the role 1052 may be changed to suit the particular project.
  • project-assignment form 970 includes a project- workload table 1032. This table is used to provide an estimate of the fraction of the resource's time that he is estimated to devote to the project over the next several months, broken down on a monthly basis. In alternative embodiments, this information may be broken down in a different manner, such as by monthly or daily, depending in part on the complexity and scope of projects to be handled by system 100.
  • the workload information is entered into project-workload table 1056 as a percentage of a full-time equivalent (FTE) person.
  • Project- assignment form 970 also includes a "Print Document" button 1060 for producing a hard copy of the form and a "Submit” button 1061 for execution when the form is complete.
  • system 100 collects this project-assignment information at step 924 and waits to detect execution of the "Submit" button 1061 at step 926.
  • system 100 updates resource records at step 928 and returns the user to the resource-allocation form 960 shown in Fig. 10(b).
  • the information collected in project- workload table 1056 is incorporated here in resource table 1042.
  • Resource table 1042 summarizes the time allocation of each resource maintained by system 100, defining all the projects to which each resource has been assigned and showing a monthly (or other, in alternative embodiments) breakdown of each resource's assigned workload over the next several months.
  • the total workload assignment for each resource is summed over all assigned projects so that a user can readily identify which resources are completely allocated, and therefore unavailable for further workload allocation, and which resources remain available for additional allocation.
  • This breakdown of resource availability is configured so that it is possible to identify specific monthly windows in which individual resources may accommodate further assignments or particular months in which a resource is overloaded.
  • a user such as a project leader, thus may easily correlate the planned needs of a project with available resources to fill those needs.
  • system 100 also monitors at step 920 for execution of the "View Workload Graph" button 1048.
  • system 100 may prepare a graphical display of the resource table 1042 information, showing the allocation of resources to particular projects in the form of a histogram or other graph.
  • the histogram may show an individual's allocation over time, may compare the allocation of different individuals, and may summarize the allocations to a particular project, among other summaries that may be generated by system 100.
  • An example of a graph that may be produced is illustrated in Fig. 10(h).
  • System 100 also monitors at step 920 for execution of the "Refresh Project List” button 1046. This feature is provided to recognize that many users may be accessing the system at any given time and assigning resources to projects. A given user may execute the button to have the system update the information presented in resource table 1042 at step 930 so that the user is accessing current information.
  • system 100 When system 100 detects at step 920 that the user has activated the submit button 1049 or a suitable "View Resources” button (not shown), it presents a resource display 980 such as shown in Fig. 10(g), in which available resources are identified, together with their default roles and designated skill sets. Ready access to this additional information permits the user to make appropriate project assignments.
  • the information shown in resource display 980 also may be accessed directly from the "Resources" drop-down menu 310, and may be organized according to resource name, default resource role, or skill sets, depending on how the user wishes to access the information.
  • resource table 1042 may be simplified in one embodiment to show a restricted set of resources, such as those that have already been identified as team members of a particular project, to simplify the display.
  • Various additional fields may be used when appropriate for certain organizations to define the resources more discretely, such as by their geographical location within the organization, their skill levels, or other criteria that may be of use in their allocation to projects.
  • Setup and Administration has several purposes: (1) facilitate the configuration of system 100 by a system administrator in accordance with the overall organizational structure and processes of a company;
  • system 100 In order to configure system 100, a system administrator or other suitable user first enters basic information about the company and its processes. Then, the system administrator may provide the names of individuals within the company who can provide additional information, particularly information related to levels of the corporate structure below the overall company level (i.e., information related to divisions, business units and market segments). System 100 automatically will notify those individuals (in the preferred embodiment, through automatically generated email messages or other notification means, such as burst messages or the like) to provide the needed information.
  • Table I shows information that may be provided to system 100 at the highest corporate level (e.g., by a systems administrator, or the like).
  • Table II shows information that may be provided by individuals at the division level
  • Table III shows information that may be provided by individuals at the business unit level
  • Table IV shows information that may be provided by individuals at the market segment level.
  • the information in Table I may be entered by the systems administrator, with input from senior corporate management.
  • the information in Tables II, III, and IV may be entered by individuals at the division, business unit and market segment levels, respectively, with such individuals named by the system administrator during system setup.
  • Fig. 12(b) if setup information has been entered previously by the system administrator, that information is indicated by listings or links appearing as "Setup Documents" 1206 - 1214. A user can access the previously entered information by selecting the appropriate link for the Setup Document 1206 - 1214.
  • button 1205 is activated, screen 1216 in Fig. 12(c) is displayed and the system administrator is prompted to enter general configuration and company information at step 1104 (see Fig. 11).
  • screen 1216 prompts the user to enter various information about the company, such as the name of the company's Process Coordinator (field 1228), the name of the company's Patent Counsel (field 1230), information on the number of gates and stages in the overall process (field 1232), and the number of months after product launch that a Post Implementation Review (PIR) document is to be created (field 1234).
  • the system administrator under the section entitled "Slalom Start Page Customization" 1236, can enter information for screen graphics. That is, the system administrator can customize the stylized headers and related content that will appear on each page or screen of the system, to provide an appropriate company name or brand identity to the system.
  • the "Company Setup" button 1220 is activated and the Company Setup screen 1238 (Fig. 12(d)) appears.
  • Company Setup screen 1238 the system administrator can enter company information, such as the company name (field 1240), and the names of individuals that can provide company top level New Project Strategy (field 1242), R&D Investment Data (field 1244), Project Hurdle Rates (field 1246) and overall Company Strategy (field 1248).
  • the system administrator may have such information or may need to consult with senior management as necessary to obtain the most current information available for entry.
  • system 100 can be configured so that information can be collected, stored, classified and reported to the management personnel within the company at the organizational level to which it most closely relates.
  • the system administrator can use a series of screens (initiated by activating the "Divs/BUs/MSs" button 1222 to enter information defining an organization's divisions, the business units under each of those divisions, and the market segments into which products are sold by each business unit. The entry of this information collectively is represented by steps 1106, 1108 and 1110 in Fig.
  • steps 1106, 1108 and 1110 in Fig. 11 may be configured as a "looped" sub-process, such that setup does not move on to the next step in Fig. 11 until all division, business unit and market segment information is entered by the system administrator.
  • screen 1258 in Fig. 12(e) is displayed.
  • the system administrator or other user can enter the names of each of a company's divisions by selecting the "Create Division" button 1251. The user then is provided a screen (not shown) to enter division information. Once entered, the divisions are listed in field 1252.
  • the system administrator selects one of the divisions listed in field 1252, and then activates the "Create a Business Unit" button 1254, which causes the Business Unit Setup screen 1258 illustrated in Fig. 12(f) to be displayed.
  • the user can enter information about each business unit associated with the selected division.
  • the division field 1260 automatically may be populated with the division name. However, the division field 1260 also is modifiable, for example by using a pull down menu or by manually entering a division name.
  • Business unit information may include the name of the business unit (field 1262), the names of individuals that can provide new Project Strategy (field 1264), R&D Investment (field 1266), Project Hurdle Rates (field 1268) and Business Unit Strategy (1272) for the business unit, as well as the R&D budget (field 1270) for the business unit.
  • the "Submit" button 1274 on screen 1258 is activated to save the information.
  • the Business Unit Setup screen can be used to enter information about each business unit in an organization.
  • the system administrator then returns to screen 1250, selects a particular division and business unit, and then clicks the "Create a Market Segment" button 1256.
  • Screen 1276 in Fig. 12(g) is displayed, and the division name (field 1286) and business unit name (field 1288) are automatically populated with the division and business unit selected on the screen 1250.
  • the division name (field 1286) and the business unit name (field 1288) can be manually entered or amended by selecting names from a pull-down menu, or by manually entering the names.
  • field 1290 Other information about a market segment that may be entered on screen 1226 to include the market segment name (field 1290), and the names of individuals that can provide Product Strategy (field 1292), R&D Investment (field 1294), Project Hurdle Rates (field 1298), and New Market Segment Strategy (field 1300).
  • screen 1276 may include an R&D Investment Template button 1296, which when selected, will cause an R&D Investment report or spread sheet 1302 (Fig. 12(h)) to be displayed.
  • R&D spread sheet 1302 can be used by project personnel to make budgeting and Go/No-Go decisions.
  • system 100 also may be configured to interface with a company's accounting or Enterprise system in order to track and manage budgeting and expenditure numbers. After the system administrator finishes entering data for each market segment, the system administrator then can activate the "Process Facilitator” button 1282 shown on Fig 12(g). The "Process Facilitator” button 1282 causes screen 1304 in Fig. 12(i) to appear.
  • Process Facilitator information may include name, address, phone number, fax number, email address, etc.
  • the system administrator or another user can select "Hurdle Rates" button 1284, to enter project hurdle rate information into screen 1306 shown in Fig. 12(j).
  • field category information may include information such as Project Categories (field 1310) and Resource Skills (field 1312).
  • the system administrator may select default field categories that are provided with system 100, or the system administrator may create and enter company specific field categories during the configuration setup.
  • users develop categories that are more appropriate for their company, or for the individual divisions, business units, or market segments within the company, the system administrator can return to Product Category Setup screen 1308 illustrated in Fig. 12(k) to add and/or modified the categories.
  • the user can activate the "Submit” button 1314 to save the changes.
  • the system administrator may select the default categories for some of the items, and then enter unique and company-specific categories for other items.
  • various individuals named during setup to provide Project Strategies, R&D Investment and other information also can be asked to review the defaults and change them as appropriate for their particular division, business unit or market segment. Tables V below illustrates example default Project categories and Table VI illustrates example default Resource Skills Categories that may be provided with the system.
  • the exemplary resource skill defaults listed in Table VI may be appropriate for information- technology products. Other products may have other technical skill defaults appropriate for those products.
  • the Gate Review Board (“GRB”) information can be configured for each gate or decision step for each market segment (step 1118).
  • the system administrator selects the "GRB Setup” button 1280, which brings-up GRB Setup screen 1316 illustrated in Fig. 12(1).
  • the GRB setup screen can be unique for each market segment, making system 100 configurable to the market segment level.
  • each of the five gate review boards 1318 (recall that this number was established earlier by the system administrator at step 1104) can be selected, and the "Edit GRB Gate Setup Doc” button 1320 is used to display a GRB information entry screen for each of the GRBs.
  • a GRB information entry screen 1322 is illustrated in Fig. 12(m).
  • GRB information such as the GRB chairperson and members can be entered for the selected GRB.
  • Screen 1322 can be used to edit existing GRB setup information or add new GRB set up information.
  • authorized individuals such as a GRB Chairperson
  • gate go/no-go criteria should be entered (Step 1124 in Fig. 11).
  • the "Go/No Go Defaults" button 1226 can be activated.
  • the Gate Go/No-Go Criteria Setup screen 1324 (Fig. 12(n)) is displayed.
  • "Go/No Go” Criteria, Agendas and Purposes may be entered.
  • system 100 may be preloaded with generic Default "Go/No-Go" Criteria, Agendas, and Purposes as illustrated in the screen in Fig. 12(n).
  • a user may select the "Create Go/No-Go Criteria” button 1326, which causes screen 1328 illustrated in Fig. 12(o) to be displayed.
  • "Go/No-Go" Criteria can be created or modified so that it is associated with particular divisions, business units, market segments, stages and gates.
  • information such as element category, sub-element name, criteria name, criteria number, and criteria details also can be entered.
  • system 100 is designed to conveniently collect information through the use of emails.
  • emails or other types of messages automatically can be sent to each of the individuals named in the setup process as having information needed for system setup.
  • the emails or messages may include appropriate links to particular screens in system 100, so that those individuals can conveniently enter the necessary information.
  • An email to that individual is generated automatically after the system administrator completes all of the entry of data during setup at step 1128.
  • the email may include a link to screen 1304 illustrated in Fig. 12(g).
  • the email may be configured to instruct the individual to activate the "Hurdle Rates" button 1284 in Fig. 12(g) in order to display the screen illustrated in Fig. 12(i) for entering the Hurdle Rate information.
  • the data After the individual enters the data in Fig. 12(j), and then clicks the "Submit" button, the data automatically is saved in system 100.
  • a similar process can be used to request other individuals in an organization to provided necessary data.
  • a reply email automatically is generated by system 100 in order to notify the system administrator.
  • a report (not shown) can be generated periodically to show any outstanding requests for data, and to send appropriate reminders if the requested data is not being submitted within required time frames (steps 1130 and 1132 in Fig. 11).
  • the initial configuration of the system is complete at step 1140 and system 100 is then ready for use.
  • a user can access the "Projects" pull-down menu 1350 illustrated in Fig. 13.
  • active and archived projects can be grouped and viewed by business, project leader, and current stage.
  • Fig. 14 illustrates a screen 1402 listing projects by business
  • Fig. 15 illustrates a screen 1502 listing stages into which projects can be group. For example, ideas can be grouped into a pre-project stage, or projects can be grouped into a decision stage or an action stage.
  • Security features may be implemented within system 100 to limit access to that information using any of several standard methods known to those of skill in the art. Such access limitations may be based, for example, on the role that a individual has with respect to a given project or with system 100 as a whole. Thus, in one embodiment, access to data for a specific project is limited to the project team leader or members, the Gate Review Board members, the process coordinator, the process facilitator, the system administrator, and the information-technology manager. In other embodiments, access may be provided according to different criteria as appropriate for the organization.
  • system 100 also may be configured to link directly to a variety of standardized tools and information. Such links may be configured so that fields from within system 100 are imported directly into such standardized tools to act on idea or project data.
  • the standardized tools and information may include, for example, a company accounting or enterprise resource system, financial analysis spreadsheets, project plan templates, business plan templates, test request forms, company standard operating procedure documents, quality assurance test method documents, manufacturing production method documents, product drawings and specifications, training material, glossary to company terms, etc.
  • Fig. 17 comprising a flow diagram illustrating the process.
  • the first decision step typically is the decision to convert an idea into a project, to hold the idea, or to archive the idea.
  • system 100 automatically generates "Gate 1" documents and information to be used in the "Gate 1" decision step.
  • "Gate 1" documents may comprise an idea document as discussed above, as well as “Gate 1" information and other supporting documentation that may be helpful for Gate Review Board (“GRB”) members to make a decision on whether or not to proceed with a project.
  • GBB Gate Review Board
  • external documents may be attached in the same manner described above for the idea-submission form 500 and project definition form 700.
  • system 100 As a project progresses from an action stage to a decision stage, system 100 generates documents/information to be used in the decision stage.
  • Information generated and maintained by system 100 may include project (or idea) information, a Stage form, a GRB purpose and agenda, GRB meeting information, information noting a value that a project may have to a business, key deliverable documents, Go/No-Go Criteria, etc.
  • the amount and type of information available at a decision step will vary based on the stage a project is in. For example, when a project is in the idea or pre-project stage, only a little information may be available. However, if is project is toward one of its final stages, such as manufacturing, much more information may be available.
  • Go/No-Go criteria will be unique to each decision stage based on the governing division-business unit-market segments in which the project resides.
  • a Stage/action step documents/information 1926 for the next Gate/decision step.
  • step 1702 in Fig. 7 Gate/decision step documents/information are provided or made available to members of a GRB. Once the documents/information are created, one or more members of the GRB (preferably the chairman) are notified that the project now is in a decision step. Members of the GRB then can edit the documents as needed (step 1704).
  • the notification to the GRB members may comprise an email with a hyperlink to the associated decision step documents.
  • the members of the GRB can access the decision step documents through the "Projects" pull-down menu 1302, as discussed above. For example, as illustrated in Fig. 18(a), by selecting a project 1802, a Project Definition page
  • FIGs. 18(b) - 18(d) By selecting hyperlink 1804, documentation and information relevant to the GRB review process can be accessed.
  • Figs. 18(c)-18(j) illustrate screens that can be used to access and edit the decision step documentation.
  • decision step information and documentation may include project information (button 1808), GRB purpose and agenda information (button 1810), GRB meeting information (button 1812), business value information (button 1814), hurdle rate 1816, key deliverable documents (button 1818), Go/No-Go criteria (button 1820), and GRB decision information (button 1822).
  • project information button 1808
  • GRB purpose and agenda information button 1810
  • GRB meeting information button 1812
  • business value information button 1814
  • hurdle rate 1816 hurdle rate 1816
  • key deliverable documents button 1818
  • Go/No-Go criteria button 1820
  • GRB decision information button 1822
  • screen 1807 in Fig. 18(e) is displayed.
  • the user can view and/or modify information about the project, such as project number 1824, project name 1826, project type 1828, project leader 1830, project start date 1832, division 1834, business unit 1836, market segment 1838, and expected product launch date 1840.
  • system 100 preferably automatically populates these fields when the project document is created. However, as one skilled in the art will appreciate, as a project progress through the development process, some of the information may need to be changed. Thus, system 100 allows users to modify certain project information as needed. To modify certain information, however, the user must have the proper security access.
  • GRB meeting purposes and agenda information To access GRB purpose and agenda information, a user selects the "GRB Purpose and Agenda" button 1810, which causes screen 1842 in Fig. 18(f) to be displayed. Using screen 1842, the user can review, add to, or modify the GRB meeting purposes 1844 and the GRB meeting agenda criteria 1846.
  • GRB meeting purposes and agenda information originally can be defined during the Setup/ Admin procedure and later reviewed or modified as needed by GRB members during the GRB review process.
  • system 100 allows a company to define default GRB meeting purposes and agendas for each decision step, but also allows the GRB members to deviate from the default entries as they deem necessary.
  • a GRB member can schedule a GRB meeting.
  • the user selects the "GRB Meeting Info" button 1812.
  • the user can modify the GRB chair field 1850 and the GRB member field 1852.
  • the user can define GRB surrogates or proxies 1854, a GRB recorder 1856, a GRB meeting date 1858, a GRB meeting time 1860, and a meeting place 1862.
  • the user can select the "Set Date" button 1863, which will display a pop-up calendar.
  • Figs. 18(e) - 18(g) may be mandatory fields. Therefore, after a user selects the "Submit" button, system 100 will verify that all mandatory fields are entered (step 1706 in Fig. 17). If information is not entered into the mandatory fields, system 100 will send an error message, and the user is prohibited from continuing until the fields are entered. When all mandatory fields are completed, system 100 then will send the notification to the GRB member with the accompanying documentation and information (steps 1708 and 1710). Upon receiving notification of the meeting, GRB members are given the opportunity to confirm or deny the date and time of the meeting (step 1712).
  • Confirmation may occur by selecting an "Accept Meeting” button (not shown) on the notification email. By selecting the "Accept Meeting” button, an automatic confirmation is sent to user scheduling the meeting. Similarly, if the scheduled meeting conflicts with a GRB member's schedule, he may deny the meeting and then provide alternative dates and times that will work for him. Once it is determined that the meeting needs to be rescheduled, the GRB Recorder or GRB Chair can reschedule the meeting by selecting a "Reschedule Meeting” button (not shown). The user scheduling the meeting can use the information regarding alternative dates and times provided by the conflicted member(s) to help schedule a new meeting date and time.
  • system 100 may send out a meeting reminder notification, such as by email, of the meeting's date, time, and place to all those who should attend. Similarly notifications may be sent at other times appropriate for reminding members of the scheduled meeting, such as one day prior to the meeting and one hour prior to the meeting.
  • the GRB holds its meeting to make a decision on whether or not to proceed with the project (step 1714).
  • members of the GRB can designate key deliverable documents and attach them to the project definition.
  • a user selects the "Attachments" button 1818, which causes a screen to be displayed listing all of the attached documents.
  • the user can browse for and attach documents to the project that reside anywhere on a company network.
  • the members of the GRB typically analyze the
  • Go/No-Go criteria to determine whether the company should proceed with the project in question.
  • the Go/No-Go criteria can be access by selecting the "Go/No-Go Criteria" button 1820, which causes screen 1882 illustrated in Fig. 18(i) to be displayed.
  • the Go/No-Go criteria 1884 for the particular decision step is listed.
  • check boxes 1886 for checking off the criteria when it has been met are check boxes.
  • the members of the GRB will review the criteria as a group and determine if it has been met. If so, a user, for example the GRB recorder, will check boxes 1886 on screen 1882.
  • the Go/No- Go criteria for each decision step are defined during the setup process.
  • One embodiment allows members of the GRB, if they feel the criteria should be modified or additional criteria added for a particular decision step, to use screen 1882 to make the modifications.
  • the members of the GRB can discuss the value the product may be to the company. Such information can be review, added and/or modified using screen 1864 illustrated in Fig. 18(h), which can be accessed by selecting the "Value to Business” button 1814.
  • Estimated financial information available on screen 1864 may include first year net sale 1866, first year gross margin 1868, net sales at maturity 1870, gross margin at maturity 1872, internal rate of return (“IRR") 1874, return on investment (“ROI”) 1876, net present value (“NPV”) 1878, as well as any other suitable financial information. As one skilled in the art will appreciate, some financial information may be difficult to predict during the early stages of a project.
  • the members of the GRB attach all relevant deliverable documents to the project and make financial value determinations.
  • System 100 automatically generates additional documents during these steps (step 1716 in Fig. 17).
  • the GRB determines whether or not to proceed with the project to the next stage of action step (step 1718).
  • the GRB members determine whether the tasks from the previous action stage were performed properly and whether all of the Go/No-Go criteria have been met, and they review the relevant financial considerations.
  • the GRP can decide to proceed with the project, hold the project or archive the project. If the GRB decides to hold or archive the project, system 100 automatically will conduct the proper steps to hold (step 1721) or archive (step 1720) the project.
  • system 100 if the GRB members decide to proceed with the project, system 100 generates documents to be used in the next action stage and then notifies team members that the project is proceeding (steps 1722 and 1724). In addition, system 100 also may automatically notify the original generator of the idea that led to the project that a decision has been made regarding the project. The supervisor of the idea generator also may automatically be notified of the decision.
  • a user selects the "GRB Decision” button 1822.
  • the GRB members can enter information, such as the next step in the product development process 1890 and 1892, a "hold until" date 1894 (fi the project is being held), a new project leader 1895 (if changing), a budget amount for the next stage or action step 1896, a stage expense account number 1897, comments 1898, and additional documents (not shown).
  • members of the GRB can tell the system to archive the project, hold the project, go to the next stage or action step, or return to the previous stage or action step.
  • system 100 automatically will populate field 1892 with the next stage or action step number. For example, in the illustrated embodiment, the project currently is in the second decision step or gate. Thus, if the project is approved to go to the next stage, Stage 2 will be populated into field 1892. Similarly, if "Go to Previous Stage” is selected, Stage 1 will be populated into field 1892. In one embodiment, as with other fields in the system, the user can override the default number entered in field 1892.
  • the user can proceed by selecting the "Submit” button 1899. This either will archive the project, hold the project, or cause it to proceed to the next stage or action step.
  • Fig. 19 the process of managing a stage or action step and associated tasks is illustrated.
  • an action step document automatically is generated and project team members are notified of the progress of the project (step 1902).
  • a user can edit the stage or action step document (step 1904).
  • Fig. 18(a) once a project goes from a gate or decision step to a stage or action step, the project is classified under the "Stage in Progress" list.
  • a project definition and information page 2002 is displayed (Fig. 20(a)).
  • the "Project Info" page 2002 (button 2004) automatically is displayed when a project is selected.
  • System 100 automatically populates these fields when a GRB approves a project at the gate or decision step.
  • an authorized user e.g., a project leader
  • stage or action step purposes In addition to project information, a user can view and modify stage or action step purposes, value to business information, default business plan tasks, key projects and project leader recommendations.
  • stage or action step purposes the user can select the "Stage Purposes" button 2006, which causes screen 2034 illustrated in Fig. 20(b) to be displayed. This screen lists the purposes 2036 of the particular stage or action step.
  • stage or action step purposes are defined during Setup/ Admin, but, with the proper security access, users can add and modify the purpose using this screen.
  • the task list page 2038 shows a list of default task 2044 that can be defined during setup, as well as a list of assigned tasks 2044. Tasks can be assigned to certain individuals by editing a default task 2044 or by creating and assigning a new task. Previously defined tasks can be modified by "double-clicking" on the task or by highlighting the task and selecting the "Assign Task” button 2047. New tasks can be created and assigned by selecting the "Create a Task” button 2046. Details of creating, editing, and assigning tasks will be discussed in more detail below. Screen 2038 also may include counter 2040 showing the number of opened assigned tasks.
  • a user e.g., a project leader
  • system 100 monitors the process to ensure that all tasks are assigned (step 1908).
  • one or more users can manage the task performance process (step 1910).
  • an individual performing the task or the project leader can mark the task as complete, for example by entering a check in a check-box 2048 on task list page 2038, or by modifying the "Task Assignee Detail" as discussed below.
  • the project leader can make a recommendation to proceed to the next stage, to return to the previous stage, or to archive the project.
  • This recommendation can be generated using screen 2050 illustrated in Fig. 20(d), which is accessible by selecting the "Project Leader Recommendation" button 2014.
  • the project leader can recommend that the project proceed to a particular stage (see fields 2052 and 2054).
  • the project leader can enter comments (field 2056), and attach documents that may be useful in the next gate or decision step (field 2058).
  • Relevant documents may include a business plan, financial information, Go/No-Go recommendations, a project plan for the next stage and beyond, etc.
  • a user also can access value to business information by selecting button 2008 and other attachments by selecting button 2012. Value to business information and attachments operate in the same manner as discussed above with reference to decision steps or gates.
  • system 100 After the project leader enters his recommendation, system 100 automatically finalizes the stage or action step documents (step 1914) and notifies the next GRB that the stage is complete (step 1915). System 100 then determines if the project is in the last stage (step 1918). If not, system 100 automatically generates the documents need for the next gate or decision step (step 1924) and proceeds to the gate or decision step (step 1926). If, however, the project is in the last stage, system 100 automatically schedules a product implementation review ("PIR") and generates documents for the PIR (step 1920) at a time interval defined in the Setup process. In addition, system 100 automatically will notify the necessary parties of the PIR (step 1922) in order to complete it and close the project.
  • PIR product implementation review
  • Figs. 21 and 22(a) - 22(f) the process of assigning and managing tasks will be described.
  • the user can select the "Create a Task” button 2046.
  • it is possible to assign an existing task by "double-clicking" on the task or highlighting the task and select the "Assign Task” button 2047.
  • screen 2200 illustrated in Figs. 22(a) - 22(b) is displayed, which corresponds to the "Task Project Leader Details" button 2202. Using this screen, a project leader or other suitable user can enter and/or modify information about the task.
  • Task detail information may include the section of the business plan to which the task relates 2212, a default task name 2214, a new task name 2216 if no default exists, the task status 2218 (e.g., not assigned, assigned, completed, etc.), project leader for the task 2220, the assignee 2222, the task due date 2226, task details 2230, task description 2232, task deliverables 2234, and a suggested approach to the task 2236 and any additional comments 2238.
  • other task details also may be entered.
  • the project leader selects a person in the Assignee field 2222 and assigns a task due date in field 2226.
  • the project leader can enter names manually into field 2222, while in another embodiment, the project leader can select the name from a resources list. The resources list can be accessed by selecting button 2224.
  • the project leader either can enter the task due date manually into field 2226, or the project leader can select the date from a pop-up calendar by selecting the "Set Date" button 2228, according to different embodiments.
  • external files may also be attached to the task form. After the task information is entered, it is saved by selecting the "Submit" button 2244.
  • system 100 automatically will notify the assignee, for example via email or the like, that a task is assigned to him (step 2102 in Fig. 21).
  • the assignee can access detailed information about the task by entering system 100, selecting the task, and then selecting the "Task Assignee Details" button 2204. This causes screen 2246 in Figs. 22(c) - 22(d) to be displayed.
  • the email sent to the assignee may include a hyperlink, which when selected will cause screen 2246 to be displayed. In either case, the assignee can use this screen to communicate task information to the project leader.
  • Information on Task Assignee Detail screen 2246 may include, for example, an assignee 2248, accept and decline selection buttons 2250, 2252, a field to enter a reason for declining the task 2254, task detail information 2256, a field to update the task status 2258, a field to enter comments about the task 2260, and a field to enter the date the task is completed 2262.
  • step 2104 The first thing an assignee does with a task is accept or decline the task (step 2104). To accept the task, the assignee selects the "Accept" button 2250, and to decline the task, the assignee selects the "Decline” button 2252. If the assignee declines the task, he may be required to enter a reason for declining the task (field 2254). To submit his response, the assignee selects the "Submit” button 2264, which sends a message back to the project leader. If the assignee declines the task, the project leader is so notified (step 2108), and then the project leader must generally reassign the task (step 2110).
  • system 100 accommodates negotiations between task assignors and task assignees regarding, for example, the nature of the task and the due date of the task. If the assignee accepts the task, the project leader is notified, and the assignee then can begin work on the task (step 2112).
  • a user can set certain task reminder values.
  • the user selects the "Task Reminder Setup" button 2208.
  • reminder values such as the number of days in advance of a task due date a reminder should be sent (field 2248), the number of days after a due date passes a reminder should be sent (field 2270), the number of days an assignee is given to accept or decline a task (field 2272), and the number of days a project leader is given to accept a completed task (field 2274).
  • reminder emails or other messages are sent.
  • system 100 if an assignee waits longer than three (3) days to accept or decline a task, system 100 automatically will send a reminder message to the assignee. Similarly, if a project leader takes longer than three (3) days to accept a completed task, system 100 automatically will send him a reminder, and so on.
  • An "alarm" notification also may be sent shortly before a task is due to the assignee of the task, and perhaps also automatically to the assignee's supervisor.
  • the assignee can use screen 2246 in Figs. 22(c) - 22(d) to update the status of the task (e.g., using field 2258) (step 2112). If, however, a task due date passes (step 2114), system 100 automatically will notify both the project leader and the assignee of the passed due date (step 2116). The project leader then can contact the assignee to address the situation, and then modify the due date or assign the task to a new assignee (step 2110). As discussed above, system 100 also can be configure to send due date reminders prior to the expiration of the due date (step 2118).
  • the assignee When the assignee completes a task, the assignee enters the "Assignee Task Complete Date" 2262 on screen 2249 (step 2120), and then submits the completed task along with all deliverables to the project leader (step 2122). As one skilled in the art will appreciate, the deliverables may be electronically attached to the task complete notification.
  • the project leader Upon receiving a task complete notification from the assignee, the project leader then can access and review the deliverables through system 100, and make a determination of whether the task is actually complete (step 2124). If the task is not complete, the project leader updates the task information, for example using screen 2220 (step 2126), and then system 100 automatically notifies the assignee that additional work is needed (step 2128), which returns the task to step 2112. If the project leader determines that the task is complete, the project leader closes the task, for example using screen 2200 (step 2130). Upon closing the task system 100 automatically will notify the assignee that the task has been accepted (step 2132). Once system 100 detects that all tasks assigned for a particular action stage have been accepted, Gate Review Board members are automatically notified that the action step is complete.
  • users of system 100 can track the assignment and due date history of a task by accessing screen 2276 illustrated in Fig. 22(f). To access this screen, a user can select a particular task, and then select the "Task History Details" button 2210.

Abstract

A computer-based system and method are provided for managing steps of a project development and management process. The process may involve the progression of an idea (200) from a project idea evaluation step (202) to a preliminary project feasibility step. The project idea evaluation step (202) requires the evaluation of the idea (200) by a reviewer for a decision on whether to proceed. An idea submission document (500) having information fields for capturing information about the idea is stored in a database associated with the system and is provided to the reviewer. In response to a decision received from the reviewer as to whether the idea should progress, a project definition document having information fields in common with those in the idea submission document is stored in the database, the common fields being copied automatically.

Description

COMPUTER-BASED SYSTEM AND METHOD FOR IMPLEMENTING
AND MANAGING PROJECTS
CROSS-REFERENCES TO RELATED APPLICATIONS
This application claims the priority of U.S. Provisional Patent Application No. 60/166,640, filed November 19, 1999 and entitled "Method and System for Effectively Managing a Process for New Product Development" ("the Provisional Application"), the entire disclosure of which is herein incorporated by reference for all purposes.
BACKGROUND OF THE INVENTION
In recent years, there has been a steady increase in efforts at product innovation, driven largely by the potential for significant financial returns when new products are successful. A number of specific factors that have each contributed to this increased effort can be identified. First, the world's technological base has been increasing at an exponential rate as individual innovations build successively on earlier developments. Second, there has been a demonstrable decrease in the life cycle of the average product, with the average product life-span now being approximately one quarter what the average was only fifty years ago. Third, increasing globalization of marketplaces has increased competitive pressures and agnified the potential rewards of innovative products. Finally, consumer sociology has been self-reinforcing — as consumers recognize that the market can respond more quickly to demands for new products, they have accelerated the rate at which they expect access to new products. These circumstances have produced a situation in which organizations recognize the considerable value of developing new products and are willing to expend significant funds researching them. In fact, in the early 1990's, the total cost of research and development in the G-5 nations (United States, Japan, Germany, Great Britain, and France) exceeded one billion dollars per day. Such a level of effort necessarily requires some level of organization to ensure that funds are being spent productively. The experience of many companies is that only 0.3 - 3.0 % of incoming new product or service ideas are ultimately successful in a commercial sense. In particular, decisions need to be made whether to pursue certain ideas or products and to supervise the overall development of those ideas from their conception to realization as products to be marketed. It is desirable to have a method for overseeing that complete development, with a systematic decision-making procedure that maximizes the probability that successful products will be fully and aggressively developed while research into products with little chance of success will be quickly recognized as such and discontinued.
SUMMARY OF THE INVENTION
Embodiments of the invention are directed to a method and computer system for managing steps of a project development and management process. In one embodiment, such a project development and management process may involve the progression of an idea from a project idea evaluation step to a preliminary project feasibility step. The project idea evaluation step requires the evaluation of the idea by one or more reviewers for a decision on whether to proceed from the project idea evaluation step to a preliminary project feasibility step. An idea submission document having information fields for capturing information about the idea is stored in a database associated with the system. The idea submission document is provided to the reviewer(s). A decision by the reviewer(s) as to whether the idea should progress from the project idea evaluation step to the preliminary project feasibility step is received. In response to the decision, a project definition document having information fields in common with information fields in the idea submission document is stored in the database, the common fields being copied automatically. In one embodiment of the present invention, for each of a plurality of sequential action steps and decision steps in a defined series following the project feasibility step, several additional steps are performed. A set of tasks that are to be completed during an action step are stored in the database together with a list of one or more members of a committee assigned to monitor progress of the action step and to perform such review at the subsequent decision step. The database also stores a list of criteria used by the committee to review the project and the tasks performed during the previous action step. The committee is notified of the set of tasks to be completed during the action step, as well as the date and time of a meeting to conduct the subsequent decision step. The decision step comprises the steps of determining whether the set of tasks was completed during the previous action stage, and analyzing the Go/No-Go criteria to determine whether the project should proceed to the next step. In response to determination of the committee, whether progression to the next action step in the defined series has been approved or rejected is stored.
In another embodiment of the present invention, one or more of the steps in a project development and management process includes assigning and managing the tasks to be completed to one or more human resources. Each resource has a predetermined role for each task and possesses a set of skills useful in performing that role. Information associated with each resource is stored in a database provided to a computer system. The information includes identification of the resource, roles that can be performed by that resource, and a set of skills possessed by that resource. For each task, one or more roles and one or more skills required for completion of that task are established and input into the system. The required roles and skills for each task are compared in the system with the information associated with each resource in order to identify one or more resources for completion of the task.
In one embodiment of the present invention, each identified resource has available a full-time equivalent workload and each task is accomplished over a time period made up of time period intervals. Planning information on the full-time equivalent workload is established for each resource for each time period interval as well as the share of the full- time equivalent workload for each time period interval expected from that resource for each task to be completed by that resource. The planning information is stored in the database and is displayed at a display device in order to plan the allocation of resources needed for completion of the tasks.
In a further embodiment of the present invention, a method is provided for configuring the computer system to a user organization, with information needed from one or more individuals within the user organization. A computer network is provided for connecting the individuals to the computer system. The names of the individuals are stored in a database associated with the system. An electronic message from the computer system is sent over the computer network to the individuals requesting the configuration information. Included in the message is an electronic link may be activated by the individuals in order to provide access to a specific location within the system for entry of the needed information. The computer system in which the methods of the invention may be embodied includes a storage device, at least one input device, at least one display device, a processor, and at least one communications device configured to permit the exchange of data among the other components.
Reference to the remaining portions of the specification, including the drawings and claims, will realize other features and advantages of the present invention. Further features and advantages of the present invention, as well as the structure and operation of various embodiments of the present invention, are described in detail below with respect to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS
In the Figures, similar components and/or features may have the same reference label. Further, various components of the same type may be distinguished by following the reference label with a second label that distinguishes among the similar components. If only the first reference label is used in the specification, the description is applicable to any one of the similar components having the same first reference label irrespective of the second reference label.
Fig. 1(a) is a schematic diagram showing an overview of the structure of an embodiment that provides local access to an innovation management system;
Fig. 1(b) is a schematic diagram showing an overview of the structure of an embodiment that provides access to multiple organizations to an innovation management system;
Fig. 2 is a flow diagram illustrating the interconnection between decision steps and action steps within the system;
Fig. 3 is an example of a home page that may be presented to users in accordance with an embodiment of the invention;
Fig. 4(a) is an example of a search page that may be presented to a user;
Fig. 4(b) is an example of a page containing links to company documents; Fig. 4(c) is an example of a page containing scheduling information;
Fig. 4(d) is an example of a page containing reports of project status;
Fig. 4(e) is an example of a page containing legal statements;
Figs. 5(a) and 5(b) illustrate an example of an idea-submission form that may be presented to an idea submitter for completion; Fig. 6 is a flow diagram illustrating how the system obtains and processes an idea submission;
Figs. 7(a), 7(b), 7(c) and 7(d) illustrate an example of a project definition form that may be presented to a project leader for completion;
Fig. 8 is a flow diagram illustrating how the system obtains and processes a project definition;
Fig. 9 is a flow diagram illustrating various options provided by the system with respect to resource records;
Fig. 10(a) is an example of a user registration that may be completed by a user; Fig. 10(b) is an example of a page that can be used to approve a new user registration;
Fig. 10(c) is an example of a new-resource form that may be presented to a user; Figs. 10(d) and 10(e) illustrate an example of a page from which various resource-maintenance actions may be taken by a user;
Fig. 10(f) is an example of a form that may be presented to a user to allocate resources to projects;
Fig. 10(g) is an example of a resource summary that may be presented to a user;
Fig. 10(h) is an example of a chart that can be used to graphically illustrate resource allocation;
Fig. 11 is a flow diagram illustrating how the system is configured during system setup; Fig. 12(a) is an example of a page illustrating the initiation of system setup;
Fig. 12(b) is an example of a page further illustrating the initiation of system setup;
Fig. 12(c) is an example of a page used for entry of general company information during system setup; Fig. 12(d ) is an example of a second page used for the entry of general company information during system setup;
Figs. 12(e) through 12(g) are examples of a pages used for entry of division, business unit and market segment information during system setup ;\
Fig. 12(h) is an example of a document that may be used for division, business unit, market segment project budgeting;
Fig. 12(i) is an example of a page used for entering Project Hurdle Rate information during system setup;
Fig. 12(j) is an example of a page used for entry of process facilitator information during system setup; Fig. 12(k) is an example of a page used for entry of field categories during system setup;
Figs. 12(1) and 12(m) are examples of pages used for establishing Gate Review Board information during system setup; Figs. 12(n) and 12(o) are examples of pages used for establishing Go/No Go Criteria, an Agenda, and a Purpose for each decision step during system setup;
Fig. 13 is an example of a page illustrating a project's menu.
Fig. 14 is an example of a page showing a list of projects; Fig. 15 is an example of a page showing categories in which projects may be classified;
Fig. 16 is an example of a page showing a project classified under the "Assign Project" category;
Fig. 17 is a flow diagram illustrating how the system manages a decision step process;
Fig. 18(a) is an example of a page showing a list of projects;
Figs. 18(b)-18(d) illustrate an example of a project definition page;
Fig. 18(e) is an example of a page showing project information at a decision step; Fig. 18(f) is an example of a page showing Gate Review Board Purpose and
Agenda information;
Fig. 18(g) is an example of a page showing Gate Review Board meeting information;
Fig. 18(h) is an example of a page showing project value to business information;
Fig. 18(i) is an example of a page showing a decision step Go/No-Go criteria;
Fig. 18(j) is an example of a page used to enter a Gate Review Board decision;
Fig. 19 is a flow diagram illustrating how the system manages an action step process; Fig. 20(a) is an example of a page showing project information at an action step;
Fig. 20(b) is an example of a page showing defined purposes of an action step;
Fig. 20(c) is an example of a page showing action step tasks;
Fig. 20(d) is an example of a page a project team leader can use to enter a project recommendation;
Fig. 21 is a flow diagram illustrating how the system configures, assigns and manages tasks within an action step;
Figs. 22(a)-22(b) illustrate an example of a page showing task details; Figs. 22(c)-22(d) illustrate an example of a page a team member may use to accept or decline an assigned task;
Fig. 22(e) is an example of a page that can be used to schedule task reminders; and Fig. 22(f) is an example of a page showing task history details.
DESCRIPTION OF THE SPECIFIC EMBODIMENTS
1. Overview
Embodiments of the present invention are directed to a method and system for managing steps of a project development and arrangement process. As used herein, "project" refers broadly to any good, service, or decision making process. While the description below relates generally to goods or services that are offered (for sale or otherwise) to customers, the invention more broadly includes goods or services that may be exchanged within an organization. For example, an organization's internal procedure that may be improved falls within the scope of a project and is treated as such according to the invention. Moreover, decision making processes, such as a venture capital firm deciding to fund a company, are covered under the definition of project. An overview of the structure of the system in different embodiments is shown schematically in Figs. 1(a) and 1(b). Fig. 1(a) corresponds to a local implementation of the system, such as may be made within a single organization. Fig. 1(b) corresponds to an implementation that permits multiple organizations to use the system, such as may be provided over the internet. Referring to Fig. 1(a), an innovation management system 100 is configured to be accessed by any of a plurality of users from individual stations 110. In the example shown, any of thirteen stations may be used to access system 100. Such access may be direct, as for stations 110-1 through 110-4, or may be through a local network 112, as for stations 110-5 through 110-13. System 100 uses storage devices 102 for the storage of relevant information, which may be retrieved or updated as necessary. Storage devices 102 may include any suitable storage device, for example, optical or magnetic storage media, such as disks or tape. When system 100 is accessed by a user through one of stations 110, information may be provided to system 100 by the user, perhaps through a local network 112, or may be retrieved from system 100. System 100 updates the information that is received from users and automatically manages the flow of information for the project management process.
An alternative physical structure for using system 100 is shown in Fig. 1(b), in which multiple individual organizations 130 (shown schematically with the dashed boxes) are provided with access to system 100 through a network such as the internet 150. In this particular embodiment, system 100 may act as an application service provider to organizations 130. In this configuration, each organization 130 may have its own internal network 120 that connects various user stations 124. Each internal network may have access to one or more local storage devices 122, while system 100 retains access to its storage devices 102, and depending on the particular configuration, also may have access to storage devices 122. Thus, in certain embodiments, information peculiar to a particular organization 130 may be stored locally while information that is more universally used by system 100 may be stored elsewhere.
The setup of system 100 is based on a hierarchical scheme within each organization. For example, an organization may include a four-level hierarchy based on divisions, business units, and market segments. The company or organization itself is the highest of the four levels. This hierarchical scheme additionally may be reflected in access limitations to the system, with individuals at only certain levels in the organization being authorized to view and/or edit certain information in system 100. Thus, a manager responsible for a given market segment could have access to projects in system 100 related only to that market segment. At a higher level, a manager responsible for a certain business unit could have access to all projects in all market segments within that business unit. At a higher level still, a division manager could have access to all projects that fall within the purview of any business unit within that division (including all market segments). Certain individuals within the organization may be superior to the entire hierarchical scheme (for example, a chief executive officer or president) and will have access to all of the projects within the organization without regard to the hierarchy. Others who may be given such wide access may include other executive managers, the organization's process coordinator, a system administrator, or the organization's patent counsel. In one embodiment of the present invention, access by individuals who wish to submit ideas to system 100 is neither scrutinized nor authenticated, without requiring a login and password, but access by all other individuals is scrutinized by requiring a valid login and unique password.
In one embodiment of the present invention, the system implements a systematic series of two-part steps for following a project from its conception to complete development to introduction into the marketplace to inventory obsolescence in some cases . The first step of each pair of steps (sometimes referred to as a "gate") requires that a designated group of individuals (which may be different for each market segment) approve continued development of the project. Such a group is referred to herein as a "Gate Review Board" ("GRB") and may be chaired by a "Gate Review Board Chair." The composition of the Gate Review Board and the Gate Review Board Chair may differ according to the division - business unit - market-segment hierarchy and/or according to how far the project has progressed through the series of two-part steps. Each GRB has criteria by which each project under its consideration must be evaluated prior to making the determination regarding whether or not to authorize the project's continuance. The second step of each pair
(sometimes referred to as a "stage") sets forth a predetermined set of tasks that should be carried out before proceeding to the next gate. The GRB criteria is applied to the information obtained during the execution of the predetermined tasks, thus enabling the GRB to make the determination regarding whether or not to proceed with the project. A failure to perform tasks at a given stage or to receive the required approval at a given gate may result in termination of further development of that project. In this way, the system includes a series of systematic conditions that should be met in a progressive way to develop the project fully.
This process may be understood more fully with reference to Fig. 2, which presents a flow diagram summarizing this procedure. Fig. 2 illustrates the process as it may be configured for five two-part steps. In alternative embodiments, the process may be configured for a different number of two-part steps.
The process begins with an idea 200 for development of a project. Ideas may originate with anyone inside the company, with customers, or with vendors. Once the idea is memorialized on a form within management system 100, the entire process of decision and action steps is automatically initiated and regulated. Each of the decision steps 202, 206, 210, 214, and 218 in the overall process proceeds in much the same fashion. A meeting is conducted among appropriate individuals to determine whether the business opportunity presented by the idea is attractive and consistent with the business's strategic direction. If so, the action plan for the next action step 204, 208, 212, 216, or 220 is evaluated, modified as necessary, and approved. Such approval includes earmarking appropriate funding and resources to complete the action plan for the next action step. Under certain circumstances, the decision-making power may be vested in a single individual so that the process proceeds in the same manner, but without actually having a meeting for each decision step. More generally, there is no requirement that the individuals who contribute to each of the decision steps be the same. Indeed, it may be preferable to vary the composition of the meeting to reflect the different emphases that each of the decision steps has.
Each of the decision steps after the first, i.e. steps 206, 210, 214, and 218, builds on tasks performed and information obtained from the preceding action step. The manner in which this information is used is illustrated schematically in the dotted box labeled 226. The results of the tasks performed in the preceding action step are evaluated in step 230 to determine whether the established criteria for proceeding to the next action step have been met. If those criteria have been met, the next action step is approved in step 236. If the criteria have not been met, they are examined more closely in step 232. Here, a determination is made, based on information obtained from the previous action step, whether a revision in the previous action plan would allow the criteria to be met. If so, the plan is revised accordingly in step 234, so that the question whether the criteria have been met can be revisited at step 230 after completing the previous action step in accordance with the revised plan. If, even with the information available from previous action steps, it is determined that the criteria cannot be met, the project may be terminated and archived at step 238. Also, if it is determined that certain criteria cannot be met at that given time, the project may be put on hold for a period of time.
The exemplary embodiment shown in Fig. 2 provides an example of how the series of individual decision and action steps may be configured, although other configurations may be tailored for individual organizations. An idea 200 is subjected to an initial evaluation at step 202 where it simply is determined whether the certain basic criteria are met: (1) whether the idea is consistent with the organization's strategic direction; (2) whether the idea appears to be technically feasible; and (3) whether successful implementation of the idea is likely to exceed established hurdle rates. Hurdle rates refer to performance criteria established by the organization that should be met or exceeded upon commercialization, and may be based on such factors as net present value (NPV), market size, market penetration, gross margin at maturity, etc. Furthermore, hurdle rates may differ for different project categories to which the idea may be assigned. Examples of such project categories may include breakthroughs, product platforms, new products, new processes, line extensions, or technical services, among others. The appropriate hurdle rates for evaluating an idea may depend on its classification in such a project category to reflect the different risks and expectations that the organization attributes to different project categories. An assignment of the project category may be solicited from the originator of the idea, may be assigned by those who attend the idea evaluation meeting 202, or may be assigned by someone else within the organization.
The usual objective of the first action step 204 is to perform a cursory investigation of the technical, liability, and marketing aspects of a project idea. The intention at this stage is to use inexpensive activities, such as library searches, concept renderings, and discussions with potential key users of the project to assess market size, potential, and acceptance. The cursory technical assessment involves gathering information concerning the proposed project's feasibility in being developed and manufactured, including likely timeframes and costs. Possible technical, legal, and regulatory roadblocks and associated risks also may be identified. This technical and marketing input permits a preliminary financial analysis to be included in a business plan and presented during the subsequent decision meeting 206.
This business plan is an important input to second decision step 206, in which the results of the previous cursory investigation 204 are evaluated. This evaluation of the cursory results is intended to take a deeper look at the idea to confirm that the technical, marketing, liability, and commercial risks of the project are manageable. If it is determined that they are, requirements are defined precisely in second action step 208. This requirements definition step, sometimes referred to as the "homework" step, is where the project team begins to specify and document the project, develops the preliminary plan for its marketing, and determines the resulting benefits expected to accrue to the organization upon its commercialization. The business plan is augmented so that specific elements of it include a definition of the customer needs, wants, and preferences ("requirements"), and identifies specific features and benefits to be incorporated within the project design to meet these requirements. As such, the business plan also includes analyses of the resulting target market and positioning strategy, with a review of competitive products for services and customer responses to preliminary concepts. It incorporates technical considerations, such as the feasibility of incorporating further requirements into an economically viable solution. If the project is a "product," the investment and cost to manufacture the product are investigated, and a schedule for the cost of goods sold, estimated capital costs for a pilot production line and full-scale manufacturing facility may be generated. A thorough legal and regulatory assessment is undertaken to identify risks and to formulate a plan for their effective management. In recognition of the fact that project costs will increase substantially in the next action step, the business plan also includes a detailed financial analysis consisting of pro forma income statements, balance sheets, discounted cash flow, and sensitivity analyses. A detailed project plan all the way through commercialization may also be developed from the precisely defined functional requirements.
This detailed business plan forms the basis for making the decision whether to develop the project that is made at third decision step 210. This decision provides the last point at which a project may be terminated before relatively significant funds have been spent. If, after considering the detailed business plan, a decision is made to proceed with the project, a full multifunctional project team, typically including representatives from research and development, marketing, manufacturing, quality, regulatory, and finance departments is put in place and empowered with the appropriate authority to bring the project deliverable to market.
This project team undertakes development of the project at third action step 212. This step is marked in particular by the implementation of the development plan, including the development of the physical product in those instances where there is to be a physical product. As prototypes are fabricated, customer input continues to be obtained to confirm and refine the design. Concurrent with the product's development, plans for production and market launch are also refined at this point. Legal, patent, and regulatory issues are resolved. Improved estimates for costs of goods sold and capital costs for the pilot and full-scale manufacturing plants are generated. Deliverables at the end of this step include a fully tested prototype of the product, including engineering specifications and documentation, test and validation plans to be implemented at action step 216, detailed marketing and operational plans to be implemented during action step 220, and a refined financial analysis based on additional information obtained during step 212.
At this point in the process, a significant investment has been made both financially and in terms of personnel time. Without a formalized requirement that the development be reviewed at decision step 214, there is a tendency for organizations to focus on this investment and simply proceed to pour yet more resources into the project. There is, however, still a considerable investment yet required to commercialize the product so a recognition that necessary criteria are not being met will prevent this remaining investment to be wasted on a project likely to fail. It is thus at decision step 214 that the development is reviewed so that a conscious decision may be made to authorize the additional investment needed to commercialize the product.
If required criteria continue to be met so that a decision is made at step 214 to proceed with the project, a period of testing and validation is carried out at action step 216. This step is intended to verify and validate several features about the product: its viability, including its acceptance by customers; the process by which it will be manufactured and distributed; and updated financial prospects, including, for example, pro forma income statements, balance sheets, and cash flows. Typical activities undertaken to achieve such verification and validation include laboratory tests of a pilot manufacturing process to check the product for quality and performance, as well as field trials to confirm the product function, including packaging and labeling, under actual use conditions. The pilot production validates the effectiveness of the production process to be used and may be used to refine production cost allocations. At this step, a trial sale to test the product launch plan and better define the estimated market share may also be undertaken.
The results of this testing and validation step are used in a final decision step 218, where the project can still be terminated if those results fail to meet established criteria. The decision at this pre-launch review focuses in particular on the expected financial return of the product's introduction to the market. In addition, the suitability of operations and marketing plans, as evidenced by the results of field trials, may also be taken into consideration. If final approval is given at this decision step, commercialization of the product is fully launched at action step 220. Both the operations and marketing plans previously developed are implemented as the product is introduced into the marketplace. As a result of the systematic review that the product plans have undergone through this process, there is a good likelihood that the product will be successful in the marketplace and realize a profit for the organization developing it.
2. Innovation Management System
In various embodiments of the present invention, innovation management system 100 includes a number of features, some of which are described in detail below and some of which will be evident to those of skill in the art after reading such description. Such features are described with reference to a particular exemplary computer-based embodiment, although the invention is not restricted to that embodiment and those of skill in the art will recognize that the features may be incorporated into other computer-based embodiments.
In the exemplary embodiment, the system is accessed through a web browser and presents a series of screens on which users can access system 100. Navigation through the system may be accomplished through hyperlinks, in which another aspect of system 100 is accessed by selecting the hyperlink so that another page is presented to the user. Alternatively, navigation may be accomplished with a menu-driven system, in which dropdown menus are presented to the user for selection of particular aspects of system 100. In some embodiments, a combination of hyperlinks, drop-down menus, drag-and-drop icons, and other suitable web-based technologies may be used. One such embodiment that uses a combination of hyperlinks and drop-down menus is shown in Fig. 3. The view shown in Fig. 3 represents a view of a "Home" page, on which various information about development projects and the allocation of an organization's resources to those projects is presented in summary form. The home page may identify an organization 302 described by the summary information and the date 304 that the summary information was generated. Other information 330 about system 100 also may be provided. The hyperlinks provided at the bottom of the page may appear on every page presented by system 100 to provide a consistent navigation scheme that is readily recognized by the user. Such hyperlinks may include, among others: (1) a "home" hyperlink 350 for immediate navigation to the page shown in Fig. 3 from anywhere else in the system; (2) a "search" hyperlink 352; (3) a "company documents" hyperlink 354; (4) a "calendars" hyperlink 356; (5) a "metrics" hyperlink 358; (6) a "reports" hyperlink 360; and (7) a hyperlink to legal statements 362.
Examples of pages to which such hyperlinks are connected are shown in Figs. 4(a) - 4(e). Thus, in Fig. 4(a) is shown a sample search page that may be used with the system 100 to search for the occurrence of terms that may appear in any document maintained by system 100. Various search schemes may be provided, from those that use simple Boolean rules to those that use complex fuzzy-logic algorithms. In certain embodiments, a plurality of search schemes are provided, perhaps linked to one another with hyperlinks, to accommodate different user skill levels and/or requirements. In Fig. 4(b) is shown an example of a page on which various company documents may be stored. Such documents may vary between different organizations, and may include statements and memoranda that define the company's policies with respect to product development or other issues. Thus, documents maintained on this page may include business plans, financial plans, product design guidelines, etc. One feature that is illustrated in Fig. 4(b) is the use of right-pointing triangles 382 and downwards-pointing triangles 384 to represent information in a compacted form. Right-pointing triangles 382 indicate that a list of documents defined by the associated heading may be displayed by activating the triangle. After the triangle is activated, it is presented as a downwards-pointing triangle 384 and the list of available documents is presented. Such triangles may be used on other pages within system 100 and function in the same manner. A given document may be accessed by activating a hyperlink associated with the document.
Fig. 4(c) illustrates a calendar that may be provided, indicating when any meetings related to a project are scheduled, whether they be associated with action steps or decision steps. The view shown is a weekly view, although daily, monthly, yearly, or other views may be provided. Hyperlinks are used to access preceding or subsequent time periods. Fig. 4(d) illustrates a page that may be used to present reports summarizing the status of various projects. The reports may be organized in different fashion, for example by project leader, by division - business unit - market-segment categorization, by funding authorization, by current action/decision position, or otherwise. In the example shown, project status is summarized by current action/decision position, with each project identified by how far along it is in the process outlined with respect to Fig. 2.
Fig. 4(e) provides an example of legal statements, such as copyright notices and disclaimers, that may be provided with system 100. Referring again to Fig. 3, the main portion of the page, referred to as the
"Innovation Score Board" 340, provides a snapshot summary of the status of projects and their relationship to allocated resources. This summary information may include a project listing 318, which identifies each of the projects, their current action/decision position, whether the project is on time with a scheduled time-line, and the fraction of the project that is complete. Each project listing may be hyperlinked to a more detailed description of the project or its related parts thereof. System 100 may use various methods for determining the fraction of the project that is complete, such as by averaging the current number of completed action steps and decision steps to be completed in the process, by a weighted average of the number of defined tasks that have been completed, by comparing total expenses to what has been authorized, or otherwise. The summary information also includes a resource designation 320, which indicates the total number of personnel full-time equivalents (FTEs) exist, how many are in use and how many are available. Such information indicates how efficiently project personnel are being assigned and how much unused labor remains available for allocation to projects within an organization. An idea summary 326 indicates the total number of ideas that are active, have been archived, or have been submitted on the current day.
All of this summary information may be tailored, in certain embodiments, according to the position of the user within the division - business unit - market-segment hierarchy. Thus, for example, if the user is a chief executive officer of the organization, the summary information may be directed to the organization as a whole, with all projects and their status listed and resources in use and available derived for the organization as a whole. If instead the user is responsible only for a particular market segment, only the projects for that market segment will be displayed and the resource summary calculated for only that market segment. For users whose positions are intermediate, i.e. they are responsible for a business unit or division, the summary information may be calculated appropriately for that intermediate position. As discussed briefly above, login and password security features can be used to allow or limit access to the different projects within the system and editing capabilities in the system. Other information provided within the "Innovation Score Board" may include direct hyperlinks to help information 316, a project calendar 322 that summarizes when decision-step meetings and team meetings are scheduled. In alternative embodiments, this information may be further customized to include summary information or hyperlinks to other aspects of the system 100 as may be desired by an individual organization. At the top of the page shown in Fig. 3 are five drop-down menus that are also used to navigate through the system: (1) "Ideas" 306; (2) "Projects" 308; (3) "Resources" 310; (4) "Setup/Admin" 312; and (5) "Help" 314. As system 100 is organized in the exemplary embodiment, a distinction is drawn between an "idea" and a "project." An idea may be submitted by anyone and its submission initiates certain activities described in detail below. A project, however, is only established after an idea has been approved, at which point it is assigned an identifying project number. In accordance with one embodiment of the invention, the project number will correspond to the idea number previously assigned when the idea was submitted.
The drop-down menu under "Ideas" 306 thus may include a link to a page for submitting a new idea and may include links to pages that summarize existing ideas sorted according to criteria such as date, the identity of the idea generator, or the division - business unit - market-segment categorization. Such links may be designated to provide a summary only for active ideas, only for archived ideas, or for a combination of active and archived ideas. The drop-down menu under "Projects" 308 is accordingly similar. One link in the drop-down menu may be for defining a new project while other links may be to pages summarizing existing projects, designated as active, archived, or including both active and archived projects. The menu links may be more specific, such as by including links to particular pages in which the projects are sorted according to the division - business unit - market-segment categorization, by project leader, or by current (if active) or last (if inactive) step within the progression defined in Fig. 2.
The drop-down menu under "Resources" 310 may include links designed to administer records relating to personnel, their skills, their availability, and how they are assigned to different projects. Thus, entries in the drop-down menu may include a link to a page for creating a personnel record for an individual, in addition to including links that summarize existing personnel records, such as by skill set, name, role, or location.
The drop-down menu under "Setup/ Admin" 312 may include links to pages that are used for configuring the system to operate according to the structure of the organization. The pages accessed from this drop-down menu are used to configure an organization by defining organization information, specifying the division - business unit - market-segment hierarchy according to the actual classifications used in the organization, and defining the action and decision step criteria for proceeding through the process defined in Fig. 2. Finally, the drop-down menu under "Help" 314 may include links to information that describe the system, such as a glossary of terms, training materials, frequently asked questions (FAQs), and other explanatory information.
Ideas
When a user selects the Create New Idea option from the "Ideas" drop-down menu 306, he is presented with a page such as shown in Figs. 5(a) and 5(b). This page represents one embodiment of an idea-submission form 500 and permits the entry of information in a specific format to define the idea and permit system 100 to initiate various functions for evaluating the idea. As one skilled in the art will appreciate, Fig. 5(a) is the top portion of idea-submission form 500, while Fig. 5(b) is the bottom portion of the form. Certain fields within the form may be mandatory while others may be optional. An attempt to submit an idea form that fails to fill in a mandatory field will result in it being rejected and prompting the submitter to complete at least all of the mandatory fields. Such mandatory fields may be marked in some way on the form to identify them clearly to the user, such as denoting them with an asterisk, displaying them in a different color, or otherwise.
In one field, labeled "Idea Submitter" 506, the name of the individual who has developed the idea is input. This person's email address may be included in an email field 508. In some embodiments, this field may be completed automatically by allowing system 100 to access directory records of the organization that specify email addresses. Email field 508 is a mandatory field because system 100 relies on electronic communications to and among individuals to implement the product development process according to the invention. Other mandatory fields may include an "Idea Name" field 510 and an "Idea Type" field 512, in which the submitter both provides an identifying designation for the idea and specifies the product category to which (he believes) the idea should be classified. Such product categories may be defined individually to meet the needs of a particular organization, although system 100 may also include certain default categories:
(1) Breakthrough — a product that is new to the world and has not been marketed by any other organization;
(2) Product Platform — a combination of designs and technologies that may be used to create a family of products that share those designs and technologies;
(3) New Product — a good or service that is new to the organization but has previously been marketed by at least another organization; (4) New Process — a new method for producing a product that is already being marketed by the organization;
(5) Line Extension — a modification to one of the organization's existing products; and
(6) Technical Service — a modification to one of the organization's existing methods for producing a product.
Specification of the product category may affect how system 100 handles the idea submission, in terms of who it is directed to, and how it affects the applicable hurdle rates. In addition, the product category may be used in developing certain summary information provided by system 100 to describe the allocation of funds and resources within the organization.
Further mandatory fields are provided for categorizing the product to which the idea is directed according to the organization's hierarchical structure. Thus, for a division - business unit - market-segment hierarchy, there is a "Division" field 514, a "Business Unit" field 516, and a "Market Segment" field 518. These fields, and the "Idea Type" field 512 may be structured with drop-down menus (shown with the arrowhead in Fig. 5), or these fields automatically may be populated by the system based on the division - business unit - market segment within which the idea submitter is employed. Free-form mandatory fields 520 and 522 are provided for the idea submitter to describe the idea and how it will benefit the organization. A mandatory check-box field 524 also may be provided so that the idea submitter can characterize the benefit to the organization according to predetermined criteria, such as increasing sales, reducing costs, and/or increasing quality.
In addition to these mandatory fields, there may be one or more optional fields. For example, a free form field 526 may be provided to allow the idea submitter to make any other relevant comments relating to the idea. In addition, a field 530 may be provided for specifying ad hoc collaborators. When system 100 sends notifications related to the idea, it may send them to individuals specified in field 530, in addition to individuals that system 100 has determined at field 528 will be notified in light of the other information entered by the submitter. The form also may be configured to permit the attachment of files at field 532.
External files may be made part of the idea submission by using the "Browse" 534 and "Attach File" 536 functions to search for appropriate files and to attach them to the submission. Once the information is fully entered into the form and any external files attached, the "Submit" button 540 is activated to submit the idea to the system 100. If the submitter wishes, he may also activate a "Print Idea" button 502 to produce a hard-copy record of his submission.
The logical flow of the idea-submission process is summarized in Fig. 6. At step 602, the system 602 prepares the idea-submission form 500, such as described with respect to Fig. 5, for completion by the submitter. Both mandatory and optional information is obtained through the form interface at step 604. After execution of the "Submit" button 540 is detected at step 606, system 100 determines at step 608 whether the mandatory fields have been completed. If not, an error message is displayed at step 612 and system 100 returns to step 604 to obtain the additional information. If the "Submit" button 540 has been executed with all mandatory fields completed, system 100 performs two parallel functions. First, it returns to step 602 to prepare another idea-submission form 500 for completion. System 100 also sends notifications at step 610. In one embodiment, the content of such notifications includes all the information that was entered by the idea submitter into idea-submission form 500. In other embodiments, the content of each notification is tailored according to the role of the recipient in the process. There may be several types of recipients of the notification, depending upon the structure that the organization has established. One recipient may be a process facilitator, who is an individual trained in shepherding ideas from their conceptual stage until a project team leader has been assigned. The facilitator may assist idea generators in completing idea-submission form 500, and may direct them to appropriate resource personnel within or outside the organization so that adequate information may be gathered and documented. The assigned facilitator may vary according to the division - business unit - market-segment hierarchy, so system 100 will direct the notification according to how this information was entered on idea-submission form 500. System 100 also may send a notification to the Gate Review Board Chair(s) who is responsible for presiding over the first decision-step meeting for the defined division - business unit - market-segment categorization of the idea, and perhaps also to each of the members assigned to that Gate Review Board. System 100 may further notify the authority- line supervisor(s) of the idea generator(s), obtaining the identity of such individuals automatically by accessing company organization records. Anyone identified in the form as a potential collaborator also may be notified of the idea submission.
In addition, system 100 may be configured to notify a patent attorney or patent agent of the idea submission. If system 100 is so configured, idea-submission form 500 may additionally include fields for inputting information of particular relevance to patent- application filings, such as the dates of conception, actual reduction to practice, public disclosures, or offers for sale. In addition, fields may be provided for attaching any available files that describe relevant prior art.
System 100 may further notify the individual who developed the idea, as input into field 506, that the idea has been submitted. That individual's supervisor may also be notified that the idea has been submitted, with system 100 extracting information regarding supervisory positions from personnel records.
At step 614, system 100 automatically generate one or more documents for the first decision-step meeting, which may include a Gate agenda and a report for completion by the Gate Review Board members. Such an agenda may include reviewing the completed idea-submission form 500, discussing the criteria for approving the idea as a project, deciding whether to approve the idea as a project, and, if approval is given, staffing and funding the project up to a certain point. An example of a Gate agenda and a report form suitable for completion at such a meeting is provided in the Provisional Application at pages 45 - 47. As discussed in further detail below, agenda items can be defined in the "Setup/ Admin" portion of the system. 4. Projects
If the idea is not approved as a project, a notation is made in system 100 that the idea is to be archived and it will be included in summaries that system 100 may produce describing archived projects/ideas. If the idea is approved as a project, however, information defining the project is input into system 100. Some of the information describing the project may be extracted automatically from idea-submission form 500. Other information results from the first decision-step Gate Review Board meeting and is therefore input after that meeting. It also is possible that projects may be entered into system 100 without having originated as ideas. This may happen, for example, when system 100 is adopted by an organization that already has an active research effort, so that existing projects are entered into system 100 when it is acquired.
One embodiment of a project definition form 700 that may be presented to a user is shown in Figs. 7(a) - 7(d). As with idea-submission form 500, certain fields may be mandatory and are denoted as such in the illustrated embodiment with asterisks, although they could be so denoted in alternative ways. The project number includes fields for a project name 710, project type 712, division 714, business unit 716, market segment 718, project submitter 706 and the email address of the project submitter 708, which correspond generally to the similarly named fields included on idea-submission form 500. While these corresponding fields may usually have the same entries as input on idea-submission form 500, system 100 is sufficiently flexible to allow them to be redefined in the project definition form. Such redefinition may correct a manifest error made by the idea submitter or may represent a more subtle correction that the Gate Review Board has introduced after its deliberations to account for various unanticipated considerations.
In addition to these fields, project definition form 700 also may include mandatory fields to identify a project leader 738, a project team 740, a description of the project 720, as well as who authorized the project 754 and who authorized funding for the project 756. Some or all of these fields automatically may be populated by system 100 based on the division - business unit - market segment within which the project is classified. There also may be various optional fields, such as a project start date 758, a project's position within the product-development scheme 742, goals and objectives of the project 744, an expected launch date for the product 748, an expected manufacturing startup date for the product 748, and a date a post-implementation review of the product is to be completed 760. Fields may be included for additional comments 726 and for the attachment of key documents 732 by using the "Browse" 734 and "Attach File" 736 functions in the same manner as described with respect to idea-submission form 500. The form includes a field for a project reference number 704, which is assigned automatically by system 100 as described below. Buttons to print a copy of project definition form 702 and to submit the completed form 762 are included as on the idea-submission form.
The functional flow used to process the project definition form is shown schematically in Fig. 8. At step 802, system 100 prepares a project definition form 700 into which the information described above with respect to Fig. 7 may be input. System 100 determines at step 804 whether the project to be defined corresponds to a previously stored idea. If so, information from the stored idea-submission form 500 that corresponds to fields in project definition form 700 is extracted from the stored idea-submission form 500 and preloaded into project definition form 700, where it may be modified if necessary as described above. Information defining the project is obtained at step 808, such information may include a combination of mandatory and optional data as described above.
At step 810, execution of the "Submit" key 762 is detected, at which point system 100 ascertains whether all mandatory fields in product-submission form 700 have been filled. If not, system 100 displays an error message and allows the user to enter additional information. If all mandatory fields have been completed, system 100 both returns to step 802 to prepare another project definition form and proceeds to assign a project number at step 814 and to add the now-defined project to the system at step 816.
5. Resources
As used herein, "resources" may refer generally to personnel resources such that system 100 maintains a record of personnel identities, their skills, and their assignment to projects. There may be more than one way for resource records to be introduced into system 100. In one embodiment of the present invention, system 100 uses user registration information to create the resource records automatically. Thus, for example, an individual will complete a user registration form when he requests general access to system 100. An example of a user registration form is shown in Figs. 10(a) and 10(b), with Fig. 10(a) illustrating the top half of the form and Fig. 10(b) illustrating the bottom half. The registration form includes fields that are useful in identifying the resource and his or her skills. Such fields may include first 1002, middle 1004, and last 1006 names, a system user name 1008, the resources location 1010 and business unit 1012, a contact phone number 1014, and email address 1016, a supervisor 1018 and his email address 1020, resource skills 1022, one or more roles that the resource will perform 1024, 1026, and a login password 1028. In addition, the user registration form illustrated in Figs. 10(a) and 10(b) may include a field 1030 that allows a supervisor to approve the registration information. In accordance with this aspect of the present invention, after the information is entered on the form, the form automatically is forwarded to a supervisor for review. The supervisor can modify the form as need and then accept it using field 1030. In addition, the. supervisor has the right to deny the resource form, in which case the resource is notified of the denial and requested to complete a new form. When the user registration form is approved by the user's supervisor, a resource document is automatically is created by system 100 on behalf of the user. Alternatively, a resource document may be created using the "New Resource" function described below.
The maintenance of resources may be illustrated with respect to Figs. 9 and 10(c) - 10(h). Fig. 9 provides a flow diagram 900 involving various aspects of resource- maintenance functions that may be performed by a user. Since the functions are constructed to be interconnected, flow diagram 900 illustrates a path that may be followed by executing a "New Resource" function from the Resources drop-down menu 310. Figs. 10(c) - 10(h) show examples of several pages that may be presented to a user as he executes the resource- maintenance functions. Accordingly, in the discussion below reference is made interchangeably to the figures so that the effect of functional aspects shown in Fig. 9 may be illustrated with the exemplary pages presented to the user in Figs. 10(c) - 10(h).
After a user executes the "New Resource" function, system 100 responds by preparing a new-resource form 900 at step 902. An example of the new-resource form 900 is shown in Fig. 10(c). It includes fields where the user may select or enter a resource name 1032 and a default role 1034 for the resource. In accordance with one embodiment of the present invention, the resource information already was entered into system 100, and new- resource form 900 only is used to select particular resources and the associated role. In an alternative embodiment of the present invention, new-resource form 900 can be used to enter in a new-resource not previously defined. In accordance with this aspect of the present invention, if a non-defined resource is entered at this page system 100 automatically will cause a resource definition to be displayed. The user then can enter the appropriate resource information. Variations on the specific types of classifications used to define resources are also within the scope of the invention. The default role 1034 field is used to define the particular function that the resource normally fills in the product-development scheme. If a resource has more than one role, the user can select the desired role using this screen. Default roles 1034 may include, for example, a Gate Review Board Chair, a Gate Review Board member, an idea generator, a line manager, a process coordinator, a process facilitator, a project team leader, a project team member, or a system administrator, among other possibilities. Skill sets are used to define the known capabilities of a user and typically are defined during the resource registration process, but can be modified at any time. Skill set information generally includes an identification of both the skill that the resource possesses, as well as a designation of the resource's proficiency at that skill. Identified skills may include technical skills, administrative skills, financial skills, etc. In accordance with one embodiment of the present invention, resource skills can be categorized at three levels, approximately corresponding to beginner, intermediate, and expert levels of proficiency. New-resource form 900 includes a "Print Document" button 1035 and a "Submit" button 1036, used respectively to print a copy of the document and to submit the completed document to system 100.
Thus, at step 904, system 100 obtains information used to define the resource. As in other forms described above, certain of the fields may be mandatory and some may be optional. Accordingly, after system 100 detects that the user has executed the "Submit" button 1036 at step 912, it determines at step 914 whether all of the mandatory fields have been completed. If not, an error message is displayed to the user at step 916 and the system again seeks to obtain more complete information describing the resource.
Once all mandatory fields are completed and the form properly submitted, the system may generate a resource-allocation form 960 (Figs. 10(d) and 10(e)) at step 918. Resource-allocation form 960 is similar to new-resource form 900, but includes additional information. For example, resource-allocation form 960 includes a menu from which further resource maintenance functions may be performed. In the illustration, the menu includes buttons for assigning a project 1044, refreshing the project list 1046, and viewing a workload graph 1048. System 100 monitors for execution of one of these menu selections at step 920 and responds accordingly. Resource-allocation form 960 additionally includes a "Print Document" button 1040 for producing a hard copy of the page, a "Submit" button 1049 for activating other aspects of system 100, and a resource table 1042, which is described in further detail below.
Activation of the "Assign Project" button 1044 causes system 100 at step 922 to prepare a project- assignment form 970, an example of which is shown in Fig. 10(f). In certain embodiments, project- assignment form 970 may be generated by system 100 in a separate window from the resource-allocation form so that resource table 1042 may be consulted easily while completing project-assignment form 970. Project-assignment form 970 includes fields for defining the name 1050 of the resource, the role 1052 the resource will have in the particular project, and an identification 1054 of the project. The purpose of project-assignment form 970 is to use these fields to define the specific role a resource will have in a given project and to provide an estimate of how much time the resource will spend on the project. Thus, while system 100 automatically will fill in the role 1052 that a particular resource is expected to take for the project according to the previously defined default role 1034 for that resource, the role 1052 may be changed to suit the particular project.
In addition to these fields, project-assignment form 970 includes a project- workload table 1032. This table is used to provide an estimate of the fraction of the resource's time that he is estimated to devote to the project over the next several months, broken down on a monthly basis. In alternative embodiments, this information may be broken down in a different manner, such as by monthly or daily, depending in part on the complexity and scope of projects to be handled by system 100. The workload information is entered into project-workload table 1056 as a percentage of a full-time equivalent (FTE) person. Project- assignment form 970 also includes a "Print Document" button 1060 for producing a hard copy of the form and a "Submit" button 1061 for execution when the form is complete.
Thus, system 100 collects this project-assignment information at step 924 and waits to detect execution of the "Submit" button 1061 at step 926. When the form is complete, system 100 updates resource records at step 928 and returns the user to the resource-allocation form 960 shown in Fig. 10(b). The information collected in project- workload table 1056 is incorporated here in resource table 1042.
Resource table 1042 summarizes the time allocation of each resource maintained by system 100, defining all the projects to which each resource has been assigned and showing a monthly (or other, in alternative embodiments) breakdown of each resource's assigned workload over the next several months. The total workload assignment for each resource is summed over all assigned projects so that a user can readily identify which resources are completely allocated, and therefore unavailable for further workload allocation, and which resources remain available for additional allocation. This breakdown of resource availability is configured so that it is possible to identify specific monthly windows in which individual resources may accommodate further assignments or particular months in which a resource is overloaded. A user, such as a project leader, thus may easily correlate the planned needs of a project with available resources to fill those needs.
Various additional features allow this information to be used even more effectively to assign projects to resources in an efficient manner. For example, system 100 also monitors at step 920 for execution of the "View Workload Graph" button 1048. When that button is executed, system 100 may prepare a graphical display of the resource table 1042 information, showing the allocation of resources to particular projects in the form of a histogram or other graph. The histogram may show an individual's allocation over time, may compare the allocation of different individuals, and may summarize the allocations to a particular project, among other summaries that may be generated by system 100. An example of a graph that may be produced is illustrated in Fig. 10(h).
System 100 also monitors at step 920 for execution of the "Refresh Project List" button 1046. This feature is provided to recognize that many users may be accessing the system at any given time and assigning resources to projects. A given user may execute the button to have the system update the information presented in resource table 1042 at step 930 so that the user is accessing current information.
When system 100 detects at step 920 that the user has activated the submit button 1049 or a suitable "View Resources" button (not shown), it presents a resource display 980 such as shown in Fig. 10(g), in which available resources are identified, together with their default roles and designated skill sets. Ready access to this additional information permits the user to make appropriate project assignments. The information shown in resource display 980 also may be accessed directly from the "Resources" drop-down menu 310, and may be organized according to resource name, default resource role, or skill sets, depending on how the user wishes to access the information.
Still further variations on this resource management subsystem are within the scope of the invention. For example, resource table 1042 may be simplified in one embodiment to show a restricted set of resources, such as those that have already been identified as team members of a particular project, to simplify the display. Various additional fields may be used when appropriate for certain organizations to define the resources more discretely, such as by their geographical location within the organization, their skill levels, or other criteria that may be of use in their allocation to projects. 6. Setup/Admin
The Setup and Administration of system 100 now will be described in conjunction with the flow diagram in Fig. 11 and the graphical user interfaces shown in Figs. 12(a) through 12(o).
Before describing the details of Setup and Administration, it is useful to first describe the overall purpose of Setup and Administration and to describe the data and personnel within the company needed in order to carry out its purpose. Setup and Administration has several purposes: (1) facilitate the configuration of system 100 by a system administrator in accordance with the overall organizational structure and processes of a company;
(2) identify the appropriate individuals within a company who will input further information needed in order to implement the processes carried out by system 100;
(3) initiate notifications to the various individuals involved in system configuration in order for them to input needed information; and
(4) subsequent to setup and initial configuration of the system, permitting the system administrator to administratively control, as needed, the re-configuration of the system and the access to various functions within the system.
In order to configure system 100, a system administrator or other suitable user first enters basic information about the company and its processes. Then, the system administrator may provide the names of individuals within the company who can provide additional information, particularly information related to levels of the corporate structure below the overall company level (i.e., information related to divisions, business units and market segments). System 100 automatically will notify those individuals (in the preferred embodiment, through automatically generated email messages or other notification means, such as burst messages or the like) to provide the needed information.
In accordance with one embodiment of the present invention, the following four tables illustrate data that may be needed in order to complete Setup and Administration. The data is organized according to the organizational level that provides such information. In particular, Table I shows information that may be provided to system 100 at the highest corporate level (e.g., by a systems administrator, or the like). In addition, Table II shows information that may be provided by individuals at the division level, Table III shows information that may be provided by individuals at the business unit level, and Table IV shows information that may be provided by individuals at the market segment level. The information in Table I may be entered by the systems administrator, with input from senior corporate management. Similarly, the information in Tables II, III, and IV may be entered by individuals at the division, business unit and market segment levels, respectively, with such individuals named by the system administrator during system setup.
Table I Corporate Information
Name of Process Coordinator
Name of Patent Counsel Number of Gates and Stages
Number of Months after Launch to Create Project Implementation Review (PIR) Document
Company Name
Individual to Provide Company New Project Strategy Individual to Provide Company R&D Investment
Individual to Provide Company Project Hurdle Rates
New Company Strategy
Division Names
Business Unit Names Market Segment Names
Individuals to Provide Division, Business Unit and Market Segment New Product Strategy
Individuals to Provide Division R&D Investment
Names of Individuals to Provide Division Project Hurdle Rates Total R&D Budget for Each Business Unit
New Business Unit Strategy for Each Business Unit
New Market Segment Strategy for each Market Segment
Process Facilitator for Each Market Segment
Table II
Division (DIV) Information
DIV New Product Strategy DIV R&D Investment DIV Project Hurdle Rates DIV Total R&D Budget
Table III
Business Unit (BU) Information
BU New Product Strategy BU R&D Investment
BU Project Hurdle Rates BU Total R&D Budget Table IV
Market Segment (MS) Information
MS New Product Strategy MS R&D Investment MS Project Hurdle Rates
A glossary of terms describing the various data or information input during Setup and referenced in Tables I, II, III and IV is provided ϊn Appendix A. Appendix A also provides definitions of other terms that may be used by system 100. Referring now to the flow diagram shown in Fig. 11 and the graphical user interfaces (also referred to as "screens" or "pages") shown in Figs. 12(a) through 12(o), the setup and admin process will be discussed. Setup is started at step 1102 by selecting the "Slalom Configuration" option 1202 in the "Setup/ Admin" drop down menu 312 in Fig. 12(a). The system then displays screen 204 illustrated in Fig. 12(b). to enter a configuration, the system administrator activates or "clicks" the "Create Slalom Configuration" button 1205. Note that in Fig. 12(b), if setup information has been entered previously by the system administrator, that information is indicated by listings or links appearing as "Setup Documents" 1206 - 1214. A user can access the previously entered information by selecting the appropriate link for the Setup Document 1206 - 1214. After button 1205 is activated, screen 1216 in Fig. 12(c) is displayed and the system administrator is prompted to enter general configuration and company information at step 1104 (see Fig. 11). Specifically, screen 1216 prompts the user to enter various information about the company, such as the name of the company's Process Coordinator (field 1228), the name of the company's Patent Counsel (field 1230), information on the number of gates and stages in the overall process (field 1232), and the number of months after product launch that a Post Implementation Review (PIR) document is to be created (field 1234). Note also that using screen 1216, the system administrator, under the section entitled "Slalom Start Page Customization" 1236, can enter information for screen graphics. That is, the system administrator can customize the stylized headers and related content that will appear on each page or screen of the system, to provide an appropriate company name or brand identity to the system.
After entering the information, the "Company Setup" button 1220 is activated and the Company Setup screen 1238 (Fig. 12(d)) appears. On Company Setup screen 1238, the system administrator can enter company information, such as the company name (field 1240), and the names of individuals that can provide company top level New Project Strategy (field 1242), R&D Investment Data (field 1244), Project Hurdle Rates (field 1246) and overall Company Strategy (field 1248). The system administrator may have such information or may need to consult with senior management as necessary to obtain the most current information available for entry. In order for system 100 to capture information during the implementation of the process and to issue reports to appropriate management personnel who are most in need of that information, system 100 can be configured so that information can be collected, stored, classified and reported to the management personnel within the company at the organizational level to which it most closely relates. Thus, at the next step 1106 (see Fig. 11) the system administrator can use a series of screens (initiated by activating the "Divs/BUs/MSs" button 1222 to enter information defining an organization's divisions, the business units under each of those divisions, and the market segments into which products are sold by each business unit. The entry of this information collectively is represented by steps 1106, 1108 and 1110 in Fig. 11, and may be accomplished by the use of screens in Figs 12(e) through 12(g). Note that steps 1106, 1108 and 1110 in Fig. 11 may be configured as a "looped" sub-process, such that setup does not move on to the next step in Fig. 11 until all division, business unit and market segment information is entered by the system administrator.
After button 1222 is selected, screen 1258 in Fig. 12(e) is displayed. Using screen 1258, the system administrator or other user can enter the names of each of a company's divisions by selecting the "Create Division" button 1251. The user then is provided a screen (not shown) to enter division information. Once entered, the divisions are listed in field 1252. To establish a business unit associate with a division, the system administrator selects one of the divisions listed in field 1252, and then activates the "Create a Business Unit" button 1254, which causes the Business Unit Setup screen 1258 illustrated in Fig. 12(f) to be displayed. At Business Unit Setup Screen 1258, the user can enter information about each business unit associated with the selected division. If a division was selected on screen 1250 the division field 1260 automatically may be populated with the division name. However, the division field 1260 also is modifiable, for example by using a pull down menu or by manually entering a division name. Business unit information may include the name of the business unit (field 1262), the names of individuals that can provide new Project Strategy (field 1264), R&D Investment (field 1266), Project Hurdle Rates (field 1268) and Business Unit Strategy (1272) for the business unit, as well as the R&D budget (field 1270) for the business unit. After the information is entered, the "Submit" button 1274 on screen 1258 is activated to save the information. The Business Unit Setup screen can be used to enter information about each business unit in an organization.
To create a market segment that is to be associated with a business unit, the system administrator then returns to screen 1250, selects a particular division and business unit, and then clicks the "Create a Market Segment" button 1256. Screen 1276 in Fig. 12(g) is displayed, and the division name (field 1286) and business unit name (field 1288) are automatically populated with the division and business unit selected on the screen 1250. Alternatively, the division name (field 1286) and the business unit name (field 1288) can be manually entered or amended by selecting names from a pull-down menu, or by manually entering the names. Other information about a market segment that may be entered on screen 1226 to include the market segment name (field 1290), and the names of individuals that can provide Product Strategy (field 1292), R&D Investment (field 1294), Project Hurdle Rates (field 1298), and New Market Segment Strategy (field 1300).
In addition, screen 1276 may include an R&D Investment Template button 1296, which when selected, will cause an R&D Investment report or spread sheet 1302 (Fig. 12(h)) to be displayed. R&D spread sheet 1302 can be used by project personnel to make budgeting and Go/No-Go decisions. In accordance with an alternative embodiment of the present invention, system 100 also may be configured to interface with a company's accounting or Enterprise system in order to track and manage budgeting and expenditure numbers. After the system administrator finishes entering data for each market segment, the system administrator then can activate the "Process Facilitator" button 1282 shown on Fig 12(g). The "Process Facilitator" button 1282 causes screen 1304 in Fig. 12(i) to appear. Using screen 1302, the system administrator can define a facilitator for the market segment. Process Facilitator information may include name, address, phone number, fax number, email address, etc. In addition, as discussed in more detail below, the system administrator or another user can select "Hurdle Rates" button 1284, to enter project hurdle rate information into screen 1306 shown in Fig. 12(j).
Next, by selecting "Field Categories" button 1224, a system administrator can enter field category information (step 1112) using screen 1308. As illustrated in Fig. 12(k), field category information may include information such as Project Categories (field 1310) and Resource Skills (field 1312). In accordance with one embodiment of the present invention, the system administrator may select default field categories that are provided with system 100, or the system administrator may create and enter company specific field categories during the configuration setup. Moreover, if during use of the system, users develop categories that are more appropriate for their company, or for the individual divisions, business units, or market segments within the company, the system administrator can return to Product Category Setup screen 1308 illustrated in Fig. 12(k) to add and/or modified the categories. After changes are made, the user can activate the "Submit" button 1314 to save the changes. This permits the system administrator or other users to have significant flexibility in setting up categories. Thus, the system administrator may select the default categories for some of the items, and then enter unique and company-specific categories for other items. Also, as part of the configuration of system 100, various individuals named during setup to provide Project Strategies, R&D Investment and other information also can be asked to review the defaults and change them as appropriate for their particular division, business unit or market segment. Tables V below illustrates example default Project categories and Table VI illustrates example default Resource Skills Categories that may be provided with the system.
Table V
Project Product Categories
Breakthrough Platform Product New Product New Process
Line Extension Technical Service
Table VI Resource Skills
Windows 2000-1
Windows 2000-2
Windows 2000-3
Windows 98-1 Windows 98-2
Windows 98-3 Windows NT- 1 Windows NT-2 Windows NT-3 C++ Dev-1
C++ Dev-2 C++ Dev-3 Scripting- 1 Scripting-2 Scripting-3
VB-1 VB-2 VB-3 Java-1 Java-2 Java-3
SQL/ODBC- 1
SQL/ODBC-2
SQL/ODBC-3
HTML-1 HTML-2
HTML-3
JavaScript- 1
JavaScript-2
JavaScript-3
The exemplary resource skill defaults listed in Table VI may be appropriate for information- technology products. Other products may have other technical skill defaults appropriate for those products.
Next, the Gate Review Board ("GRB") information can be configured for each gate or decision step for each market segment (step 1118). To access the GRB Setup screen, the system administrator selects the "GRB Setup" button 1280, which brings-up GRB Setup screen 1316 illustrated in Fig. 12(1). The GRB setup screen can be unique for each market segment, making system 100 configurable to the market segment level. As illustrated in Fig. 12(1), each of the five gate review boards 1318 (recall that this number was established earlier by the system administrator at step 1104) can be selected, and the "Edit GRB Gate Setup Doc" button 1320 is used to display a GRB information entry screen for each of the GRBs. A GRB information entry screen 1322 is illustrated in Fig. 12(m). In the GRB information entry screen, GRB information, such as the GRB chairperson and members can be entered for the selected GRB. Screen 1322 can be used to edit existing GRB setup information or add new GRB set up information. As one skilled in the art will appreciate, only authorized individuals (such as a GRB Chairperson) will have the security clearance to add or modify GRB records.
Next, gate go/no-go criteria should be entered (Step 1124 in Fig. 11). To access the Gate Go/No-Go Criteria Setup screen, the "Go/No Go Defaults" button 1226 can be activated. Upon activation of button 1226, the Gate Go/No-Go Criteria Setup screen 1324 (Fig. 12(n)) is displayed. At this screen, "Go/No Go" Criteria, Agendas and Purposes may be entered. In accordance with one embodiment of the present invention, system 100 may be preloaded with generic Default "Go/No-Go" Criteria, Agendas, and Purposes as illustrated in the screen in Fig. 12(n). As one skilled in the art will appreciate, users of the system can use the generic defaults, or new criteria can be added. To add or modify "Go/No-Go" Criteria, a user may select the "Create Go/No-Go Criteria" button 1326, which causes screen 1328 illustrated in Fig. 12(o) to be displayed. As illustrated in Fig. 12(o) "Go/No-Go" Criteria can be created or modified so that it is associated with particular divisions, business units, market segments, stages and gates. In addition, information such as element category, sub-element name, criteria name, criteria number, and criteria details also can be entered. The generic default "Go/No-Go" Criteria, Agendas and Purposes that may be provided with the system generally may be applicable to most companies for most process stages and gates. Examples of default "Go/No-Go" Criteria, Agendas, and Purpose that may be used are set forth on pages 45-48, 51-56, 58-60, 62-64 of Provisional Patent Application No. 60/166,640, filed November 19, 1999, which is incorporated herein by reference for all purposes.
After all of the setup procedures are complete, the data is submitted to the system by clicking a "Submit" button. Upon submitting the data, system 100 returns to the home page (Fig. 3).
As mentioned earlier, system 100 is designed to conveniently collect information through the use of emails. In accordance with one embodiment of the present invention, emails or other types of messages automatically can be sent to each of the individuals named in the setup process as having information needed for system setup. In accordance with this aspect of the present invention, the emails or messages may include appropriate links to particular screens in system 100, so that those individuals can conveniently enter the necessary information.
Take, for example, the individual named at step 1108 (using the screen in Fig. 12(g)) as the individual to provide Project Hurdle Rates. An email to that individual is generated automatically after the system administrator completes all of the entry of data during setup at step 1128. The email may include a link to screen 1304 illustrated in Fig. 12(g). The email may be configured to instruct the individual to activate the "Hurdle Rates" button 1284 in Fig. 12(g) in order to display the screen illustrated in Fig. 12(i) for entering the Hurdle Rate information. After the individual enters the data in Fig. 12(j), and then clicks the "Submit" button, the data automatically is saved in system 100. A similar process can be used to request other individuals in an organization to provided necessary data.
In accordance with one aspect of the present invention, after requested data is submitted by the named individuals, a reply email automatically is generated by system 100 in order to notify the system administrator. A report (not shown) can be generated periodically to show any outstanding requests for data, and to send appropriate reminders if the requested data is not being submitted within required time frames (steps 1130 and 1132 in Fig. 11). After all requested information is submitted, the initial configuration of the system is complete at step 1140 and system 100 is then ready for use.
7. Project Processing
As discussed above, once an idea is accepted, it is converted to a project, which can be managed by system 100. To access projects, a user can access the "Projects" pull-down menu 1350 illustrated in Fig. 13. In accordance with one embodiment of the present invention, active and archived projects can be grouped and viewed by business, project leader, and current stage. Fig. 14 illustrates a screen 1402 listing projects by business, and Fig. 15 illustrates a screen 1502 listing stages into which projects can be group. For example, ideas can be grouped into a pre-project stage, or projects can be grouped into a decision stage or an action stage. Ideas in a pre-project stage would be listed under the "Assign Project" category 1504, projects in a decision stage would be listed under the "Gate in Progress" category 1506, and projects in an action stage would be listed under the "Stage in Progress" category 1508. To access the projects (or ideas) listed under each category, a user can select the right-pointing arrow next to each category, which causes the lists to be displayed. For example, a list of ideas under the "Assign Project" category 1504 is illustrated in Fig. 16. Similarly, a list of projects in the "Stage in Progress" category 1508 is illustrated in Fig. 18(a).
Various information described below is used in the processing of a project. Security features may be implemented within system 100 to limit access to that information using any of several standard methods known to those of skill in the art. Such access limitations may be based, for example, on the role that a individual has with respect to a given project or with system 100 as a whole. Thus, in one embodiment, access to data for a specific project is limited to the project team leader or members, the Gate Review Board members, the process coordinator, the process facilitator, the system administrator, and the information-technology manager. In other embodiments, access may be provided according to different criteria as appropriate for the organization.
In addition to the specific gate-processing (decision steps) and stage- processing (action steps) features described below, system 100 also may be configured to link directly to a variety of standardized tools and information. Such links may be configured so that fields from within system 100 are imported directly into such standardized tools to act on idea or project data. The standardized tools and information may include, for example, a company accounting or enterprise resource system, financial analysis spreadsheets, project plan templates, business plan templates, test request forms, company standard operating procedure documents, quality assurance test method documents, manufacturing production method documents, product drawings and specifications, training material, glossary to company terms, etc.
A. Gate Processing
Referring now to Figs. 17 and 18(a)-18(j), a process of managing a project at a decision stage in accordance with one embodiment of the present invention will be discussed. Fig. 17 comprising a flow diagram illustrating the process. As discussed above, the first decision step typically is the decision to convert an idea into a project, to hold the idea, or to archive the idea. In accordance with this aspect of the present invention, system 100 automatically generates "Gate 1" documents and information to be used in the "Gate 1" decision step. "Gate 1" documents may comprise an idea document as discussed above, as well as "Gate 1" information and other supporting documentation that may be helpful for Gate Review Board ("GRB") members to make a decision on whether or not to proceed with a project. For all of the forms described below, external documents may be attached in the same manner described above for the idea-submission form 500 and project definition form 700.
Similarly, as a project progresses from an action stage to a decision stage, system 100 generates documents/information to be used in the decision stage. Information generated and maintained by system 100 may include project (or idea) information, a Stage form, a GRB purpose and agenda, GRB meeting information, information noting a value that a project may have to a business, key deliverable documents, Go/No-Go Criteria, etc. As one skilled in the art will appreciate, the amount and type of information available at a decision step will vary based on the stage a project is in. For example, when a project is in the idea or pre-project stage, only a little information may be available. However, if is project is toward one of its final stages, such as manufacturing, much more information may be available. Also, Go/No-Go criteria will be unique to each decision stage based on the governing division-business unit-market segments in which the project resides.
When a project enters a decision stage, system 100 already will have generated documents/information associated with the project. For example, idea information automatically is generated by the submission of an idea. In addition, as illustrated in Fig. 19, the output of a Stage/action step is documents/information 1926 for the next Gate/decision step. At step 1702 in Fig. 7, Gate/decision step documents/information are provided or made available to members of a GRB. Once the documents/information are created, one or more members of the GRB (preferably the chairman) are notified that the project now is in a decision step. Members of the GRB then can edit the documents as needed (step 1704). The notification to the GRB members may comprise an email with a hyperlink to the associated decision step documents. Alternatively, the members of the GRB can access the decision step documents through the "Projects" pull-down menu 1302, as discussed above. For example, as illustrated in Fig. 18(a), by selecting a project 1802, a Project Definition page
1806 will be displayed (Figs. 18(b) - 18(d)). By selecting hyperlink 1804, documentation and information relevant to the GRB review process can be accessed. Figs. 18(c)-18(j) illustrate screens that can be used to access and edit the decision step documentation.
As illustrated in Fig. 18(c), decision step information and documentation may include project information (button 1808), GRB purpose and agenda information (button 1810), GRB meeting information (button 1812), business value information (button 1814), hurdle rate 1816, key deliverable documents (button 1818), Go/No-Go criteria (button 1820), and GRB decision information (button 1822). When a user selects "Project Info" button 1808, screen 1807 in Fig. 18(e) is displayed. Using screen 1807, the user can view and/or modify information about the project, such as project number 1824, project name 1826, project type 1828, project leader 1830, project start date 1832, division 1834, business unit 1836, market segment 1838, and expected product launch date 1840. As discussed above, system 100 preferably automatically populates these fields when the project document is created. However, as one skilled in the art will appreciate, as a project progress through the development process, some of the information may need to be changed. Thus, system 100 allows users to modify certain project information as needed. To modify certain information, however, the user must have the proper security access.
To access GRB purpose and agenda information, a user selects the "GRB Purpose and Agenda" button 1810, which causes screen 1842 in Fig. 18(f) to be displayed. Using screen 1842, the user can review, add to, or modify the GRB meeting purposes 1844 and the GRB meeting agenda criteria 1846. In accordance with one embodiment of the present invention, GRB meeting purposes and agenda information originally can be defined during the Setup/ Admin procedure and later reviewed or modified as needed by GRB members during the GRB review process. In accordance with this aspect of the present invention, system 100 allows a company to define default GRB meeting purposes and agendas for each decision step, but also allows the GRB members to deviate from the default entries as they deem necessary.
After the project and GRB purpose and agenda information is reviewed, a GRB member can schedule a GRB meeting. To access the GRB meeting screen 1848 (Fig. 18(g), the user selects the "GRB Meeting Info" button 1812. Using screen 1848, the user can modify the GRB chair field 1850 and the GRB member field 1852. In addition, the user can define GRB surrogates or proxies 1854, a GRB recorder 1856, a GRB meeting date 1858, a GRB meeting time 1860, and a meeting place 1862. To set the GRB meeting date, the user can select the "Set Date" button 1863, which will display a pop-up calendar. The user then can select the appropriate date from the calendar, and the meeting date field 1858 automatically will be populated with that date. Once all the information is entered, the user can submit the information by selecting a "Submit" button (not shown). Upon submission of the meeting information, members of the GRB (including surrogate members) automatically are informed of the scheduled meeting, for example by email or other communication means, and the meeting is posted on a system calendar for access by system users. In addition, the decision step information and documentation is forwarded to the members, so that they can review the information prior to the meeting.
As one skilled in the art will appreciate, some or all of the fields on the screens illustrated in Figs. 18(e) - 18(g) may be mandatory fields. Therefore, after a user selects the "Submit" button, system 100 will verify that all mandatory fields are entered (step 1706 in Fig. 17). If information is not entered into the mandatory fields, system 100 will send an error message, and the user is prohibited from continuing until the fields are entered. When all mandatory fields are completed, system 100 then will send the notification to the GRB member with the accompanying documentation and information (steps 1708 and 1710). Upon receiving notification of the meeting, GRB members are given the opportunity to confirm or deny the date and time of the meeting (step 1712). Confirmation may occur by selecting an "Accept Meeting" button (not shown) on the notification email. By selecting the "Accept Meeting" button, an automatic confirmation is sent to user scheduling the meeting. Similarly, if the scheduled meeting conflicts with a GRB member's schedule, he may deny the meeting and then provide alternative dates and times that will work for him. Once it is determined that the meeting needs to be rescheduled, the GRB Recorder or GRB Chair can reschedule the meeting by selecting a "Reschedule Meeting" button (not shown). The user scheduling the meeting can use the information regarding alternative dates and times provided by the conflicted member(s) to help schedule a new meeting date and time.
Seven days before the scheduled meeting, system 100 may send out a meeting reminder notification, such as by email, of the meeting's date, time, and place to all those who should attend. Similarly notifications may be sent at other times appropriate for reminding members of the scheduled meeting, such as one day prior to the meeting and one hour prior to the meeting.
On the scheduled date and time, the GRB holds its meeting to make a decision on whether or not to proceed with the project (step 1714). At the meeting, members of the GRB can designate key deliverable documents and attach them to the project definition. To attach new documents to the project or to review already attached documents, a user selects the "Attachments" button 1818, which causes a screen to be displayed listing all of the attached documents. In addition, using the same screen, the user can browse for and attach documents to the project that reside anywhere on a company network. During a decision step meeting, the members of the GRB typically analyze the
Go/No-Go criteria to determine whether the company should proceed with the project in question. The Go/No-Go criteria can be access by selecting the "Go/No-Go Criteria" button 1820, which causes screen 1882 illustrated in Fig. 18(i) to be displayed. On screen 1882, the Go/No-Go criteria 1884 for the particular decision step is listed. Next to the Go/No-Go criteria are check boxes 1886 for checking off the criteria when it has been met. Typically, the members of the GRB will review the criteria as a group and determine if it has been met. If so, a user, for example the GRB recorder, will check boxes 1886 on screen 1882.
In accordance with some embodiments of the present invention, the Go/No- Go criteria for each decision step are defined during the setup process. One embodiment allows members of the GRB, if they feel the criteria should be modified or additional criteria added for a particular decision step, to use screen 1882 to make the modifications.
Either before or after the Go/No-Go criteria have been analyzed the members of the GRB can discuss the value the product may be to the company. Such information can be review, added and/or modified using screen 1864 illustrated in Fig. 18(h), which can be accessed by selecting the "Value to Business" button 1814. Estimated financial information available on screen 1864, may include first year net sale 1866, first year gross margin 1868, net sales at maturity 1870, gross margin at maturity 1872, internal rate of return ("IRR") 1874, return on investment ("ROI") 1876, net present value ("NPV") 1878, as well as any other suitable financial information. As one skilled in the art will appreciate, some financial information may be difficult to predict during the early stages of a project. Therefore, this information typically is review at each decision step and modified as more information becomes available. Also, one skilled in the art will appreciate that any financial indicators may be used, and therefore, the present invention is not limited to the illustrated embodiment. After the financial information has been completed, the user can save the information by selecting the "Submit" button 1880.
As discussed above, during the GRB meeting, the members of the GRB attach all relevant deliverable documents to the project and make financial value determinations. System 100 automatically generates additional documents during these steps (step 1716 in Fig. 17). Finally, the GRB determines whether or not to proceed with the project to the next stage of action step (step 1718). In making this decision, the GRB members determine whether the tasks from the previous action stage were performed properly and whether all of the Go/No-Go criteria have been met, and they review the relevant financial considerations. The GRP can decide to proceed with the project, hold the project or archive the project. If the GRB decides to hold or archive the project, system 100 automatically will conduct the proper steps to hold (step 1721) or archive (step 1720) the project. Alternatively, if the GRB members decide to proceed with the project, system 100 generates documents to be used in the next action stage and then notifies team members that the project is proceeding (steps 1722 and 1724). In addition, system 100 also may automatically notify the original generator of the idea that led to the project that a decision has been made regarding the project. The supervisor of the idea generator also may automatically be notified of the decision.
To access the GRB decision screen 1888 (Fig. 18(j)), a user selects the "GRB Decision" button 1822. At the GRB decision screen, the GRB members can enter information, such as the next step in the product development process 1890 and 1892, a "hold until" date 1894 (fi the project is being held), a new project leader 1895 (if changing), a budget amount for the next stage or action step 1896, a stage expense account number 1897, comments 1898, and additional documents (not shown). Using the "Select Next Step" field 1890, members of the GRB can tell the system to archive the project, hold the project, go to the next stage or action step, or return to the previous stage or action step. If "Go to Next Stage" is selected, system 100 automatically will populate field 1892 with the next stage or action step number. For example, in the illustrated embodiment, the project currently is in the second decision step or gate. Thus, if the project is approved to go to the next stage, Stage 2 will be populated into field 1892. Similarly, if "Go to Previous Stage" is selected, Stage 1 will be populated into field 1892. In one embodiment, as with other fields in the system, the user can override the default number entered in field 1892.
After the information has been finalized on the screen in Fig. 18(j), the user can proceed by selecting the "Submit" button 1899. This either will archive the project, hold the project, or cause it to proceed to the next stage or action step.
B. Stage Processing
Referring now to Fig. 19, the process of managing a stage or action step and associated tasks is illustrated. Once a project proceeds through a gate or decision step, an action step document automatically is generated and project team members are notified of the progress of the project (step 1902). At that point a user (perhaps a project leader or someone working for the project leader) can edit the stage or action step document (step 1904). As illustrated in Fig. 18(a), once a project goes from a gate or decision step to a stage or action step, the project is classified under the "Stage in Progress" list. By selecting a project, a project definition and information page 2002 is displayed (Fig. 20(a)). The "Project Info" page 2002 (button 2004) automatically is displayed when a project is selected.
Information on the "Project Info" page may include project number 2016, project name 2018, project type 2020, project leader 2022, project start date 2024, the associated division 2026, business unit 2028 and market segment 2030, project team members 2028, expected product launch date 2030, authorized stage or action step budget 2032, as well as other suitable information as discussed above. System 100 automatically populates these fields when a GRB approves a project at the gate or decision step. However, an authorized user (e.g., a project leader) has the ability of modify some or all of the fields using screen 2002 illustrated in Fig. 20(a).
In addition to project information, a user can view and modify stage or action step purposes, value to business information, default business plan tasks, key projects and project leader recommendations. To access stage or action step purposes, the user can select the "Stage Purposes" button 2006, which causes screen 2034 illustrated in Fig. 20(b) to be displayed. This screen lists the purposes 2036 of the particular stage or action step.
Typically the stage or action step purposes are defined during Setup/ Admin, but, with the proper security access, users can add and modify the purpose using this screen.
By selecting the "Business Plan Tasks" button 2010, a user can access page 2038 listing tasks that can be completed during the current stage or action step (Fig. 20(c)). The task list page 2038 shows a list of default task 2044 that can be defined during setup, as well as a list of assigned tasks 2044. Tasks can be assigned to certain individuals by editing a default task 2044 or by creating and assigning a new task. Previously defined tasks can be modified by "double-clicking" on the task or by highlighting the task and selecting the "Assign Task" button 2047. New tasks can be created and assigned by selecting the "Create a Task" button 2046. Details of creating, editing, and assigning tasks will be discussed in more detail below. Screen 2038 also may include counter 2040 showing the number of opened assigned tasks.
As illustrated in Fig. 19, a user (e.g., a project leader) creates and/or assigns all the tasks that need to be completed during that particular stage or action step (1906). In one embodiment, system 100 monitors the process to ensure that all tasks are assigned (step 1908). Once the tasks are assigned, one or more users can manage the task performance process (step 1910). When tasks are completed, an individual performing the task or the project leader can mark the task as complete, for example by entering a check in a check-box 2048 on task list page 2038, or by modifying the "Task Assignee Detail" as discussed below. After all the tasks for a particular stage or action step are complete (step 1912), the project leader can make a recommendation to proceed to the next stage, to return to the previous stage, or to archive the project. This recommendation can be generated using screen 2050 illustrated in Fig. 20(d), which is accessible by selecting the "Project Leader Recommendation" button 2014. As illustrated in Fig. 20(d), the project leader can recommend that the project proceed to a particular stage (see fields 2052 and 2054). In addition, the project leader can enter comments (field 2056), and attach documents that may be useful in the next gate or decision step (field 2058). Relevant documents may include a business plan, financial information, Go/No-Go recommendations, a project plan for the next stage and beyond, etc. A user also can access value to business information by selecting button 2008 and other attachments by selecting button 2012. Value to business information and attachments operate in the same manner as discussed above with reference to decision steps or gates.
After the project leader enters his recommendation, system 100 automatically finalizes the stage or action step documents (step 1914) and notifies the next GRB that the stage is complete (step 1915). System 100 then determines if the project is in the last stage (step 1918). If not, system 100 automatically generates the documents need for the next gate or decision step (step 1924) and proceeds to the gate or decision step (step 1926). If, however, the project is in the last stage, system 100 automatically schedules a product implementation review ("PIR") and generates documents for the PIR (step 1920) at a time interval defined in the Setup process. In addition, system 100 automatically will notify the necessary parties of the PIR (step 1922) in order to complete it and close the project.
Referring now to Figs. 21 and 22(a) - 22(f), the process of assigning and managing tasks will be described. To create and assign a new task, the user can select the "Create a Task" button 2046. In some embodiments, it is possible to assign an existing task, by "double-clicking" on the task or highlighting the task and select the "Assign Task" button 2047. In either case, screen 2200 illustrated in Figs. 22(a) - 22(b) is displayed, which corresponds to the "Task Project Leader Details" button 2202. Using this screen, a project leader or other suitable user can enter and/or modify information about the task. Task detail information may include the section of the business plan to which the task relates 2212, a default task name 2214, a new task name 2216 if no default exists, the task status 2218 (e.g., not assigned, assigned, completed, etc.), project leader for the task 2220, the assignee 2222, the task due date 2226, task details 2230, task description 2232, task deliverables 2234, and a suggested approach to the task 2236 and any additional comments 2238. As one skilled in the art will appreciate, other task details also may be entered.
To assign a task to a resource identified as in a Team Member role in an organization, the project leader selects a person in the Assignee field 2222 and assigns a task due date in field 2226. In one embodiment, the project leader can enter names manually into field 2222, while in another embodiment, the project leader can select the name from a resources list. The resources list can be accessed by selecting button 2224. Similarly, the project leader either can enter the task due date manually into field 2226, or the project leader can select the date from a pop-up calendar by selecting the "Set Date" button 2228, according to different embodiments. As described for other entry pages above, such as for the idea- submission form 500 and for the project definition form 700, external files may also be attached to the task form. After the task information is entered, it is saved by selecting the "Submit" button 2244.
If the project leader assigns the task to an assignee, system 100 automatically will notify the assignee, for example via email or the like, that a task is assigned to him (step 2102 in Fig. 21). The assignee can access detailed information about the task by entering system 100, selecting the task, and then selecting the "Task Assignee Details" button 2204. This causes screen 2246 in Figs. 22(c) - 22(d) to be displayed. Alternatively, the email sent to the assignee may include a hyperlink, which when selected will cause screen 2246 to be displayed. In either case, the assignee can use this screen to communicate task information to the project leader. Information on Task Assignee Detail screen 2246 may include, for example, an assignee 2248, accept and decline selection buttons 2250, 2252, a field to enter a reason for declining the task 2254, task detail information 2256, a field to update the task status 2258, a field to enter comments about the task 2260, and a field to enter the date the task is completed 2262.
The first thing an assignee does with a task is accept or decline the task (step 2104). To accept the task, the assignee selects the "Accept" button 2250, and to decline the task, the assignee selects the "Decline" button 2252. If the assignee declines the task, he may be required to enter a reason for declining the task (field 2254). To submit his response, the assignee selects the "Submit" button 2264, which sends a message back to the project leader. If the assignee declines the task, the project leader is so notified (step 2108), and then the project leader must generally reassign the task (step 2110). However, if the project letter disagrees with the assignee's reasons for declining the task, it may be assigned to that assignee again, with an explanation. In this way, system 100 accommodates negotiations between task assignors and task assignees regarding, for example, the nature of the task and the due date of the task. If the assignee accepts the task, the project leader is notified, and the assignee then can begin work on the task (step 2112).
As illustrated in Fig. 22(a), a user can set certain task reminder values. To access this screen, the user selects the "Task Reminder Setup" button 2208. Using this screen the user can set reminder values, such as the number of days in advance of a task due date a reminder should be sent (field 2248), the number of days after a due date passes a reminder should be sent (field 2270), the number of days an assignee is given to accept or decline a task (field 2272), and the number of days a project leader is given to accept a completed task (field 2274). At the inception of these dates, reminder emails or other messages are sent. For example, in the illustrated embodiment, if an assignee waits longer than three (3) days to accept or decline a task, system 100 automatically will send a reminder message to the assignee. Similarly, if a project leader takes longer than three (3) days to accept a completed task, system 100 automatically will send him a reminder, and so on. An "alarm" notification also may be sent shortly before a task is due to the assignee of the task, and perhaps also automatically to the assignee's supervisor.
As an assignee works on a task, the assignee can use screen 2246 in Figs. 22(c) - 22(d) to update the status of the task (e.g., using field 2258) (step 2112). If, however, a task due date passes (step 2114), system 100 automatically will notify both the project leader and the assignee of the passed due date (step 2116). The project leader then can contact the assignee to address the situation, and then modify the due date or assign the task to a new assignee (step 2110). As discussed above, system 100 also can be configure to send due date reminders prior to the expiration of the due date (step 2118). When the assignee completes a task, the assignee enters the "Assignee Task Complete Date" 2262 on screen 2249 (step 2120), and then submits the completed task along with all deliverables to the project leader (step 2122). As one skilled in the art will appreciate, the deliverables may be electronically attached to the task complete notification.
Upon receiving a task complete notification from the assignee, the project leader then can access and review the deliverables through system 100, and make a determination of whether the task is actually complete (step 2124). If the task is not complete, the project leader updates the task information, for example using screen 2220 (step 2126), and then system 100 automatically notifies the assignee that additional work is needed (step 2128), which returns the task to step 2112. If the project leader determines that the task is complete, the project leader closes the task, for example using screen 2200 (step 2130). Upon closing the task system 100 automatically will notify the assignee that the task has been accepted (step 2132). Once system 100 detects that all tasks assigned for a particular action stage have been accepted, Gate Review Board members are automatically notified that the action step is complete.
Finally, users of system 100 can track the assignment and due date history of a task by accessing screen 2276 illustrated in Fig. 22(f). To access this screen, a user can select a particular task, and then select the "Task History Details" button 2210.
8. Conclusion
In conclusion, the present invention provides a novel method and system for managing product innovations.. While a detailed description of presently preferred embodiments of the invention have been given above, various alternatives, modifications, and equivalents will be apparent to those skilled in the art without varying from the spirit of the invention. Therefore, the above description should not be taken as limiting the scope of the invention, which is defined by the appended claims.

Claims

WHAT IS CLAIMED IS: 1. In a computer system for managing steps of a project development and management process, a method for managing the progression of an idea from a project idea evaluation (PIE) step to a preliminary project feasibility (PPF) step, the PIE step requiring the evaluation of the idea by a reviewer for a decision on whether to proceed from the PIE step to the PPF step, the method comprising: storing, in a database associated with the system, an idea submission document having information fields for capturing information about the idea; providing the idea submission document to the reviewer; receiving a decision by the reviewer as to whether the idea should progress from the PIE step to the PPF step; and in response to the decision, storing in the database a project definition document having information fields in common with information fields in the idea submission document, the system automatically copying the common fields from the idea submission document to the project definition document.
2. The method as recited in claim 1 , wherein providing the idea submission document to the reviewer comprises sending at least one email message.
3. The method as recited in claim 1, wherein the reviewer comprises a committee of individuals.
4. The method as recited in claim 1, further comprising providing the idea submission document and the decision of the reviewer to at least one individual other than the reviewer.
5. The method as recited in claim 1, wherein some of the information fields in the idea submission document are mandatory information fields and other fields in the idea submission document are optional fields, and wherein the method further comprises: before providing the idea submission document to the reviewer, determining whether all mandatory information fields in the idea submission document have been completed; and if not all mandatory information fields in the idea submission document have been completed, notifying a user that all such fields must be completed before the idea submission document will be provided to the reviewer.
6. The method as recited in claim 1, wherein the information about the idea comprises a reference to a document external to the idea submission document, and wherein providing the idea submission document to the reviewer comprises providing the external document to the reviewer.
7. The method as recited in claim 1, wherein the information about the idea comprises a classification of the idea according to a hierarchical scheme established by an organization and a categorization of a project defined by the idea according to a predetermined project grouping scheme, and wherein the decision by the reviewer includes a consideration of whether specified performance criteria for the project are likely to be met.
8. The method as recited in claim 7, wherein the specified performance criteria are defined according to the categorization of the project within the project grouping scheme.
9. The method as recited in claim 7, wherein the specified performance criteria are defined according to the classification of the idea within the hierarchical scheme.
10. The method as recited in claim 7, further comprising capturing data concerning development of the project to compare against the specified performance criteria.
11. The method as recited in claim 10, further comprising summarizing the development of a plurality of such projects according to their respective specified performance criteria for presentation to a user.
12. The method as recited in claim 11 , further comprising limiting the presentation to the user according to a classification of the user within the hierarchical scheme.
13. The method as recited in claim 1, wherein the PPF step requires a project leader to coordinate tasks to be completed during the PPF step, wherein the project definition document has a project leader field for identifying the project leader at the PPF step, and wherein the method further comprises: entering data in the project leader field of the project definition document in conjunction with the decision by the reviewer; and automatically notifying the identified project leader in response to data being entered in the project leader field.
14. The method as recited in claim 1, wherein the PPF step requires at least one human resource to perform tasks to be completed during the PPF step, wherein the project definition document has a field identifying such human resources, the method further comprising: capturing information assigning such human resources to a project defined by the project definition document; and automatically notifying each such human resource that (s)he has been assigned to the project.
15. The method according to claim 14 further comprising summarizing existing assignments for a plurality of such human resources for display to a user to assist the user in identifying which such human resources are to be assigned to the project.
16. The method as recited in claim 15 wherein such display is a graphical display.
17. The method as recited in claim 1, further comprising, for each of a plurality of sequential action steps and decision steps in a defined series following such PPF step; storing in the database (i) a set of tasks to be completed during the action step and a set of performance criteria to be used at the subsequent decision step to review the project, and (ii) a list of members of a committee assigned to perform such review at the subsequent decision step; notifying the committee of the completion of the action step; notifying the committee of a meeting to conduct the subsequent decision step by reviewing the project and determining whether the set of performance criteria has been satisfied; and in response to a determination of the committee, storing in the database that progression to the next action step in the defined series has been approved or rejected.
18. A method for managing steps of a project development and management process, wherein one or more of the steps includes tasks to be completed by allocating one or more human resources, each resource having a predetermined role during each task and possessing a set of skills useful in performing that role, the method comprising: providing a computer system with a data base; storing in the data base information associated with each resource, such information including identification of the resource, roles that can be performed by that resource, and a set of skills possessed by that resource; establishing for each task one or more roles and one or more skills required for completion of that task, and inputting those required roles and skills into the system; automatically comparing in the system the required roles and skills for each task with the information associated with each resource in order to identify one or more resources for completion of the task.
19. The method as recited in claim 18, wherein each identified resource has available a full time equivalent (FTE) workload, wherein each task is accomplished over a time period made up of time period intervals, and wherein the method further comprises: establishing, for each resource, planning information on (a) the FTE workload of that resource for each time period interval and (b) the share of the FTE workload for each time period interval expected from that resource for each task to be completed by that resource; storing the planning information in the database; displaying the planning information at a display device in order to plan the allocation of resources needed for completion of the tasks.
20. The method as recited in claim 19, wherein displaying the planning information comprises providing a graphical display.
21. The method as recited in claim 19, further comprising: capturing information assigning at least one human resource to a project; and automatically notifying each such human resource that (s)he has been assigned to the project.
22. A method for managing a plurality of sequential action steps and decision steps in a series defining a project development and management process, the method comprising: providing a computer system with a database; storing in the database, a set of tasks to be completed during each action step; a set of performance criteria to be used to review and evaluate the project at a subsequent decision step; a list of human resources assigned to that action step and the role to be performed by each such human resource within that action step; a list of members of a committee assigned to review the project at the subsequent decision step; automatically notifying the committee of the completion of each action step and of the scheduling of the subsequent decision step to review the project and determine whether the set of performance criteria has been satisfied; and in response to a determination of the committee, storing in the database that progression to the next action step in the defined series has been approved or rejected.
23. A computer system for managing steps of a project development and management process progressing an idea from a project idea evaluation (PIE) step to a preliminary project feasibility (PPF) step, the PIE step requiring the evaluation of the idea by a reviewer for a decision whether to proceed from the PIE step to the PPF step, the computer system comprising: a storage device; at least one input device; at least one display device; a processor; and at least one communications device configured to permit exchange of data among the storage device, each input device, each display device, and the processor; wherein the processor is configured to: present an idea submission document having information fields for capturing information about the idea to a user on one of such at least one display device associated with the user; store the idea submission document in a database on the storage device; provide the idea submission document to the reviewer on one of such at least one display device associated with the reviewer; and after approval of the idea by the reviewer, store in the database a project definition document having information fields in common with information fields in the idea submission document, the common fields being copied from the idea submission document to the project definition document.
24. The computer system as recited in claim 23, wherein the processor is configured to provide the idea submission document to the reviewer with at least one email message.
25. The computer system as recited in claim 23, wherein the reviewer comprises a committee of individuals.
26. The computer system as recited in claim 23, wherein the processor is further configured to provide the idea submission document to at least one individual other than the reviewer.
27. The computer system as recited in claim 23, wherein some of the information fields in the idea submission document are mandatory information fields and other fields in the idea submission document are optional fields, and wherein the processor further is configured to: determine, before providing the idea submission document to the reviewer, whether all mandatory information fields in the idea submission document have been completed; and if not all mandatory information fields in the idea submission document have been completed, notify the user on the display device associated with the user that all such fields must be completed before the idea submission document will be provided to the reviewer.
28. The computer system as recited in claim 23, wherein the information about the idea comprises a reference to a document external to the idea submission document, and wherein the processor is further configured to provide the external document to the reviewer with the idea submission document.
29. The computer system as recited in claim 23, wherein the information about the idea comprises a classification of the idea according to a hierarchical scheme established by an organization and a categorization of a project defined by the idea according to a predetermined project grouping scheme, and wherein the approval of the idea by the reviewer includes a consideration of whether specified performance criteria for the project are likely to be met.
30. The computer system as recited in claim 29, wherein the specified performance criteria are defined according to the categorization of the project within the project grouping scheme.
31. The computer system as recited in claim 29, wherein the specified performance criteria are defined according to the classification of the idea within the hierarchical scheme.
32. The computer system as recited in claim 29, wherein the processor is further configured to capture data concerning development of the project to compare against the specified performance criteria.
33. The computer system as recited in claim 32, wherein the processor is further configured to summarize the development of a plurality of such projects according to their respective specified performance criteria for presentation to the user on the display device associated with the user.
34. The computer system as recited in claim 33, wherein the processor is further configured to limit the presentation to the user according to a classification of the user within the hierarchical scheme.
35. The computer system as recited in claim 23, wherein the PPF step requires a project leader to coordinate tasks to be completed during the PPF step, wherein the project definition document has a project leader field for identifying the project leader at the PPF step, and wherein the processor is further configured to: capture data in the project leader field of the project definition document after approval of the idea by the reviewer; and automatically notify the identified project leader in response to data being entered in the project leader field.
36. The computer system as recited in claim 35, wherein the PPF step requires at least one human resource to perform tasks to be completed during the PPF step, wherein the project definition document has a field identifying such human resources, and wherein the processor is further configured to: capture information assigning such human resources to a project defined by the project definition document; and automatically notifying each such human resource that (s)he has been assigned to the project.
37. The computer system as recited in claim 36, wherein the processor is further configured to summarize existing assignments for a plurality of such human resources for display to the user on the display device associated with the user to assist the user in identifying which such human resources are to be assigned to the project.
38. The computer system as recited in claim 37, wherein such display is a graphical display.
39. The computer system as recited in claim 23, wherein, for each of a plurality of sequential action steps and decision steps in a defined series following such PPF step, the processor is further configured to: store in the database (i) a set of tasks to be completed during the action step and a set of performance criteria to e used at the subsequent decision step to review the project, and (ii) a list of members of a committee assigned to perform such review at the subsequent decision step; notify the committee of the completion of the action step; notify the committee of a meeting to conduct the subsequent decision step by reviewing the project and determining whether the set of performance criteria has been satisfied; and store in the database a determination of the committee that progression to the next action step in the defined series has been approved or rejected.
40. The computer system as recited in claim 23, wherein the at least one communications device is connected with the internet.
41. A computer system for managing steps of a project development and management process, wherein one or more of the steps includes tasks to be completed by allocating one or more human resources, each resource having a predetermined role during each task and possessing a set of skills useful in performing that role, the computer system comprising: a storage device; at least one input device; at least one display device; a processor; and at least one communications device configured to permit exchange of data among the storage device, each input device, each display device, and the processor; wherein the processor is configured to: store information associated with each resource in a database on the storage device, such information including identification of the resource, roles that can be performed by that resource, and a set of skills possessed by that resource; capture information defining, for each task, one or more roles and one or more skills required for completion of that task; and automatically compare the required roles and skills for each task with the information associated with each resource in order to identify one or more resources for completion of the task.
42. The computer system as recited in claim 41, wherein each identified resource has available a full time equivalent (FTE) workload, wherein each task is accomplished over a time period made up of time period intervals, and wherein the processor is further configured to: store planning information in the database, the planning information having been established, for each resource, on (a) the FTE workload of that resource for each time period interval and (b) the share of the FTE workload for each time period interval expected from that resource for each task to be completed by that resource; and display the planning information at one of such at least one display device associated with a user to allow the user to plan the allocation of resources needed for completion of the tasks.
43. The computer system as recited in claim 42, wherein the planning information is displayed graphically.
44. The computer system as recited in claim 42, wherein the processor is further configured to: capture information assigning at least one human resource to a project; and automatically notify each such human resource that (s)he has been assigned to the project.
45. The computer system as recited in claim 41 , wherein the at least one communications device is connected with the internet.
46. A computer system for managing a plurality of sequential action steps and decision steps in a series defining a project development and management process, the computer system comprising: a storage device; at least one input device; at least one display device; a processor; and at least one communications device configured to permit exchange of data among the storage device, each input device, each display device, and the processor; wherein the processor is configured to: store in a database on the storage device, a set of tasks to be completed during each action step; a set of performance criteria to be used to review and evaluate the project at a subsequent decision step; a list of human resources assigned to that action step and the role to be performed by each such human resource within that action step; and a list of members of a committee assigned to review that progress at the subsequent decision step; automatically notify the committee of the completion of each action step and of the scheduling of the subsequent decision step to review the project and determine whether the set of performance criteria has been satisfied; and store in the database a determination of the committee that progression to the next action step in the defined series has been approved or rejected.
47. In a computer system for managing the steps of a project development and management process, a method for configuring the system to a user organization, wherein configuration information is needed from one or more individuals within the user organization, the method comprising: providing a computer network for connecting the individuals to the computer system; storing, in a database associated with the system, the names of the individuals; automatically sending an electronic message from the computer system over the computer network to the individuals, such message requesting the configuration information; and including in the message an electronic link that is activated by the individuals in order to provide access to a specific location within the system for entry of the needed information.
48. The method as recited in claim 47, further comprising: establishing a response period for entry of the needed information by the individuals; automatically sending a reminder message to the individuals if the needed information is not entered within the response period.
49. The method as recited in claim 47, wherein the computer network is the internet and wherein the electronic link is a hypertext markup language (HTML) link.
50. A computer system for managing the steps of a project development and management process, the system configured according to the user organization using the system and comprising: a database: a processor; and a computer network connected to the database and the processor, the computer network permitting individuals to communicate with the computer system over the computer network, wherein the database stores the names of the individuals, wherein the processor is programmed to receive configuration information from the individuals over the computer network, and wherein the processor is further configured to send an electronic message to the individuals over the computer network, the message requesting configuration information and including an electronic link for accessing a document at a location in the database for entry of the requested configuration information.
51. The system as recited in claim 50, wherein the computer network is the internet and wherein the electronic link is a hypertext markup language (HTML) link.
52. In a computer system for managing a series of sequential action steps and decisions steps of a product innovation process, wherein a decision maker for at least at one of the decision steps uses one or more established criteria for making a decision at such decision step, a method for configuring the system to a user company, the method comprising: during initial setup of the system, establishing default criteria for use at the one of the decision steps; storing the default criteria in a database associated with the system; notifying the decision maker of the default criteria; and permitting the decision maker to replace the default criteria in the database with other criteria for use at the one of the decision steps.
53. The method as recited in claim 52, further comprising: storing the name of the decision maker in the database; and in response to storing the name, automatically sending an electronic message to the decision maker, such message including the default criteria.
54. The method as recited in claim 53, wherein the electronic message includes an electronic link for providing access to a location in the database for storing other criteria to replace the default criteria.
PCT/US2000/031891 1999-11-19 2000-11-20 Computer-based system and method for implementing and managing prjects WO2001037145A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU19238/01A AU1923801A (en) 1999-11-19 2000-11-20 Computer-based system and method for implementing and managing prjects

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16664099P 1999-11-19 1999-11-19
US60/166,640 1999-11-19

Publications (2)

Publication Number Publication Date
WO2001037145A1 true WO2001037145A1 (en) 2001-05-25
WO2001037145A9 WO2001037145A9 (en) 2002-05-30

Family

ID=22604130

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/031891 WO2001037145A1 (en) 1999-11-19 2000-11-20 Computer-based system and method for implementing and managing prjects

Country Status (2)

Country Link
AU (1) AU1923801A (en)
WO (1) WO2001037145A1 (en)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1372091A2 (en) * 2002-06-12 2003-12-17 Siemens Gebäudesicherheit GmbH & Co. OHG Computer system for projects control
WO2005013162A1 (en) * 2003-07-30 2005-02-10 Trialstat Corporation Systematic review system
SG109491A1 (en) * 2001-02-12 2005-03-30 Chevron Oronite Co System and method for new product clearance and development
US7533034B2 (en) 1999-07-20 2009-05-12 Brainbank, Inc. Idea management
US20210097498A1 (en) * 2019-09-26 2021-04-01 Sap Se Email enabled updates of database time records

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5953707A (en) * 1995-10-26 1999-09-14 Philips Electronics North America Corporation Decision support system for the management of an agile supply chain

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5953707A (en) * 1995-10-26 1999-09-14 Philips Electronics North America Corporation Decision support system for the management of an agile supply chain
US6151582A (en) * 1995-10-26 2000-11-21 Philips Electronics North America Corp. Decision support system for the management of an agile supply chain

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
JAUW ET AL.: "Field data is reliability information: Implementing an automated data acquisition and analysis system", IEEE, RELIABILITY AND MAINTAINABILITY SYMPOSIUM, XP002937917 *

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7533034B2 (en) 1999-07-20 2009-05-12 Brainbank, Inc. Idea management
SG109491A1 (en) * 2001-02-12 2005-03-30 Chevron Oronite Co System and method for new product clearance and development
EP1372091A2 (en) * 2002-06-12 2003-12-17 Siemens Gebäudesicherheit GmbH & Co. OHG Computer system for projects control
EP1372091A3 (en) * 2002-06-12 2004-07-14 Siemens Gebäudesicherheit GmbH & Co. OHG Computer system for projects control
WO2005013162A1 (en) * 2003-07-30 2005-02-10 Trialstat Corporation Systematic review system
US20210097498A1 (en) * 2019-09-26 2021-04-01 Sap Se Email enabled updates of database time records

Also Published As

Publication number Publication date
WO2001037145A9 (en) 2002-05-30
AU1923801A (en) 2001-05-30

Similar Documents

Publication Publication Date Title
US8122425B2 (en) Quality software management process
US9779386B2 (en) Method and system for implementing workflows and managing staff and engagements
US7930201B1 (en) EDP portal cross-process integrated view
US20060129441A1 (en) Apparatus, method, and system for documenting, performing, and attesting to internal controls for an enterprise
WO2001026014A1 (en) Method and estimator for providing service control
US20110054968A1 (en) Continuous performance improvement system
US20070067772A1 (en) Tools and methods for task management
Ng et al. Maintaining ERP packaged software–a revelatory case study
US20030097296A1 (en) Service transaction management system and process
JP2009503733A (en) Management system and method for outsourced service level agreement provisioning
US20100223557A1 (en) Method and system for workflow integration
US20060247965A1 (en) Method of defining and monitoring processes
WO2003102807A1 (en) Computer-aided system and method for evaluating employees
US20080040193A1 (en) System and method for dynamic staff bidding
US20220245589A1 (en) Contract management system
WO2007030633A2 (en) Method and system for remotely monitoring and managing computer networks
US20230153732A1 (en) Acquisition Planning System
WO2001037145A1 (en) Computer-based system and method for implementing and managing prjects
US20070192145A1 (en) Computerized sales system program
US20230316197A1 (en) Collaborative, multi-user platform for data integration and digital content sharing
Kwak A systematic approach to evaluate quantitative impacts of project management (PM)
Teh Online Academic Appointment Scheduling System
Macieira Managing a Robotic Process Automation Project Implementation
Weerasinghe Human Resource Information System with Mobile Application for Hotel
Çikot Project management with PMI standards and a critical approach to a real utilization in banking industry

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
AK Designated states

Kind code of ref document: C2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: C2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

COP Corrected version of pamphlet

Free format text: PAGES 1/40-40/40, DRAWINGS, REPLACED BY NEW PAGES 1/40-40/40; DUE TO LATE TRANSMITTAL BY THE RECEIVING OFFICE

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase