SYSTEM AND METHOD FOR LIMITING PROJECT MANAGEMENT RISK

Description

RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No. 17/724,245, entitled “System and Method for Limiting Project Management Risk”, filed Apr. 19, 2022, which is a continuation of U.S. patent application Ser. No. 12/586,240 entitled “System and Method for Limiting Project Management Risk”, filed Sep. 18, 2009, each of which is hereby incorporated by reference in its entirety.

COPYRIGHT AUTHORIZATION

A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

FIELD OF THE INVENTION

The present invention is related to computer software and more specifically to computer software for minimizing project risk.

BACKGROUND OF THE INVENTION

All projects have risks. The degree of risk is dependent on the project. For example, a project without a high degree of measurable benefits may have a risk that the expected benefits of the parties for whom the project is being implemented are not realized when the project is completed.

Documents may be used to assist a project team in minimizing certain risks. In the above example, a document that describes the expected benefits may be written and agreed to by the party or parties for whom the project is being implemented, or the document may contain steps that can be taken to make the expected benefits measurable.

Project teams may be expected to minimize risks of their projects, but are frequently left without any structured guidance for doing so. Existing solutions may just use a one-size-fits-all approach, where the project team members are expected to fill out every document on a list of documents, some of which may or may not address project risk. This solution is suboptimal in that the project team devotes time to filling out documents with only marginal risk reduction benefits for a specific project.

Some solutions, such as that addressed by U.S. Pat. No. 6,161,113 base the documents to be filled out on the type of project, for example, where all computer projects use the same set of documents. U.S. Pat. No. 7,058,660 allows the user to enter unspecified project risk, but doesn't utilize the risk information to assist the user in minimizing those risks.

What is needed is a system and method for assisting a project team in minimizing project risks by selecting appropriate documents.

SUMMARY OF INVENTION

A system and method receives categories of risks and one or more risks in each category. Scenarios are received for each risk that correspond to different levels of risk, such as high, medium or low. One or more documents, or their names, are received for each risk that can serve to help contain or minimize the risk for projects most nearly corresponding to the scenario for the highest level of such risk. Additionally, an indication is received as to whether the document or documents for the highest level of risk should be used for other levels of that risk, based on a cost benefit analysis. A baseline set of documents may be received or identified that can apply to all projects. The documents identified or received as described above are assigned to one of several project life cycles. Scores are assigned to each level of each risk, or a uniform scoring system, for example, assigning a score of 1, 3 or 9 to low, medium or high levels of every risk, may be used.

To use the system, for each risk category, the name of the risk category and for each risk corresponding to the risk category, the name of each risk, are displayed to a user, who may be an individual or a project team. The scenarios for each risk are displayed and the user is allowed to select one scenario for each risk that most closely approximates the project whose risks are being analyzed. The names of the documents that were selected to contain the risks as described above and that were assigned to the level of risk corresponding to the scenario selected are displayed, organized by the life cycle to which the documents correspond. The total project score is also displayed. The user or team may add additional documents or may indicate that they do not feel a document, displayed as described above, should be used and the reason why they feel that way. Any or all of the score and the list of documents, including any added as described above, as well as the explanations, are published to one or more managers of the team. The managers may compare the score with a threshold, and provide additional attention and require additional reports from, development teams with a score above the threshold.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block schematic diagram of a conventional computer system.

FIG. 2 consisting of FIGS. 2A and 2B, is a flowchart illustrating a method of containing project risk according to one embodiment of the present invention.

FIG. 3 is a block schematic diagram of a system for containing project risk according to one embodiment of the present invention.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

The present invention may be implemented as computer software on a conventional computer system. Referring now to FIG. 1, a conventional computer system 150 for practicing the present invention is shown. Processor 160 retrieves and executes software instructions stored in storage 162 such as memory, which may be Random Access Memory (RAM) and may control other components to perform the present invention. Storage 162 may be used to store program instructions or data or both. Storage 164, such as a computer disk drive or other nonvolatile storage, may provide storage of data or program instructions. In one embodiment, storage 164 provides longer term storage of instructions and data, with storage 162 providing storage for data or instructions that may only be required for a shorter time than that of storage 164. Input device 166 such as a computer keyboard or mouse or both allows user input to the system 150. Output 168, such as a display or printer, allows the system to provide information such as instructions, data or other information to the user of the system 150. Storage input device 170 such as a conventional floppy disk drive or CD-ROM drive accepts via input 172 computer program products 174 such as a conventional floppy disk or CD-ROM or other nonvolatile storage media that may be used to transport computer instructions or data to the system 150. Computer program product 174 has encoded thereon computer readable program code devices 176, such as magnetic charges in the case of a floppy disk or optical encodings in the case of a CD-ROM which are encoded as program instructions, data or both to configure the computer system 150 to operate as described below.

