PROJECT MANAGEMENT SYSTEM AND METHOD

FIELD OF INVENTION

The invention relates to the field of electronic project management and in particular to an electronic stakeholder relationship management and project management planning system and method.

BACKGROUND TO INVENTION

Planning and decision-making processes are more effective if the interests of all affected parties (often referred to as stakeholders) are considered and issues resolved before any decisions are made about what action to take. In some cases, management of and consultation with stakeholders is required by law and/or policy and therefore could have a significant impact on the outcome of a project.

However, the process of stakeholder management can be time-consuming and expensive, not least of all because of the number of man-hours that are generally involved in manually compiling information about all relevant stakeholders, analysing and organising this information, and planning the appropriate response.

It would be useful to have a system and/or method that facilitates stakeholder management and project management processes by automating the co-ordination and integration of stakeholder relationship management data. Alternatively it would be useful to have a stakeholder relationship management and project management planning system and/or method that at least ameliorates one or more of the above-mentioned difficulties or which at least provides the public with a useful choice.

It would also be useful to have a system that can distinguish between stakeholders who are project collaborators or partners and those from the general public.

SUMMARY OF INVENTION

In one form the invention provides a project management system comprising a project identifier configured to obtain from a user a project type or project name; a project record retrieval component configured to retrieve at least one project record from a plurality of project records stored in computer memory using the user specified project type or project name; a stakeholder retrieval component configured to retrieve at least one stakeholder record from a plurality of stakeholder records stored in computer memory; and a project deliverables generation component configured to generate, at the request of the user, at least one project deliverable from at least the retrieved project record and/or the retrieved stakeholder record.

The term "comprising" as used in this specification means "consisting at least in part of; that is to say when interpreting statements in this specification which include the term "comprising", the features prefaced by this term in each statement all need to be present but other features can also be present. Related terms such as "comprise" and "comprised" are to be interpreted in a similar manner.

In another form the invention provides a method of managing a project comprising obtaining from a user a project type or project name; retrieving at least one project record from a plurality of project records stored in computer memory using the user specified project type or project name; retrieving at least one stakeholder record from a plurality of stakeholder records stored in computer memory; and generating, at the request of the user, at least one project deliverable from at least the retrieved project record and/or the retrieved stakeholder record.

In another form the invention provides a project management computer program comprising a project identifier component configured to obtain from a user a project type or project name; a project record retrieval component configured to retrieve at least one project record from a plurality of project records stored in computer memory using the user specified project type or project name; a stakeholder retrieval component configured to retrieve at least one stakeholder record from a plurality of stakeholder records stored in computer memory; and a project deliverables generation component configured to generate, at the request of the user, a project deliverable from at least the retrieved project record and/or the retrieved stakeholder record.

The invention further provides a project management computer program for performing a method comprising obtaining from a user a project type or project name; retrieving at least one project record from a plurality of project records stored in computer memory using the user specified project type or project name; retrieving at least one stakeholder record from a plurality of stakeholder records stored in computer memory; and generating, at the request of the user, at lease one project deliverable from at least the retrieved project record and/or the retrieved stakeholder record.

In yet further forms the above computer programs are stored on a computer-readable medium.

BRIEF DESCRIPTION OF THE FIGURES

Preferred forms of the invention will now be described with reference to the accompanying drawings in which:

Figure 1 illustrates a preferred network environment in which the invention may be practiced;

Figure 2 illustrates preferred systems architecture for one or more exemplary embodiments of the invention;

Figure 3 is a flow diagram of the project management lifecycle in accordance with one or more exemplary embodiments of the invention;

Figure 4 illustrates a typical stakeholder record

Figure 5 illustrates a typical project record

Figure 6 illustrates an exemplary arrangement for a conceptual data model according to one or more exemplary embodiments of the invention;

Figure 7 illustrates some of the interrelationships between the elements of the conceptual data model illustrated in Figure 6;

Figure 8 is a block diagram illustrating the flow of data between a stakeholder meta- model data-store and a project management instance in accordance with one or more exemplary embodiments of the invention; and

Figure 9 illustrates in more detail steps and data flow involved in the project management lifecycle.

DETAILED DESCRIPTION

The present invention is embodied in the methods herein described including the methods as implemented in any suitable computing environment. The invention is also

. _

embodied by computer software that implements the invention including computer programs comprising computer-executable instructions that, when executed in an appropriate computing system, will cause the system to perform the methods of the invention. Computer software may include computer programs, computer modules, routines, objects, components, or data structures that perform particular tasks. The invention may be embodied in such computer-executable instructions as stored in any computer-readable medium. The invention is also embodied by any system that is a combination of hardware and software that is configured to perform the methods of the invention, for example by being programmed with appropriate computer-executable instructions.

