Project planning can be a daunting and stressful task that, because of its complexity, is often assigned to a dedicated project planner. A project planner may be an employee of a corporation who helps to plan and manage business projects for internal clients. In other instances, a project planner has his or her own business that offers services to outside clients. As an example, it has become increasingly common to hire planners to organize large events, such as weddings and corporate parties.
The planning of a large project often requires a high degree of coordination between the various planning stages and the entities involved to ensure that a client's requirements are satisfied within schedule and budget constraints. Many factors often combine to make such coordination a challenging task. For instance, at the beginning stages of a project, a client may be overloaded with options, thus complicating the initial definition of project requirements. In addition, once project requirements are defined, the marketplace may be saturated with vendors and product offerings, which can complicate both evaluating vendors and ultimately finding a match that provides the best value between a client's requirements and available vendors. Yet further, project requirements tend to evolve over time, either due to modifications in a client's requirements or changes in available venues, vendors, services or products. A change in one requirement may affect other requirements or aspects of the project, thus presenting further complications for efficient planning.
Some embodiments are described with respect to the following figures:
A system and method are provided to facilitate project planning. Conventionally, the project planning process entails many high-touch stages where the project planner must be actively involved in gathering and capturing various pieces of information. These pieces of information range from collecting a client's project requirements to matching those requirements with suitable products or service in a manner that meets the client's needs while still meeting project constraints, such as schedule and budget. In some respect, the advent of electronic marketplaces has facilitated the project planning process by greatly increasing the ease by which a large variety of available products and services can be identified.
However, while multiple options are beneficial, the wide variety of offerings often presents difficulties in sorting through and selecting those products and services that may be best suited for a particular project. Despite the wide variety of choices, many times a particular project requirement cannot be met within the confines of the project's time and budget constraints. At other times, project requirements may change or evolve over time, due to changes either in a client's preferences and/or in the products and services available in the marketplace. In such situations, project requirements may be modified and the process for matching requirements with product or service offerings likewise may require modification. Oftentimes, requirements are interrelated, such that modification of one requirement may affect other requirements. A further complicating factor is the presence in the electronic marketplace of many vendors of unknown reputation. All in all, coordination of the project may often become a daunting and frustrating task.
Accordingly, a project planning tool is provided to facilitate the project planning process. The project planning tool provides for gathering and acquiring a client's detailed requirements and preferences for a project, matching those requirements to vendors in a manner that optimizes the value to the client, and refining the matching solution in response to new information that is made available to the planning tool, such as new or modified requirements, project constraints, vendors, product or service offerings, etc.
As shown in
The vendor resource management system 108 may be executable on a processor 112 in the computer system 102. The processor 112 is connected through a network interface 114 to the communication network 106. In addition, the processor 112 is connected to storage media 116, which can be implemented with one or several disk-based storage devices and/or one or several integrated circuit (IC) or semiconductor storage devices.
The storage media 116 may be used to store project requirements 118 that are collected from the various clients 104. In addition, the storage media 116 may be used to store a collection of requirement options 120, such as videos, catalogs, photos, audio recordings, questionnaires, text descriptions, etc., that may be used to solicit project requirements 118 from client 104, as will be discussed in further detail below. Yet further, the storage media 116 may be used to store a numerical model 122 of the project that is generated based on the requirements collected from a client 104, as well as a solution 124 of a matching between project requirements 118 and vendors 110. In some embodiments, and as will be discussed in further detail below, the storage media 116 may also be used to store reputation information 126 regarding various vendors 110 that may be used to match vendors 110 to project requirements 118.
Starting first with the discovery phase of the project planning process, this phase involves the acquisition of both general and detailed project requirements. For instance, general information regarding the scope of the project may first be gathered during initial meetings or contact with a client, such as type of project (e.g., reunion, wedding, etc.), size of project, schedule, budget, number of attendees, general ideas or vision for the project, etc. This information may be input to the vendor resources management system 108 by a client computer 104 via the network 106. In some instances, the client computer 104 may be located at the client's home or place of business. In other instances, the client computer 104 may be located at the project planner's place of business, in which case communications may be established over a local communication network 106. In any event, during the discovery phase, the goal is to acquire as much information as possible from the client regarding the client's requirements and preferences.
To facilitate the acquisition of information, the vendor resource management system 108 includes a Requirements Module 130. For instance, the general project requirements may be provided as an input to the Requirements Module 130 so that the Module 130 may then solicit detailed requirements. As an example, the general requirements may assist the Module 130 in formulating or selecting a questionnaire to present to the client, as well as with selecting requirement options maintained in storage media 116 regarding various services or products in which the client may be interested or which may assist the client with formulating or articulating the client's requirements and preferences. The Module 130 may present options to the client in the form of menu items where selection of a menu item may lead to the presentation of further requirement options that are relevant to the type of project being planned.
Any suitable format may be used to present information to the client. For instance, the client may be presented with photographs, videos, audio recordings, text, etc. that may assist the client in defining the client's project requirements, including attributes of those requirements. As an example, if the client is planning a wedding and indicates that music is a requirement, various musical selections may be presented to which the client can listen. In addition, if the client indicates that floral arrangements are a requirement, photographs or pictures of floral arrangements may be presented so that the client may further define attributes of the desired floral arrangement, such as types of flowers, colors, etc. The Requirements Module 130 may use questionnaires to solicit further details or may allow the client to input comments regarding the client's requirements. The Requirements Module 130 may also accept input from the client in the form of photographs, videos, audio recordings, text, etc. and may use these submissions to discern the client's project requirements and associated attributes. The attributes acquired from the client need not have discrete values (e.g., the flower is red), but may also be expressed in terms of a continuous value or range (e.g., the number of attendees may be between 100-150).
In addition to acquiring the client's project requirements, the Requirements Module 130 determines the relative importance of the attributes associated with the requirements. In an exemplary arrangement, relative importance is determined based on rankings or ratings that are provided by the client or otherwise obtained based on information provided by the client. For instance, the client may be asked to rank attributes in accordance with a numerical ranking system.
As an example, the client has indicated a requirement for floral arrangements that include red roses. The client may indicate that the most important attribute of the floral arrangement is the color (i.e., red) and the least important attribute is the type of flower (i.e., roses).
The Requirements Module 130 may also discern preferences or rankings in other manners. For instance, the Requirements Module 130 may present a series of questions to the client, the response to which may provide an indication of the client's preferences and the relative importance of those preferences.
Once the Requirements Module 130 has acquired at least an initial set of requirements and associated attributes, a Scoring Module 132 analyzes the acquired information in order to generate a numerical model 122 of the project. For instance, the Scoring Module 132 may derive scores for the attributes based on the rankings, responses, comments and other information obtained from the client. The scores assigned to the attributes may be discrete values, a range of values, probability distributions, etc. The attributes are mapped to the scores and a numerical model 122 corresponding to the project is generated.
In an exemplary, arrangement, the Scoring Module 132 may also include an adaptive learning algorithm that uses past experiences in assigning scores to enhance the efficiency of the process of generating the numerical project model 122.
Once the project model 122 has been generated, the vendor resource management system 108 can then match the project's requirements to products and services offered by various vendors 110. Towards this end, the vendor resources management system 108 includes a Vendor Matching Module 134. Initial identification of suitable vendors 110 may be performed in a variety of manners. For instance, the vendor resources management system 108 may be in communication with an electronic marketplace service with which vendors 110 may register and advertise their products/services. The vendor resource management system 110 also may maintain a database of known vendors 110 and products and may consult that database to select suitable offerings. Yet further, the vendor resource management system 108 may generate search requests that are broadcast on the communication network 106 so that potential vendors 110 may be identified. In some implementations, the vendor resource management system 108 may direct requests for proposal to various vendors 110, and interested vendors 110 may respond with bids. The vendor matching module 108 can then match received bids to the project's requirements in a suitable manner.
More particularly, in an exemplary implementation, the goal of the Vendor Matching Module 134 is to provide scoring-based matching between requirements 118 and vendors 110 within the constraints of the client's budget and schedule. As an example, the Vendor Matching Module 134 may generate a matching solution 124 that optimizes the overall score of the numerical project model 122 within the constraints of the project's budget. For instance, optimization criteria may be defined that require the Matching Module 134 to optimize the model 122 by maximizing the model's overall score. The matching solution 124 may be fuzzy. The solution 124 may include a specific matching, a range, or a probability distribution. In one example of the Matching Module 134, the matching is implemented by stochastic optimization using known matching algorithms. In other examples, other matching algorithms and optimization techniques may be used depending on the particular types and requirements of the projects in which the matching is implemented.
It should be understood that optimization techniques and optimization criteria may vary depending on the particular project or type of project that is being planned. For instance, an optimized score of the project model 122 may be the score that satisfies all of the client's requirements within the confines of the budget. Alternatively, an optimized score may be the score that provides the best value to the client even though some attributes may not have been satisfied. Yet further, an optimized score may be a solution that offers the greatest amount of flexibility in the event that the client knows that there is a high likelihood that the project requirements will be modified in the future.
Regardless of the particular optimization technique used, once a matching solution 124 has been obtained, the solution 124 may be passed to a Delivery Management Module 136, which presents the matching solution 124 to the client for review. At this point, the client may simply accept the solution and the Delivery Management Module 136 then ensures that the proper agreements are finalized with the appropriate vendors 110, if necessary. Alternatively, the client (or the project planner) may refine the requirements and/or the attributes of those requirements, including modifying the budget, changing the number of attendees, modifying rankings associated with attributes, adding new requirements, etc. If changes are made, then the scoring and matching process may be repeated until the client is satisfied with the results and the Delivery Management Module 136 has completed negotiations and entered into agreements with the appropriate vendors
Ideally, the project planning process should be complete at this point and requirements firmly established. However, it is possible that various events may occur that may change the project's requirements. For instance, a client may become aware of new information that may prompt the client to change requirements, such as a need to provide a special menu for certain guests. As another example, a vendor or the vendor's products may become unavailable under the terms that were previously negotiated. As yet another example, a new vendor may become available that may offer more value to the project. Regardless of the reason for the change, a need to refine the deliverables may arise in response to the receipt of new information from either the client or the vendors.
Accordingly, exemplary arrangements of the Delivery Management Module 136 include an automatic renegotiation trigger 137 that is activated in response to the receipt of new information that is relevant to a planned project. In such a situation, if the new information changes the project's requirements 118, then the activation of the trigger 137 causes the Scoring Module 132 to refine the scores assigned to the requirement attributes so that an updated numerical project model 122′ may be generated. The Vendor Matching Module 134 receives the updated model 122′ and then refines the matching solution to optimize the overall score of the updated model 122′. The refined matching solution 124′ is provided to the client for review, further refinements may be made, and purchase contracts are re-negotiated if feasible and/or agreements are reached with new vendors 110. In situations in which the new information learned by the system 108 does not modify the project requirements 118 but only affects product availability, then the Vendor Matching Module 134 may simply compute a new solution 124′ based on the existing project model 122.
In some implementations of the Delivery Management Module 136, the re-negotiation trigger 137 may be activated in response to the receipt of any new information. In other implementations, the trigger 137 may be activated only if re-negotiation is feasible or if the new information will result in an improved matching solution.
Referring now to
In some implementations of the vendor resource management system 108, vendor matching may be further facilitated by a Reputation System 138 that collects and maintains information relating to the reputation of various vendors 110. The Reputation System Module may be included on the computer system 102, as shown in
The reputation information 126 may then be provided to the Vendor Matching Module 134 so that a vendor's reputation may become a factor that affects the matching solution 124. For instance, the matching algorithm may be configured to optimize the score of the project model 122 using only vendors 110 having a reputation above a specified threshold. Yet further, the matching algorithm may provide a range of matching solutions 124 that demonstrate tradeoffs between value and reputation.
In yet other implementations, vendor reputation can be a requirement that is input by the client. For instance, the client may specify that only vendors having a specified reputation score may be considered for the matching.
The various modules described above for performing the project planning technique 150 depicted in
Instructions of software described above (including the planning process 150 of
Data and instructions are stored in respective storage devices, which are implemented as one or more computer-readable or machine-readable storage media. The storage media, such as media 116 in
In the foregoing description, numerous details are set forth to provide an understanding of the subject disclosed herein. However, implementations may be practiced without some or all of these details. Other implementations may include modifications and variations from the details discussed above. It is intended that the appended claims cover such modifications and variations.