In one embodiment, each computer system 150 is a conventional SUN MICROSYSTEMS ULTRA workstation running the SOLARIS operating system commercially available from SUN MICROSYSTEMS, Inc. of Mountain View, California, a PENTIUM compatible personal computer system such as are available from DELL COMPUTER CORPORATION of Round Rock, Texas running a version of the WINDOWS operating system (such as 95, 98, Me, XP, NT or 2000) commercially available from MICROSOFT Corporation of Redmond Washington or a Macintosh computer system running the MACOS or OPENSTEP operating system commercially available from APPLE INCORPORATED of Cupertino, California and the NETSCAPE browser commercially available from MOZILLA FOUNDATION CORPORATION of Mountain View, California or INTERNET EXPLORER browser commercially available from MICROSOFT above, although other systems may be used.

Referring now to FIG. 2, consisting of FIG. 2A and FIG. 2B, a method of containing project risk is shown according to one embodiment of the present invention.

Setup of Risks, Documents and Scores.

The names of several categories of risks are received 210. In one embodiment, the several categories of risks are identified by someone familiar with project management, and the several categories include categories that correspond to all possible risks of a project. In one embodiment, the categories are those shown in Appendix A.

For each category of risk received in step 210, the names of individual risks are received 212. The individual risks are risks of things that could go wrong with the project or could indicate a potential problem with the project.

A first of the risks received in step 212 is selected 214. Two or more scenarios are received 216 for the selected risk. Each scenario corresponds to a different level of risk and describes an aspect of a project that has the level of risk to which the scenario corresponds. For example, if the risk is funding, and the risk level is high the scenario could be “The project has no identified source of funding”.

In one embodiment, there are three different scenarios for each risk, corresponding to high, medium and low levels of risk, and an optional fourth “not applicable” scenario that simply defaults to “N/A” for projects for which no explicit scenario is received. Other numbers of levels of risks may be used. Appendix A illustrates a set of risk categories, risks and scenarios, though other sets of these may be used.

One or more documents (or document names) are received 218 that can help contain the selected risk where the risk level is the highest of the levels described above. Containing the risk may include identifying the causes of the risk, identifying solutions to the risk, identifying ways to minimize the effects of the risk or the risk itself, or identifying people who can help minimize the risk. In one embodiment, a document may apply to more than one risk. In addition, a risk may have one or more documents received as part of step 218.

An indication is received 220 that identifies whether the benefits associated with filling out the document of step 218 outweigh the costs of filling that document out where the risk is a different level than high, such as medium. An indication is received 222 that identifies whether the benefits associated with filling out the document of step 218 outweigh the costs of filling that document out where the risk is a different level than high risk level or the risk level corresponding to step 220. For example, the different risk level may be “low”. In other embodiments, steps similar to steps 220 or 222 may be used for each risk level other than the N/A risk level. In one embodiment, the N/A risk level scenario is always considered to be one in which the benefits of completion of the document corresponding to the highest level of such risk are outweighed by the costs of completion. However, a user or team may disagree and add any such document into the list of documents for any given project, as described in more detail below.

If there are more risks 224, the next risk is selected 226 and the method continues at step 216 using the newly selected risk. If there are no more risks 224, the method continues at step 230.

At step 230, scores for each scenario of each risk are received. In one embodiment, the scores for each scenario corresponding to the same risk level are the same for every risk. That is, the scores for the scenarios corresponding to low levels of risk are ‘1’ for every risk, the scores for the scenarios corresponding to medium levels of risk are ‘3’ for every risk, and the scores for the scenarios corresponding to high levels of risk are ‘9’ for every risk. The score for a not applicable risk may be zero. In other embodiments, the scenarios from the same level of risk for different risks use different scores. The individual scores are set up to allow projects with more risks at the highest level to generate much higher scores than ones with fewer risks at the highest level.