Figure 1 illustrates a block diagram of a suitable network arrangement 100 in which one form of the present invention 105 may be implemented. Network arrangement 100 is only one example of a suitable network environment and is not intended to suggest any limitation to the use or functionality of the invention.

The system 100 preferably includes one or more clients 110, for example HOA, HOB, HOC, 11 OD, HOE, and 11 OF which each may comprise a personal computer or workstation as described below. It will be appreciated that clients 110 may also comprise any device with sufficient processing, input, and output capabilities to provide an interface to the invention, for example, a laptop, pocketPC, or mobile telephone.

Each client 110 is interfaced to the invention at 105 as shown in Figure 1. Each client could be connected directly to the invention, could be connected through a local area network or LAN, could be connected through the Internet, through a wireless network, or any combination of the above.

Clients IIOA and 11OB, for example, are connected to a network 120, such as a local area network or LAN. The network 120 could be connected to a suitable network server 125 and communicate with the invention as shown. Client HOC is shown connected

directly to the invention 105. Clients 11OD, 11OE, and 11OF are shown connected to the Internet 130. Client HOD is shown as connected to the Internet 130 with a dial-up connection and clients HOE and 11OF are shown connected to a network 140 such as a local area network or LAN with the network 140 connected to a suitable network server 145.

It will be appreciated that a client 110 may be connected to the invention 105 directly, via a network or via the Internet 130 by any available means such as, for example, wireless or cable.

One exemplary form of the invention at 105 comprises a personal computer or server 150 operating under the control of appropriate operating and application software having a data memory 160 storing local data for the invention. Local data stored in data memory 160 includes one or more computer programs, computer modules or components in the form of computer-executable instructions which, when processed by server or personal computer 150 will cause the server or personal computer 150 to perform the methods of the invention.

Figure 2 shows an exemplary system architecture of a client 110 or server 150. System 200 is only one example of a suitable computing environment and is not intended to suggest any limitation on the use or functionality of the invention nor is it intended to suggest any dependency or requirement for any one or combination of components illustrated in Figure 2. The invention is capable of being embodied in a number of computing system environments or configurations. The invention may also be implemented in a distributed computing environment in which tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

The computer system 200 typically comprises one or more processors 202, a main memory 204 for example RAM, and an input/output controller 206. Exemplary system 200 also comprises non- volatile storage memory 160 in the form of one or more computer-readable media such as, for example, an internal hard drive or removable drive, floppy disk, or CD-Rom. The exemplary computer system 200 may also comprise peripherals such as a keyboard 208, a pointing device 210, for example a mouse, touchpad, or trackball, a display or screen device 212, and an output device 216 such as a printer. The system 200 could also include a network interface card or controller 218 and/or a modem 220. The individual components of the system 200 could communicate through a system bus 222.

Data memory 160 stores local data for the invention. Such data may include a database, meta-base or any other appropriate form of data-store containing known or existing information about possible stakeholders who may be included in any particular project. A stakeholder retrieval component retrieves stakeholder records or instances from data memory 160.

This data may take the form of a stakeholder meta-model or meta-store. The exact nature of the information will depend on the context in which the invention is used. But it is envisaged that important attributes of stakeholders will be searchable, for example by reference to meta-data about the stakeholder, so that the decision-maker can locate likely stakeholders from the stakeholder data-store that may need to be involved in any particular project.

In this specification the example is used of a governmental roading authority planning the route of proposed roads or highways. In this example, the governmental authority must consult local tribes of indigenous peoples who have a connection to the land over which the proposed road or highway will cross. However, it will be appreciated by those skilled in the art, that the invention may be used for any decision-making process for which consultation with stakeholders is recommended or required. Therefore, throughout this specification, the party that is required or who wishes to conduct

consultation with stakeholders, such as the governmental roading authority, will be referred to as the decision-maker. In addition, the example makes use of words in the Maori language. The meaning of Maori words unfamiliar to the reader may be determined by reference to a Maori dictionary.

A flow diagram 300 of the project management life-cycle of a project in accordance with one or more exemplary embodiments of the invention is illustrated in figure 3.

The invention provides an interface, preferably web-based. The interface includes or comprises a project identifier component. The decision-maker may use the interface to select or enter details of the subject matter and other important details about the proposed project thus either creating a new instance of a project or retrieving an existing project record or instance. A project record retrieval component is configured to do this. The step of creating a new project instance is shown at 310 in figure 3.

