WO2001037145A9 - Systeme et procede informatiques de mise en oeuvre et de gestion de projets - Google Patents

Systeme et procede informatiques de mise en oeuvre et de gestion de projets

Info

Publication number
WO2001037145A9
WO2001037145A9 PCT/US2000/031891 US0031891W WO0137145A9 WO 2001037145 A9 WO2001037145 A9 WO 2001037145A9 US 0031891 W US0031891 W US 0031891W WO 0137145 A9 WO0137145 A9 WO 0137145A9
Authority
WO
WIPO (PCT)
Prior art keywords
project
information
idea
recited
resource
Prior art date
Application number
PCT/US2000/031891
Other languages
English (en)
Other versions
WO2001037145A1 (fr
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/fr
Publication of WO2001037145A9 publication Critical patent/WO2001037145A9/fr

Links

Classifications

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

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, hi 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.
  • 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.
  • 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 apage 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 hyperhnked 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 supervisors) 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. If system 100 is so configured, idea-submission fo ⁇ n 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.
  • 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 'Trint 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.
  • project-assignment form 970 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.
  • 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.
  • 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 IN 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 IN 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. 120 " ), 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 proj ect 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 mclude 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, hi 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

L'invention concerne un système et un procédé informatiques conçus pour gérer les étapes d'un processus de mise au point et de gestion de projet. Dans ledit processus, il peut s'agir de l'avancement d'une idée (200) de l'étape d'évaluation (202) d'une idée de projet à l'étape préliminaire de faisabilité du projet. L'étape d'évaluation (202) exige l'évaluation de l'idée par un examinateur qui décidera de la, ou de ne pas la poursuivre. Ledit examinateur reçoit un document de soumission (500) d'idée, stocké dans une base de données associée au système, qui contient des champs d'informations destinés à la saisie d'informations concernant l'idée. En réponse à la décision émanant de l'examinateur quant à la poursuite éventuelle de l'idée, on stocke, dans la base de données, un document de définition de projet contenant, en commun avec le document de soumission d'idée, des champs d'informations, les champs en commun étant copiés automatiquement.
PCT/US2000/031891 1999-11-19 2000-11-20 Systeme et procede informatiques de mise en oeuvre et de gestion de projets WO2001037145A1 (fr)

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 WO2001037145A1 (fr) 2001-05-25
WO2001037145A9 true WO2001037145A9 (fr) 2002-05-30

Family

ID=22604130

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/031891 WO2001037145A1 (fr) 1999-11-19 2000-11-20 Systeme et procede informatiques de mise en oeuvre et de gestion de projets

Country Status (2)

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

Families Citing this family (5)

* 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
US20020111850A1 (en) * 2001-02-12 2002-08-15 Chevron Oronite Company Llc System and method for new product clearance and development
EP1372091A3 (fr) * 2002-06-12 2004-07-14 Siemens Gebäudesicherheit GmbH & Co. OHG Système d'ordinateur pour le contrôle de projets
CA2533267A1 (fr) * 2003-07-30 2005-02-10 Trialstat Corporation Systeme de revue systematique
US20210097498A1 (en) * 2019-09-26 2021-04-01 Sap Se Email enabled updates of database time records

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0770967A3 (fr) * 1995-10-26 1998-12-30 Koninklijke Philips Electronics N.V. Système d'aide de décision pour la gestion d'une chaíne de l'alimentation agile

Also Published As

Publication number Publication date
AU1923801A (en) 2001-05-30
WO2001037145A1 (fr) 2001-05-25

Similar Documents

Publication Publication Date Title
US20180365628A1 (en) Agile teams freelance-sourcing: online system and method for enhancing success potential of freelance projects
US9779386B2 (en) Method and system for implementing workflows and managing staff and engagements
US8122425B2 (en) Quality software management process
US6754874B1 (en) Computer-aided system and method for evaluating employees
US7930201B1 (en) EDP portal cross-process integrated view
WO2001026014A1 (fr) Procede et estimateur destines a la mise en oeuvre d'une commande de services
US20060129441A1 (en) Apparatus, method, and system for documenting, performing, and attesting to internal controls for an enterprise
US20110054968A1 (en) Continuous performance improvement system
US20070067772A1 (en) Tools and methods for task management
US20030097296A1 (en) Service transaction management system and process
US20100223557A1 (en) Method and system for workflow integration
JP2009503733A (ja) アウトソーシングしたサービスレベルアグリーメントプロビジョニングのマネジメントシステムおよび方法
US20080040193A1 (en) System and method for dynamic staff bidding
WO2007030633A2 (fr) Procede et systeme de surveillance et de gestion a distance de reseaux informatiques
US20230153732A1 (en) Acquisition Planning System
WO2001037145A9 (fr) Systeme et procede informatiques de mise en oeuvre et de gestion de projets
US20070192145A1 (en) Computerized sales system program
US20230316197A1 (en) Collaborative, multi-user platform for data integration and digital content sharing
US8533027B1 (en) User interface enabling approval/disappoval of revised contract performance indicators
Macieira Managing a Robotic Process Automation Project Implementation
Teh Online Academic Appointment Scheduling System
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
Hasibović et al. The importance of ITIL4 adoption for IT service management in insurance companies
Clapp et al. A guide to conducting independent technical assessments

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