Names of baseline documents, those that should be used by all or most projects, (or the documents themselves) are received 232. Life cycle phases are assigned 234 to each of the documents whose names (or the documents themselves) were received as described above. Such documents include the documents or document names received in steps 218 and 232. Life cycle phases are names of life cycles of projects, such as “inception” “elaboration”, “construction” and “transition”, though other numbers and names of life cycles may be used.

Preparation of Development Case for a Specific Project.

Once the steps of FIG. 2A have been performed as described above, users may use the method of FIG. 2B to put together what is referred to as a “development case” for a project. A development case may be part of or all of a project methodology or project management process. The development case includes a list of the documents the development team will fill out to limit the risks of the project as described above, and a score, as will now be described. A user is described herein, although the user may in fact be several people or all people from a development team.

A first risk category is selected 250 from those received as described above, and the name of the category is displayed 252. In one embodiment, a risk score is initialized as zero as part of step 250, and will be added to as described in more detail below. In one embodiment, multiple category risk scores are used as described below, and a risk score for each category is also initialized to zero as part of step 250.

A list of documents is also initialized to contain the baseline documents as part of step 250. A first risk from the selected category is selected 254 from those received as described above, and the name of the risk is displayed 256, along with all of the scenarios received for the selected risk as described above.

The user selects one of the scenarios most closely matching the current state of the project for which the development case is being generated, and the user's selection is received and stored 258 associated with the selected risk. The score corresponding to the risk level of the scenario (and the risk) is added to the risk score, and the document or documents corresponding to the selected scenario, if any are added to a list of documents as part of step 258. In one embodiment, the score corresponding to the risk level of the selected scenario is also added to the score corresponding to the risk category as part of step 258. The document assigned to the highest risk level of a risk corresponds to the selected scenario if the selected scenario corresponds to the highest risk level of that risk, and corresponds to any other risk levels selected for the same risk if the benefit of filling out the document was indicated as being worth the cost of completion of such document at that risk level as described above.

If there are more risks in the selected category 260, the next risk in the selected category is selected 262 and the method continues at step 256 using the newly selected risk. If there are no more risks in the selected category 260, if there are more categories 264, the next category is selected 266, and the method continues at step 252 using the newly selected category. If there are no more categories 264, the method continues at step 268.

At step 268, the list of documents, assigned based on the scenarios chosen as well as from the set of baseline documents, is provided, for example, by displaying it or printing it. In one embodiment, the documents are organized by the life cycle phase to which they correspond, for example, listing the names of the phases in the order in which each phase typically occurs, and listing the documents from the baseline and from those corresponding to the user-selected scenarios that correspond to each phase under the name of the phase.

The score or scores are also provided, and the score or scores and document list are published as the development case 280. Publication may include distribution to interested and potentially interested parties. In one embodiment, publication of the development case is performed after step 282 instead of performing it before step 282. Steps 282 and 286 follow step 280.

At step 282, the user or team reviews the document list and the documents, and identifies those one or more documents that are listed on the development case that they feel they should not complete. The user or team indicates which documents they will not complete, and why they feel they should not complete them. In addition, the user or team may supply the names (or the documents themselves) of additional documents the user or team feels would be beneficial for containing one or more risks of the project or for other purposes. All such information is received as part of step 282 and stored as part of the development case.

The user or team fills out 284 the documents corresponding to the current life cycle phase that were not indicated as inapplicable as described above. Other documents not corresponding to the current life cycle phase may also be filled out, such as some or all of those corresponding to the upcoming life cycle phase.

The team submits 286 the score to a management team. In one embodiment, the list of documents, or the filled-out documents, are also submitted to the management team, or one or more of the filled-out documents may be submitted in response to a request from the management team, and the management team stores the score, associated with an identifier of the team. As part of step 286, the management team compares the score submitted with a threshold. The management team may include parties for whom the team members work, management of organizations who will benefit from the project, or other management of the organization or organizations that include any such person or group. For example, the management team may include a project governance or project oversight organization in a company.

If the score is above the threshold 288, the management team meets with the team more frequently, requires extra reporting (and optionally, the documents) and provides greater attention to the project 290 than if the score is below the threshold 288, 292. The method continues at step 294. There may be individual thresholds for each risk category and step 288 may also check for category scores above a threshold. If any category score is above a threshold or a minimum number of category scores are above their respective thresholds (each of which may be the same or different from one another and may be a function of the number of risks in the category), the “yes” branch of step 288 is taken.

At step 294, if the project transitions to a new life cycle phase, or there has been another significant change to the project for which a new assessment of risks and/or containment of such risks would be beneficial, the method continues at step 250, and otherwise 294, the method continues at step 288.