The interface may also provide access to any pre-existing information about potential stakeholders in data memory 160, for example a stakeholder meta-model. The step of importing stakeholder data into the project instance is shown at 320 in figure 3.

In the example of the governmental roading authority that must consult with local tribes of indigenous peoples, the existing information stored at 160 may include details of the geographical areas over which each tribal group claims a significant connection. In this embodiment, the geographic information may form part of the stakeholder meta-model. The decision-maker in this case may be able to select the affected stakeholders simply by selecting portions on a geospatial map-type interface that represent where the proposed road will pass. The invention may then automatically retrieve all available data about known tribes who will be affected by the proposed road from the stakeholder meta-model in the data-store at 160. Such data will preferably include details of sub- tribes and/or pan-tribal groups that may also need to be consulted individually.

In other embodiments the decision-maker may need to use other types of searches of the stakeholder meta-model in order to locate potential stakeholders for any particular project. This may involve using key-word or name searches of the stakeholder meta- model.

Where it is not clear from the stakeholder meta-model who the stakeholders for a particular project are (for example, if data on the most likely stakeholders is not present in the stakeholder meta-model) then it may be necessary to prepare a list of possible stakeholders from other sources and enter them into the stakeholder meta-model. The stakeholders added to the meta-base or database will then be available for all future projects. Thus the invention enables decision-makers to build a repository of potential stakeholder data.

Figure 4 shows a typical stakeholder data record 400. The record includes at least a stakeholder type 410 and stakeholder name 420. The stakeholder type field contains one of a finite set of types for example INDIVIDUAL, IWI or GOVERNMENT AGENT. The list of stakeholder types is configurable by the system administrator.

Further fields in the stakeholder record 400 are configurable by the administrator. The administrator sets up attributes, names the attributes, and identifies which of the attributes are mandatory or optional.

Figure 5 shows a typical project data record 500. The record includes at least a project type 510, a project name 520 and a lifecycle state 530. The lifecycle state identifies the state the project management process is in that is represented by the data record 500.

Further fields in the project record 500 are configurable. As described above with reference to the stakeholder data record, the administrator reconfigures the record as needed.

It is envisaged that all pre-existing data in the stakeholder meta-model and all additional data needed to create the project will conform to the data model arrangement illustrated in figure 6. This arrangement is enforced by the instance of a project that is produced by the invention.

The invention generates a project instance that both provides an interface to any preexisting data retrieved from the stakeholder meta-model by the invention and that also provides a framework and interface through which the decision-maker can enter all remaining data required for the project. The instance of the project is completed by enabling the decision-maker to enter all the data set out in figure 6. The completion of the project instance creates one or more deliverables in the form of documentation, for example a comprehensive plan for the actual process that provides the decision-maker with comprehensive best-practice data in relation to each of the stakeholders in the project. Completion of the project instance is shown at 330 in figure 3.

The data for the project is organised under three main headings, namely, Relationship data 610, Equity data 620, and Management data 630. Relationship data 610 relates to who will be engaged in the project, Equity data 620 relates to when and in relation to what interaction with a stakeholder will be involved, and Management data 630 relates to how the interaction is to be conducted.

Relationship data, Equity data and Management data are compiled by a Relationship data component, an Equity data component and a Management data component respectively. These components both obtain data from a user and from other sources.

A number of different data types including specific examples of data items are provided below with reference to the roading authority example set out above. The particular examples given are not to be construed as limiting the scope of the invention. Any one or more of a plurality of different arrangements of data items may be used without

departing from the scope of the invention. In particular, specific data items may be different depending on the subject matter of the project to which the invention is being applied.

Relationship data can be divided into four different types. Data of each type may be entered via consecutive fields in the interface to the invention. Each field may build on the previous field. Data entered in one field may impact on the options provided for following fields. This may be the case for all data entered via the user interface.

As shown at 61 OA, the first type of relationship data is stakeholder data identifying the stakeholders who may be impacted by the decision for which the consultation is required. Typically this data is imported from the stakeholder meta-model as described above. Such data may include an identifier of the stakeholder, their status, a contact person including their role and context, affiliations, contact details, and any mitigating factors that may be a barrier to delivering the project. The table below sets out an example arrangement of data types for the first type of relationship data item in the context of the user example.