Any of the information flows described herein may occur over a computer network. Thus, the scenarios may be displayed over a network and selected via the network, or the development case may be provided to the user or team via a network. The applied purpose of the actions is to assist users in limiting (i.e. containing) one or more risks of a project.

System.

Referring now to FIG. 3, a system 300 for containing the risk of a project is shown according to one embodiment of the present invention. In one embodiment, containing risk means identifying a level of risk and identifying steps that can be used to reduce the level of risk for risks that are at a high or medium level, or can be used to reduce the potential negative effects of that risk. The risk of a project is made of the component risks identified as described herein.

Communication interface 308 is a conventional communication interface that includes a conventional Ethernet interface running TCP/IP, Ethernet and other conventional communications protocols. All communication into or out of system 300 is made via input/output 306 of communication interface 308, which is coupled to a network 302, such as a local area network, the Internet, or both. Any other computer or other device 304 (of which there may be several) coupled to the Internet 302 may be used to provide or receive information as described herein.

System Setup.

An administrator of the system may use a user computer system 304 to set up the risk and document information as described herein. Risk category receiver 310 provides a user interface to the administrator that allows the administrator to enter the names of risk categories as described above, which risk category receiver 310 stores into risk information storage 326. After each risk category name has been so stored, risk category receiver 310 signals risk name receiver 312 with the name of the risk category just entered.

When it receives each risk category name, risk name receiver 312 provides a user interface that allows the administrator to enter the names of risks as described above, which risk name receiver 312 receives and stores into risk information storage 326 associated with the risk category name received that is stored therein. After each risk name has been so stored, risk name receiver 312 signals scenario receiver 314 with the name of the category and risk.

When it receives each risk category name and risk name, scenario receiver 314 prompts the administrator to enter two or more scenarios, each corresponding to a different level of risk, for example corresponding to a high, medium or low level of risk. In one embodiment, scenario receiver 314 also allows the administrator to indicate whether a “not applicable” level of risk can apply to the risk name it receives. Scenario receiver 314 stores the scenarios and the risk level to which each scenario corresponds into risk information storage 326, as well as the indication that the “not applicable” risk level can apply to the risk, each associated with the risk name it receives that is associated with the category name it receives.

Scenario receiver 314 then signals document name receiver 316 with the name of the risk and category it received as described above, and scenario receiver 314 receives the name of the document or the document for one or more documents that can be used to limit the risk received by scenario receiver 314 at the highest level, and stores the document or name into risk information storage 326, associated with the risk name and risk category. Document name receiver 314 signals other risk level identifier 318 with the name of the risk and category.

When so signaled, other risk level identifier 318 provides a user interface that allows the administrator to indicate the scenarios or levels of risk for which the benefits of completing the document received by document name receiver for the risk and category names exceed the cost of completing the document, and risk level identifier 318 stores in risk information storage 326 identifiers of such scenarios or levels, associated with the risk level name and risk name it received. Other risk level identifier 318 then provides the risk name and category name to risk name receiver 312, which allows the administrator to enter an additional risk name as described herein, or to indicate that no additional risks for the category are being entered, at which point risk name receiver 312 signals risk category receiver 310.

When signaled, risk category receiver 310 allows the administrator to enter information for an additional risk category, which is processed as described above, or to indicate that the system description is complete. If the administrator indicates that the description is complete, risk category receiver 310 signals score receiver 320.

When signaled, score receiver 320 receives the scores for each level of risk for each risk or for all risks, stores such scores into risk information storage 326 and signals baseline document receiver 322.

When so signaled, baseline document receiver 322 receives the names of the baseline documents as described above, and optionally the documents themselves, and stores the names, and optionally the documents, into risk information storage 326 as the baseline documents. Baseline document receiver 322 signals life cycle receiver 324.

When signaled, life cycle receiver 324 retrieves the names of the documents in risk information storage 326 and provides the user with a user interface that allows the system administrator to identify a life cycle phase name for each of the document names, and life cycle receiver 324 receives such information and stores the life cycle name associated with each document name in risk information storage 326. Life cycle receiver 324 also receives order information for each of the life cycle phase names, that identifies the order in which the phases occur in a project. Life cycle receiver 324 stores such information into risk information storage 326.

Production of a Development Case for a Project.

At any time, a user or project team may use their own user computer system 304 to request a user interface from project information receiver 350 (and to provide and receive the information described below) via network 302. When it receives such a request, project information receiver 350 provides a user interface to receive a project name, receives such project name and stores the project name into project information storage 356. Project information receiver 350 uses the information in risk information storage 326 to provide one or more user interfaces that perform the steps 250-266 except for assignment of the documents and addition to the score or scores described with respect to step 258. Project information receiver receives the user's or team's scenario selection for each risk and stores them associated with each risk name and the project name into project information storage 356. Project information receiver 350 provides the project name to document assignor 352 and to score assignor 354.

Document assignor 352 uses the information in risk information storage 326 and the information in project information storage 356 for the project whose name it receives to assign documents to a list of documents for the project as described above, and stores the names of the documents assigned for the project into project information storage 356 associated with the project name. When it has finished assigning the documents as described above, document assignor 352 signals document/adjustment manager 358 with the name of the project.

When it receives the project name, score assignor 354 uses the scenario selections in project information storage 356 and the scores in risk information storage 326 to assign a score to the project (and optionally to each category) as described above. Score assignor 354 stores the score into project information storage 356 associated with the project name it received. When it has completed identifying and storing the project score, score assignor 354 signals score threshold manager 360 with the score and the name of the project.

When it receives the score and the name of the project, score threshold manager 360 stores in project information storage 356 an indication as to whether the score exceeds a threshold associated with the project name, and optionally whether any of the category scores exceed their respective thresholds and whether a threshold number (e.g. one or more) of the category scores have been exceeded. In one embodiment, more than one threshold for the total score and for each category score may be used, and in such embodiment, score threshold manager 360, identifies the lowest threshold exceeded by the score.

Document/adjustment manager 358 retrieves from project information storage 356 the list of documents associated with the project name it receives, and displays the list of documents to the user or team. Document/adjustment manager 358 provides a user interface that allows the user to indicate which of the documents on the list they feel they should not complete, and the reasons for not completing them. The user interface provided by document/adjustment manager 358 also allows the user to add the names of documents to the list, as well as the documents themselves, in one embodiment. Document/adjustment manager 358 receives and stores in project information storage 356 such information, associated with the project name it received. When document/adjustment manager 358 has completed storing any such information (or receives an indication from the user that no such update is required because the list of documents generated as described above will be used without modification) document/adjustment manager 358 publishes the optionally-altered list of documents (including indications of any document that will not be completed and the reason for non completion), the score, and an indication as to whether the score exceeds the threshold, collectively referred to as the development case to management, team members and others, the identifiers (such as e-mail addresses) of which are received by document/adjustment manager 358 via a user interface it provides to the user or the team.

The development case score or scores and the indication as to whether it exceeds the threshold are used by the management team as described above. In one embodiment, if the score exceeds the threshold or the threshold number of category scores exceed their respective thresholds, score threshold manager 360 arranges one or more meetings that would not have been arranged if the score had not exceeded the threshold, for example, via a central meeting server (not shown) coupled to the network and sends notices of the one or more meetings via e-mail, using the network.

As noted above, the user or team may use the system 300 to provide or update the scenarios corresponding to the project at different points in time corresponding to different life cycle phases, and a new list of documents and score or scores are assigned to each life cycle phase as described above. The scores and document assignments may be different for each life cycle phase.

Thus, documents names for high risk levels are provided for each risk. An indication is also received for each risk and the risk level, except the highest risk level, for which the document should also be used. The scenarios each correspond to a level for a risk, and apply to projects generally. Some risks will have no indications, other risks will have indications for some risk levels other than the highest, and still other risks will have indications for all 5 levels except the “Not Applicable” level. The system and method matches the identified scenario for a project to the document or documents identified, if any, for the level of that risk to which the identified scenario corresponds.

As used herein, a “name” is an “identifier” and they are used interchangeably.

APPENDIX A
Categories, Risks and Scenarios

Risk Category	Risk	HIGH	MEDIUM	LOW	N/A
Sponsorship
1	# of enterprises	Multiple	“More than one	“Single
	with shared	enterprises with	enterprise, but	enterprise, self-
	accountability	critical interest	one group taking	contained”
			accountability/o
2	Clarity	Accountable	Role is in	AE actively
	regarding	Executive not	question due to	engaged
	Accountable	assigned	organizational
	Executive		or other changes