As shown at 610B, the second type of relationship data is alliance data that identifies other parties or organisations that a stakeholder has an association with. This type of data creates an awareness of the potential range of other interests that a stakeholder may have because of these alliances and a potential range of other stakeholders that may need to be included in the project. Alliances may be categorised and typed. Alliance data may include impact status data indicating the relevance of the alliance to the project. Alliance data may also include context data identifying the nature of the

alliance and data regarding any mitigating factors that may create barriers to or assist delivery of the project. The table below sets out an example arrangement of data types for the second type of relationship data item in the context of the user example.

As shown at 610C, the third type of relationship data is values data identifying the nature of any values that the stakeholder may have that will influence the process. Values data may also be categorised and typed and may include impact status, context and mitigation data. The table below sets out an example arrangement of data types for the third type of relationship data item in the context of the user example.

As shown at 610D, the final type of relationship data is vision data identifying any vision of the stakeholder that is relevant to the project including context, status and mitigation data. Vision data identifies the customary and contemporary factors that the vision of the stakeholder is based on. The table below sets out an example arrangement of data types for the fourth type of relationship data item in the context of the user example.

As mentioned above, Equity data 620 indicates whether and when interaction will be required. As for Relationship data, Equity data may be divided into four types. As shown at 620A, the first type of Equity data is ownership data identifying any ownership rights of stakeholders that may influence the decision. Ownership rights may include legal, customary, use, and access rights and may relate to real, tangible, or intangible property. Ownership data may comprise type, context, status, impact, and mitigation data. The table below sets out an example arrangement of data types for the first type of equity data item in the context of the user example.

As shown at 620B, the second type of Equity data is influence data. Influence data is not independent data but is generated by analysing impact status (mitigation) data from other data types to identify important influences that may affect one or more aspects of any project. Influence data may include resolution data providing measures for addressing mitigation issues on one or more aspects of the interaction. Resolution strategies may be linked to Practice 630D deliverables as described below.

Access to influence data may be by use of a query submitted via the user interface that specifies a data type (stakeholder, alliance, value, vision, ownership, contribution, participation, structure, procedure, resource) and type of mitigation (structure, procedure, resource).

As shown at 620C, the third type of Equity data is contributions data identifying contributions from stakeholders that may be required to deliver the project. These are not confined to just dealing with mitigation issues. The table below sets out an example arrangement of data types for the third type of equity data item in the context of the user example.

As shown at 620D, the final type of Equity data is participation data identifying the nature of participation through which stakeholders may interact with the project.

The table below sets out an example arrangement of data types for participation data in the context of the user example.

As mentioned above, Management data 630 is directed to how interaction with a stakeholder is to be conducted. As with Relationship and Equity data, Management data may be divided into four types of data. Management data includes Structure data 630A indicates the basis on which the interaction with stakeholders will be conducted. Structure data records the level of stakeholder relationship management involved in a policy, programme or project in relation to the project phase. The table below sets out an example arrangement of data types for this first type of management data item in the context of the user example.

As shown at 630B Management data also includes Procedure data detailing the procedures for delivering a completed project. Procedure data describes how the stakeholder relationship dynamics will be managed during the project. The table below sets out an example arrangement of data types for this second type of management data item in the context of the user example.

As shown at 630C, Management data also includes resources data indicating the resources that are available or that must be available to the project. This data may therefore also include any resource deficits for the project. The table below sets out an example arrangement of data types for this third type of management data item in the context of the user example.

As shown at 630D, Management data also includes practice data indicating practices required after the project is complete and all decisions are taken. Practice data will represent the results of the interaction with stakeholders. It is envisaged that Practice data will be the collected resolution strategies from influence data 620B for all aspects of the project. The table below sets out an example arrangement of data types for this fourth type of management data item in the context of the road user example.

Interaction with data items such as those in the examples given above, may be achieved via any combination of standard or custom user interface elements or styles.

In addition to being designated as Relationship, Equity, and Management data, the data types described above may also be categorised as 1) "Influence" data including the Alliance, Values, Vision, Ownership, Contribution, and Participation data types, and 2) "Mitigation" data including the Structure, Procedure, and Resources data types.

Figure 7 illustrates these further interrelationships between the elements of the conceptual data model illustrated in Figure 6 and in the examples above. It can be seen at 710 in Figure 7 that influence data 620B comprises impact status data from the Stakeholder data 610A, Alliance data 610B, Values data 610C, Vision data 610D, Ownership data 620A, Contribution data 620C, and Participation data 620D.

The influence data (the impact status data from the other data types listed at 710) identifies where certain impacts from the other data types will need to be mitigated. Typically mitigation will be needed wherever an impact has been identified in the other listed data types as requiring assessment.