3	Accountable	AE not regularly	AE	AE available
	Executive	available or	inconsistently	and acts as
	engagement	responsive to	available but	advocate for
		critical project	has assigned	project
		needs	delegate
4	Key stakeholder	Stakeholder s	Stakeholder s	All stakeholder s
	engagement	not identified or	identified but	identified and
		not engaged	participation is	actively engaged
			inconsistent
Benefits
5	Clarity of project	End state	End state	End state
	vision/objectives	objective not	objective	objective clear
		well defined	reasonably	and well defined
			defined
6	Degree to which	Majority are soft	Some but not all	Clear and
	benefits are	benefits and	critical benefits	measurable
	measurable	not measurable	can be reliably	benefits
			quantified	expressed in
				terms of direct
				impact to
				revenue or cost
7	Sensitivity of	“Benefits	“Benefits	Benefits
	benefits	realization is	realization is	realization is not
	realization	sensitive to	sensitive to	sensitive to
		multiple volatile	external factors,	external factors
		external factors,	but those
		such as	factors tend to
		competitor	be fairly
		activity or	predictable!!
8	Incremental	Required FOEX	Required FOEX	FOEX is	This project will
	ongoing	is not yet	is understood	planned and	not result in any
	business or	understood	but not yet	approved	need for ongoing
	technical		planned and		support.
	support needed		approved
	as result of
Requirements
9	Consensus	Key	Key	Feature level
	amongst	stakeholders	stakeholders	requirements
	multiple	have conflicting	have conflicting	have been
	stakeholders	requirements	requirements	baselined and
		AND priorities	OR priorities	prioritized by all
				key stakeholders
10	Clarity of	Complex	Complex	Requirements
	documented	requirements	requirements	are explicit
	requirements	with many	but seem to be	enough to
		outstanding	well understood	create target
		questions	by design team	architecture
11	AFTER	Requirements	“Requirements	Requirements	Project has not
	INCEPTION:	are changing	are changing,	have entered	yet left Inception
	Stability of	frequently	but infrequently	change control
	documented		and changes are
	requirements		minor”
12	AFTER	High Risk	“High Risk	Core project	Project has
	INCEPTION:	requirements	requirements	team is highly	not yet left
	Completeness	are not yet	have been	confident that	Inception
	of documented	defined	defined, but	requirements
	requirements		supplementary	are complete
			requirements	and comprehensive
			are outstanding!!
Timeline
13	Date	“Top Down”	“Project has	Project dates
	Drivers	project dates	date drivers, but	driven by
		preset and	they are flexible	tasks and
		immovable”	and/or	resources
			achievable”
14	Project Duration	Duration >18	Duration	Duration <9
		months	between 9-18	months
15	AFTER	Milestones are	“Milestones are	“Milestones are	Project has not
	INCEPTION:	extremely broad	broad but team	discrete, well	yet left Inception
	Scope of project	and require	has realistic	defined and
	milestones	significant work	plan to achieve	frequent”
		before progress	more frequent,
		can be accurately	well defined
		measured	milestones”
Cost
16	Project Size	Cost >$3M	Cost between	Cost <$1M
			$1M-$3M
17	AFTER	Project team is	Project team is	Project team is	Project has not
	INCEPTION:	unable to commit	confident in	confident in	yet left Inception
	Accuracy of	to estimate within	estimate within	estimate within
	estimation	50% variance	50% variance	10% variance
18	Funding stability	Funding is less	Funding is	Funding
		than required	marginally	includes risk
		OR there is high	adequate and	contingency and
		probability of	expected to	is highly certain
		losing funds to	remain relatively	to remain
		another priority	stable	available
		effort
Exposure
19	Brand Risk	“High external	“External	External
		profile due to	attention with	attention
		marketing	little brand risk,	unlikely
		efforts, media	but potentially
		coverage or	significant client
		competitor	impact.”
		activities”
20	Regulatory	High external	Moderate	Regulatory	There are no
	requirements	profile due to	external profile	standards	regulatory
		regulatory	due to regulatory	suggested but	standards or
		requirements	requirements	not required	requirements
					impacting this
21	Access	Project will	Project will	No access	This project
	mechanisms to	modify or create	modify or create	mechanisms to	does not involve
	Customer	an unencrypted	an encrypted	customer	data of any kind.
	Data/Fraud	access mechanism	access mechanism	information will
	Control	to customer	to customer	be created or
		information	information.	modified.
			No data
			transmission or
			ISS has approved
			an encrypted
			transmission.
Resources
22	Availability of	SMEs are	“SME	SMEs are
	Subject Matter	committed	commitment	committed to
	Experts (SMEs)	elsewhere	varies, but most	the project and
		and/or	current	actively involved
		overbooked	availability
			requirements
			are being met”
23	End user	User	Knowledgeable	“Highly
	involvement	availability	users available	knowledgeable
		inconsistent	as consultants	users fully
			only	committed to
				project, with
				backfill if
				required”
24	Availability of	“Legal,	“Legal,	“Legal,	“This project
	specialized	compliance or	compliance or	compliance or	does not require
	resources	other highly	other highly	other highly	any legal,
		specialized	specialized	specialized	compliance or
		resources are	resources are	resources are	other highly
		not available or	aware of but not	fully committed	specialized
		have not been	committed to	to project”	resources.”
		consulted”	project”
25	Team project	Core project	Core project	Core project team
	experience	team is relatively	team is experienced	has significant
		new to managing	but project	project experience
		projects of this	complexity may	relative to
		complexity	be a stretch for	project complexity
			them
26	Project Team	Many resources	At least one	All key roles are
	Staffing	assigned to key	resource	filled by resources
	(Expertise and	roles do not meet	assigned to a	with adequate
	Availability)	the project's	key role does	availability and
		requirements for	not meet the	whose level of
		expertise in the	project's	expertise in the
		role OR Many	requirements for	role meets the
		key roles are	expertise in the	project's
		unfilled or filled	role OR at least	requirements
		by resources	one key role is
		with low/	unfilled or filled
		inconsistent	by a resource
		availability	with low/
			inconsistent
			availability
27	Conflicting	Critical	“Contention	Key resources
	priorities	resources shared	exists, however	are dedicated
		with other high	project is	with little risk of
		priority efforts	expected to be	contention
			priority”
28	Skill backup for	Project has a	Project has	Project has little
	role turnover	high dependency	moderate dependency	dependency on
		on limited	on limited	limited
		resources with	resources with	resources with
		critical/	critical/	critical/
		specialized skill	specialized skill	specialized skill
		or expertise and	or expertise and	or expertise OR
		no resource	no resource	a comprehensive
		contingency plan	contingency plan	resource contingency
3rd Party
29	Vendor history	Vendor is less	“Vendor has	“Vendor is	This project will
		than 2 years old	history with	industry leader	not utilize a
		OR has no	Schwab, but not	and has ongoing,	vendor of any
		relevant	in project area	successful	type.
		experience at	OR there are	history with
		Schwab OR	potential issues	Schwab, with
		there are	with the contract/	interaction
		outstanding	relationship”	models firmly
		issues with		established!!
		vendor that
		require resolution
30	Due Diligence	“Only one	Formal selection	An extensive	This project will
	process	vendor was an	amongst multiple	selection	not utilize a
		option, and	vendors was	process was	vendor of any
		vendor due	bypassed due	conducted and	type.
		diligence was	to prior track	appropriate
		not performed”	record	screening
				completed.
31	Offshore vendor	“Offshore team,	Offshore team	“Offshore team,	This project will
		including	is inexperienced	including the	not utilize any
		development	with Schwab but	development lead,	offshore resources.
		lead, is	the project	is experienced
		inexperienced	deliverable is	with Schwab
		with Schwab	standard OR	AND the project
		and the project	the project	deliverable is
		deliverable s are	deliverable is	standard technology”
		complex and	complex/
		potentially	ambiguous but
		ambiguous.”	the offshore
			team is
			experienced
			with Schwab
User Experience
32	Impact on client	Project will have	Project will have	Project will have
		significant	minor impact	no impact on
		impact (positive	(positive or	client interaction
		or negative) on	negative) on	with Schwab
		client interaction	client interaction
		with Schwab	with Schwab
33	AFTER	Users are	Users are	Users fully	Project has not
	ELABORATION:	resistant	ambivalent	prepared for	yet left
	User readiness for			and supportive	Elaboration
	adoption			of change
34	New functional! ty	Requires new	Requires	No new
	or process creates	business rules	modified	business rules
	impact on internal	and policies	business rules	or policies
	user		and policies
Interdependencies
35	Number of	“Multiple	“Multiple	Project is	This project
	technology groups	technology	technology	ontained within	does not involve
	involved	providers are	providers	cone technology	a technical
		involved, with	involved, with	provider	solution.
		shared	one group
		accountability	taking clear
		for project	accountability”
		deliverable s”