As shown at 720, mitigations of Assess impacts will be recorded via Structure data 630A, Procedure data 630B, and Resource data 630C. In practical terms this means that the recorded structures, procedures, and resources will be used to mitigate any Assess impacts identified in the influences on the project.

As shown at 730 in Figure 7, the structures, procedures, and resources used and recorded for the project result in Practices. Each practice will be categorised as a 1 ^st use practice if it has been used for the first time in the current project. Where the practice is found to be useful and is re-used in subsequent projects, the status of the practice will be updated to multi-use. If the practice has been found by repeated use to work for virtually all processes involving a particular stakeholder, the practice will be updated to the status of Best Practice. Typically the decision-maker will determine when a practice should be given the status of Best Practice.

The completion of the project instance may thus provide both a methodology and framework for organising and planning an interaction and also a clear record of how the process was planned and conducted after the fact. This enables comprehensive reporting and therefore transparency in the delivery process.

In preferred embodiments stakeholders other than the decision-maker may be able to access some or all of the data for the project instance, preferably via a web-interface. In some preferred embodiments stakeholders may also have edit privileges for some of the data for the project, however, the decision-maker may review all proposed changes to data records entered by the stakeholder and the project instance will only be updated permanently once the decision-maker has approved such updates.

Either during the process of the project instance being completed or alternatively upon completion of the project instance, the decision-maker may validate any or all data that has been contributed to the project instance. AU validated data that is relevant to

stakeholders may be fed back into the stakeholder meta-model stored in the database or metabase at 160. This step is shown at 340 in figure 3.

Figure 8 illustrates the flow of data between stakeholder meta-model 810 and the project instance 820. As shown at 830, stakeholder data is imported into the project instance when the project instance is created. Validated alterations or additions to stakeholder data that result from the completion of the project instance are fed back into the stakeholder meta-model as shown at 840. Thus the invention may enable decision- makers to more effectively manage stakeholder relationships because mitigation data in relation to each stakeholder will be updated or added to, every time a project is completed or new data is created using the invention.

Figure 9 illustrates in more detail some of the steps and data flow involved in the project lifecycle. The project management lifecycle can be described in stages and can be configured by the decision maker. The example below is configured for a consultation project.

The first stage is the creation of the project instance as shown at 910 by entering the name of the policy programme or project to be consulted on and adding any project partners or collaborators. The next stage is to import any data about known stakeholders that is available in one or more databases that the decision-maker has access to (also referred to as the Meta Store). Typically an instance will be created by an appointed project manager. This first stage is called Stakeholder Identification.

The appointed project manager will then review all information available to ensure the project has imported all the stakeholders required for the project. This second stage is called Pre-consultation.

The project manager completes the consultation process as required via the invention. This third stage is called Consultation and can be delivered by external contractors (project partners or collaborators).

It is during the consultation stage that new data about stakeholders is typically generated. As shown at 920 in Figure 9, influence data (impact status data) will not be classified when the process begins although the importation of stakeholder data may have already highlighted some influences that need to be classified for the particular project.

As shown at 930, to complete the process, the stakeholder influences will need to be classified as having a positive, neutral or Assess impact on the project. As shown at 940, any influences that are identified as needing Assessment will need to be mitigated by structures, procedures, and resources.

Mitigations are then classified as shown at 950. If a new structure, procedure, or resource is used, then the mitigation will be recorded as being a 1 ^st time mitigation. If a previously used mitigation is used then it will be recorded as "multi-use". At the discretion of an overall administrator or decision-maker, a mitigation that has been used successfully a number of times may be recorded as "best practice."

New stakeholder information generated for a particular project may be automatically imported into other current (or live) project instances with which the stakeholder is associated as shown at 960. This may reduce repetition of work where a new mitigation for a particular stakeholder can be used for more than one current project or where information relevant to more than one concurrent project has already been collected and recorded for one of the projects.

Finally, the project manager completes the consultation process via the invention and presents the completed project to the decision-maker. The decision-maker can then validate any new information that may have been generated as a result of the project as shown at 970 and update the stakeholder information stored in data memory 160, as shown at 980 in Figure 9 and 340 in Figure 3, which may thus be used for future projects as described above. This final stage is call post-consultation.

As mentioned above, in preferred embodiments stakeholder information generated from one project is automatically imported to other projects where the same stakeholder has an association.

The foregoing describes the invention including preferred forms thereof. Modifications and improvements as would be obvious to those skilled in the art are intended to be incorporated in the scope hereof, as defined in the following claims.