36	Dependencies on	Predecessor	Predecessor	Predecessor	This project has
	other projects	project(s) unable	project(s) on	project(s) are on	no dependencies
		to commit to	track but no	track to deliver	on any other
		required	slack is available	with plenty of	project
				slack
37	Dependencies on	Releases are	Release	“Release	This project has
	other release	infrequent or	inclusion is	schedules are	no dependencies
	schedules	inflexible OR	planned but not	frequent and/or	on any other
		inclusion is	confirmed	flexible,	release
		problematic		inclusion is	schedules.
				planned”
38	Dependencies on	Critical	Critical	Critical	This project has
	external factors	decisions such	decisions such	decisions such	no dependencies
		as regulatory	as regulatory	as regulatory	any external
		decisions and/or	decisions and/or	decisions and/or	factors.
		deadlines are	deadlines	deadlines are
		highly uncertain	are shifting	clear and
				confirmed
Methodology
39	Team	Team is	Team is trained	All team
	experience with	unfamiliar with	but inexperienced	members have
	standard	standard and	with standard	training and
	methodology	processes	methodology	experience with
				standard processes
40	Support for	Circumstances	Standard tools	Standard tools
	standard	such as	and processes	and processes
	methodology	aggressive	are applied to	are being
	and tools	timeline	some but not all	applied in all
		preclude use of	parts of project	parts of project
		standard tools	OR were applied
		and processes	midstream
41	Level of	Standard	Some but not all	All standard
	governance	governance	standard	governance
	adherence	processes are	governance	processes are
		not being	processes are	being adhered to
		adhered to	being adhered to
Implementation
42	Unproven	No track record	Solution has	Proven track	This project
	technology/	of implementing	been implemented	record of	does not involve
	Experience with	this system in	elsewhere with	implementing	a technical
	delivering within	the industry with	moderately	system at	solution.
	Schwab business	comparable	comparable	Schwab or in
	conditions	volumes or	volumes and	industry with
		configuration	configuration	comparable
				volumes and
				configuration
43	AFTER	High risk	Enough high	Deployment	Project has not
	INCEPTION:	functionality	risk functionality	plan implements	left Inception
	Staged	deployed last	deployed early	high risk
	Deployment		to extrapolate	functionality
			viability of entire	early
			solution
44	Complexity of	Significant	Moderate	Little or no	This project
	integration with	reliance or	reliance on	reliance or	does not involve
	existing	integration with	existing	integration with	a technical
Technical Design
45	AFTER	Vendor product	Vendor product	Vendor product	This project will
	INCEPTION:	will require	will require	will meet	not utilize a
	Degree of	significant	moderate	requirements	vendor product.
	product	customization	customization	with out of the
	customization			box functionality
46	Team familiarity	Solution is new	Solution is new	Core technical	This project
	with technology	to the core	to the core	team has	does not involve
		technical team	technical team	experience with	a technical
		and resources	but resources	implementing	solution.
		experienced with	experienced with	the solution
		implementing it	implementing it
		at Schwab are	at Schwab are
		NOT available	available for
47	Conformance	Solution	Solution	Solution	This project
	to Schwab	requires	presents minor	conforms to	does not involve
	Technology	significant	exceptions to	Schwab's	a technical
	standards	negotiation with	Schwab's	technology	solution.
		Schwab's	technology	standards
		technology	standards
Technical
Environment
48	Team	Team is	“Team is	Team is	This project
	experience with	inexperienced	inexperienced	experienced	does not involve
	development	with required	with required	with development	a technical
	tools	tools and	tools, but well	tools required	solution.
		Schwab has no	supported at
			”
49	Experience	Ability to	Testing	Testing	This project
	testing	perform full	resources have	resources have	does not
	technology	testing is	experience	experience	involve a
		uncertain OR	testing some	testing this	technical
		team is	but not all of the	solution in the	solution.
		inexperienced at	solution in the	Schwab
		testing solution	Schwab	environment
			environment
50	Stability of	Test OR	Test and	Test and	This project
	environment	Development	development	development	does not
		environment	environment	environment	involve a
		is unstable OR	s are mainly	s are stable	technical
		significant	stable but some	and reserved to	solution.
		contention	contention	project
		with other	with other
		testing	effort exists
		efforts exists.
indicates data missing or illegible when filed