Technical Risk Assessment

Portfolio Development
Technical Risk Assessment
Standard Dedicated uCMDB (SD-uCMDB) Instance

Version 1.0 Date 10/31/2009
Index
DOCUMENT INFORMATION .................................................................................................. 3 PURPOSE ...................................................................................................................................... 3 PREREQUISITES ............................................................................................................................ 3 DURATION ................................................................................................................................... 3 INSTRUCTIONS ............................................................................................................................. 3 TECHNICAL RISK ASSESSMENT TEMPLATE CHANGE HISTORY .................................................... 4 PROJECT <INITIATIVE NAME>CHANGE HISTORY ......................................................................... 5 ORGANIZATIONAL ASSIGNMENTS ................................................................................................ 6 1. SUMMARY ............................................................................................................................... 7 2. RISK ANALYSIS.................................................................................................................... 10 INSTRUCTIONS ........................................................................................................................... 10 RISK ASSESSMENT - GENERAL ................................................................................................... 11 RISK ASSESSMENT PROCESS ................................................................................................... 15 RISK ASSESSMENT - TECHNICAL ................................................................................................ 28 3. ADDITIONAL RISKS ........................................................................................................... 35 INSTRUCTIONS ........................................................................................................................... 35 RISK DESCRIPTION AND ASSESSMENTS ...................................................................................... 35
V2.2 07-31-06
HP Enterprise Services Internal
Page 2 of 37
Document Information
Purpose
The purpose for the Technical Risk Assessment is twofold: To outline any high-level technical or process barriers that exist in the proposal, and to rank them according to their severity To provide a preliminary analysis of the impact of these barriers to the proposal and to update the analysis over time as more information is known about the proposal
Prerequisites
The following documents must be produced by upstream activities before a Technical Risk Assessment can be completed: Idea Submission Form: This will help give information describing the initiative and any high-level available documents. If clarification is needed, a request will be made back to the Service Line Manager for further details. Business Requirements to the extent known: Depending on the nature of the Offering and the current CtP phase, these could be the High-level Requirements and/or the Detailed Business Requirements. If clarification is needed, a request will be made back to the Portfolio Development Program Manager for further details. Updates to the EDS Enterprise Architecture: The Core Architect should notify the Enterprise Architecture Program Office of any needed updates to the EDS Enterprise Architecture based on information known during Manage and Plan. Product Release Plan: This should provide the architect with details sufficient to understand the proposal including a tentative description of features. After receiving the Product Release Plan, if additional clarification is necessary, a request will be made back to the Portfolio Development Program Manager for further details.
Duration
After receiving a request for a Technical Risk Assessment, the assigned architect will identify the appropriate group(s) requiring involvement. Provided the pre requisites have been completed fully, the completed assessment must be sent back to Portfolio Management within five business days.
Instructions
The Technical Risk Assessment has three major sections: 1. Summary: This section contains tables that can be used to summarize the results of the Technical Risk Assessment and assist the Core Architect in determining an overall rating for the proposal. 2. Risk Analysis: This section contains a number of predetermined risk analysis areas that must be examined to outline the high-level risks associated with the proposal. Each area has three levels of risk from which to choose. Report the current situation by selecting the appropriate risk assessment. Each organization that participates will determine their rating for each question.
V2.2 07-31-06 HP Enterprise Services Internal Page 3 of 37
Technical Risk Assessment Comments shall be provided for each risk area ranked Medium or High. 3. Additional Risks: In addition to the risks outlined in the Risk Analysis section, there may be additional risks that need to be analyzed in order to assess the technical feasibility of this new idea. These additional risks need to be added to this section. Describe the risk, assign it a ranking, and add sufficient notes to describe the implications of what it means to EDS. In some circumstances it may be desirable to produce a single Technical Risk Assessment which spans multiple targeted releases. The documentation approach may vary depending on the architectural coupling of the releases. The Core Architect should work with the Portfolio Development Program Manager to determine the best documentation approach for a particular offering. If using this template to span multiple targeted releases, repeat Sections 1 through 3 as needed.
Technical Risk Assessment Template Change History

The following Change History log contains a record of changes made to this template:
Published / Revised Date 06 Jan 2005 Version # 1.01 Author L Fernandez Change History Removed macros & improved formatting Provided references for responding to questions Removed question 11 due to overlap w/ overall rating Removed references to Technology Development Added references to Delivery Systems Architecture Added a Risk Rating Detail table in the Summary section. Clarified the language in the Prerequisites section. Updated references to the DSA CtO Procedures Added EDS Technology Policy as a reference for Risk 10 (EDS Experience). Used name DSA Support for CtO Enterprise
13 Apr 2005 30 June 2005
1.02 1.03
N. Cresswell E. Nadhan / H. Steinman N. Cresswell H. Steinman
27 July 2005 10 Nov 2005
1.04 1.05
Process Annex B Architecture Guidance Assessment for Validate, Plan and Design for
E. Nadhan / H. Steinman 09 March 2006 1.06 P. Singh 01 Sept 2006 03 Jan 2007 24 Jan 2007 21 Mar 2007 19 Feb 2008 03 Apr 2008 28 Jul 2008 1.08 1.09 1.10 1.11 1.12 1.13 1.14 H. Steinman H. Steinman H. Steinman H. Steinman M. Hunter H. Steinman H. Steinman E. Perry H. Steinman consistency throughout document. Added table to track evolution of risk ratings over time as progress is made from one phase to the next. Added questions to assess process risk. Added Not Applicable and Insufficient Requirements check boxes. Renamed from Preliminary Technical Assessment to Technical Risk Assessment Added instructions for handling multiple targeted releases in one document Changed Business Case/Plan references to Product Release Plan throughout document. Fixed typo in risk evolution table. Updated to reference EDS Enterprise Architecture instead of DSA. Updated to reference new CtP role names and requirements management activities. Corrected typo in Process Question 4. Made several improvements in grammar and punctuation. No content changes. Added question for change in usage, deployment, or
21 June 2006
1.07
H. Steinman
V2.2 07-31-06
Page 4 of 37

Application Services Engineering & Portfolio Applications Engineering support
Project <Initiative Name>Change History

The following Change History log contains a record of changes made to this document:
Published / Revised Date 11/3/2009 Version # 1.0 Author Doug Fisher Change History Changed all reference from Standard Dedicated to Standard Private with the acronym SD-uCMDB.
V2.2 07-31-06
Page 5 of 37
Organizational Assignments
After receiving a request for a Technical Risk Assessment, the assigned architect will review it to determine which organizations will be involved with the initiative. Those individuals who will play a role in developing this initiative will also be responsible for giving input to this report. Below, please identify the organizations that the architect anticipates will be required in developing this initiative, and document who from that organization (SME) will provide input to this report.
Capability / Organization Group(s) Global Process Owner Service Owner Capability Owner Engineering Leader
Subject Matter Expert Zoe Lambert Roland Fadrany Alexis Mermet-Grandfille Craig Parker
V2.2 07-31-06
Page 6 of 37
1. Summary
After completing this report, the architect will provide an overall rating for this proposal. Use the Risk Rating Detail table in this section to summarize the results of the risk analysis and to assist you in determining an overall rating. The rating will use the following criteria:
Criteria
Completely feasible - no difficulties to overcome Mostly feasible - only slight difficulties to overcome Possible - several difficulties to overcome Difficult - many difficulties to overcome Impossible to overcome difficulties
Rating
5 4 3 2 1
Rating Type General Rating for this proposal Process rating for this proposal Technical rating for this proposal Overall rating for this proposal
Rating (1-5) 4
Notes
V2.2 07-31-06
Page 7 of 37

This table may be used to summarize the results of the Risk Analysis below. Double-click anywhere on the table to activate the Excel worksheet. Delete rows that are not needed.
Risk Rating Detail
Risk #
1 2 3 4
Risk Description
General Availability of sufficient offering details Time-to-market reasonability EDS Experience Learning Curve Sub Total Sub Percentages
Low
x
Medium
High
N/A
Insuff. Req.
x x x 3 75.00% x x x x x x x x x x x 8 80.00% x x x x x x x 5 71.43% 2 28.57% 0 0.00% x x 2 100.00% 2 8.70% 2 20.00% 0 0.00% 1 25.00% 0 0.00%
1 2 3 4 5 6 7 8 9 10 11
Process Process Conformance Process Flow Definition Process Components Process Reusability Process Scalability EDS Industry Frameworks Technology Policy Tools Compliance Tools Independence Process Integration Effort Process Automation Process Measurability Sub Total Sub Percentages
1 2 3 4 5 6 7
Technology Technology maturity Technology provider stability Integration Complexity Technology availability Standards current state # of technology categories Change in usage, deployment, or support Sub Total Sub Percentages
1 2
Additonal Risks Leveraged Component Dependency RADM Component Dependency Sub Total Sub Percentages Total Total Percentages
0 0.00% 16 69.57%
0 0.00% 5 21.74%
V2.2 07-31-06
Page 8 of 37

This table may be used to track the evolution of the risk ratings from phase to phase. This can be useful to highlight how risks change over time as progress is made from one phase to the next. Manage Phase Rating (Low, Medium, High) General Low Plan Phase Rating (Low, Medium, High) Design Phase Rating (Low, Medium, High)
Risk #
1. 2. 3. 4. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 1. 2. 3. 4. 5. 6. 7.
Risk Description
Availability of sufficient offering details Time-to-market reasonability EDS experience Learning Curve
Low Medium Low Low Low Low Low Low Low N/A Low Low Medium Low Medium Low Low Low Low Low Medium Medium
1. 2.
Process Process Conformance Process Flow Definition Process Components Process Reusability Process Scalability EDS Industry Frameworks Technology Policy Tools Compliance Tools Independence Process Integration Effort Process Automation Process Measurability Technology Technology Maturity Technology Provider Stability Integration Complexity Technology availability Standards current state # of technology categories Change in usage, deployment, or support Additional Risks Leveraged Component Dependency RADM Component Dependency
High High
V2.2 07-31-06
Page 9 of 37
2. Risk Analysis
Instructions
The risks listed below are recognized as general risks that are dealt with frequently when developing or enhancing new capabilities and/or offerings. For each risk area, provide a rating (High, Medium, Low) and include notes explaining the reasoning for the rating. The risks are classified as General, Process-Centric and Technology oriented. The ProcessCentric risks address Business, Development and Delivery processes. Not all risks are applicable to every offering. Moreover, at times there may not be sufficient requirements available to assess the risk. Therefore a risk can be marked as Not Applicable or having Insufficient Requirements. The rating scale is meant to be rather broad. Use your best educated judgment to determine how to rate each risk. The following are some general guidelines Low: The risk exists and needs to be dealt with, but the impact will not be severe, and the mitigation strategy is well understood. Medium: The risk is substantial, but a mitigation plan can be accomplished. High: The risk will have a major impact on the success of the initiative and must be addressed before moving forward. Where assessment involves considering multiple items, some may be high risk and others medium or low. For example, the assessment is covering company stability and there are 5 suppliers involved, some very stable, others not. In cases such as this, to make the overall assessment follow these guidelines: Ignore any item that is being reused. For example if the Supplier is involved because they provide a product or service in support of an existing Feature then EDS should already be aware of the status of that Supplier and be acting accordingly. Consider items that are vital to delivering the Offering. For example a supplier may only be providing software that is a minor cost compared with the overall total, but it is vital to the Offering, then this Supplier would need to be considered. Where more than one item is still to be considered, the risk assessment should be made on the highest risk case. Record an overall description of all other items in the notes. These are only guidelines and if the real situation can only be portrayed by fully assessing multiple items, this should be done.
V2.2 07-31-06
Page 10 of 37
Risk Assessment - General

1. Have sufficient offering details been provided in order to develop an accurate risk assessment? Topic: Offering Description Reference(s): Business Requirements Product Release Plan o Release Roadmap Matrix o Release Description o Release Risk Analysis
Not Applicable
Rating x Low _ Medium _ High
Insufficient Requirements
Criteria Well-defined details Some incomplete details Vague or missing details
Notes: (Required for all Medium and High ratings) Offering Details are well defined Recommended mitigation strategy: (Required for all Medium and High ratings) <Insert comments>
V2.2 07-31-06
Page 11 of 37
Technical Risk Assessment 2. How reasonable is the Portfolio Management-suggested time-to-market for this initiative? Topic: Time-to-Market Reference(s): Business Requirements Product Release Plan: Release Roadmap Matrix
Not Applicable
Rating _ Low X Medium _ High
Criteria Time frames seem reasonable with normal resource levels Time frames is a concern because it may require above average resource levels Time frames may require a large amount of additional resources OR Time frames were not provided
Notes: (Required for all Medium and High ratings) Time to market is very aggressive and may require significant resources to deliver on time. Dependency on other components to deliver the solution may extend the timeframe for this particular solution. Recommended mitigation strategy: (Required for all Medium and High ratings) Validate all required resources are available, if resources are not currently scheduled or available open a risk dependency with the project manager.
V2.2 07-31-06
Page 12 of 37
Technical Risk Assessment 3: How much experience does EDS have with these processes or technologies or both? Topic: EDS Experience References: Business Requirements Product Release Plan: Release Scope of Features & Capabilities EDS Enterprise Architecture EDS Technology Policy
Not Applicable
Criteria Substantial experience Limited experience No experience
Notes: (Required for all Medium and High ratings) HP Enterprise Services has a lot of experience with the technologies involved in the solution. The process and governance to control when a solution utilizes the Standard Dedicated uCMDB solution and when a deployment is custom is not well defined and has typically not been well governed or controlled. This process that determines when a solution is custom versus leveraged needs to be well defined. The governance process must accommodate both new sales in the solutioning phase as well as during the steady state operations. If the process detects a solution that does not fit the strict guidelines for a leveraged solution, the appropriate organization will be notified and an action plan to transition or support the custom solution by the appropriate organization should be documented and executed. Recommended mitigation strategy: (Required for all Medium and High ratings) One of the outputs of the solution will be a governance process that describes the processes and steps to be followed during initial sales creation and steady state. The process will define ghte criteria and actions that need to be taken if a solution is determined not to meet the leveraged deployment criteria.
V2.2 07-31-06
Page 13 of 37
Technical Risk Assessment 4: How is the learning curve for these processes or technologies or both characterized? Topic: Learning Curve References: Business Requirements Product Release Plan: Release Scope of Features & Capabilities
Not Applicable
Rating X Low _ Medium _ High
Criteria Easy Challenging Very Steep
Notes: (Required for all Medium and High ratings) The learning curve is not great. Many companies already have the processes in place and this implementation will not change any of the customers processes, just the tools utilized to facilitate the configuration management processes. Recommended mitigation strategy: (Required for all Medium and High ratings) <Insert comments>
V2.2 07-31-06
Page 14 of 37
Risk Assessment Process
1: To what extent can standard processes be followed? Topic: Process Conformance References: Business Requirements EDS Enterprise Architecture Standard realization processes followed within EDS for different product work types are listed below Table 1 Product Work Type Applications and System Engineering Operations Applications Development Project Management Realization Process GAD QMS: http://www.gsmsam.eds.com/gad_qms/gsms/
ITIL: http://www.gsms-am.eds.com/itil/ OCE: http://www.gsmsam.eds.com/gad_qms/gsms/perform_task.htm PM2: http://pm2.iweb.eds.com/processes/process_pm2.asp
Not Applicable
Rating X Low
Criteria Processes employed, if any, are in conformance with one of the following in the order of preference listed below EDS standard realization processes listed above in Table 1, wherever existent Industry standard processes if there are no EDS standards defined in this space EDS Alliance Partner processes if there are no EDS or industry standards defined in this space.
_ Medium
Most of the processes are in conformance with one of the following standards: EDS process standards EDS Alliance Partners' process standards Standards applicable to the industry in context
V2.2 07-31-06
Page 15 of 37
Technical Risk Assessment _ High Few processes, if any, are in conformance with EDS standard realization processes or EDS Alliance Partners' standards Processes are following multiple standards (EDS, EDS Alliance Partner or otherwise) Notes: (Required for all Medium and High ratings) All common processes for development, project management, and operations can be followed. There are not special circumstances which would require alteration of stand processes. Recommended mitigation strategy: (Required for all Medium and High ratings) <Insert comments>
V2.2 07-31-06
Page 16 of 37
Technical Risk Assessment 2: Do the process steps within a process flows have defined conditional activities that accommodate potential success or failure conditions? Topic: Process Flow Definition References: Business Requirements Product Release Plan
Not Applicable
Rating X Low
Criteria Consensus reached between process stakeholders on flow with supporting documentation for the success and failure paths Ongoing discussion between process stakeholders on the flows for the success and failure paths Consensus has not been reached between process stakeholders for most of the flow paths
_ Medium _ High
Notes: (Required for all Medium and High ratings) <Insert comments> Recommended mitigation strategy: (Required for all Medium and High ratings) <Insert comments>
V2.2 07-31-06
Page 17 of 37
Technical Risk Assessment 3: How many of the following process components will be involved in this initiative? Program Management and Governance Service Support Project Management Service Desk Change Management Configuration Management Release Management Problem Management Incident Management Service Delivery Service Level Management Capacity Management Availability Management Document Management Value Management Applications and Systems Engineering Applications Development Operations Trading partner interaction Business Process Software Development Knowledge Management Knowledge Transfer
Topic: Process Components References: Business Requirements Product Release Plan
Not Applicable
Rating X Low _ Medium
Criteria 1-7 8-15
V2.2 07-31-06
Page 18 of 37
Technical Risk Assessment _ High 15-21
Notes: (Required for all Medium and High ratings) Low risk due to number of processes this affects. Recommended mitigation strategy: (Required for all Medium and High ratings) <Insert comments>
V2.2 07-31-06
Page 19 of 37
Technical Risk Assessment 4: What is the extent to which these processes can be reused across industries? Topic: Process Reusability References: Business Requirements EDS Enterprise Architecture
Not Applicable
Criteria Processes can be reused across industries. No customization required. Processes can be reused between customers within an industry. Some customization is needed to use these processes for customers in other industries. Processes are specific to one or more customers within an industry. Major customization is required to use these processes for other customers.
_ High
V2.2 07-31-06
Page 20 of 37
Technical Risk Assessment 5: To what extent can Workflow-based processes be scaled? Topic: Process Scalability References: Business Requirements EDS Enterprise Architecture
Not Applicable
Criteria Workflow-based processes can scale across geographies and industries Workflow-based processes can scale across customers within a given geography or industry Workflow-based business processes can scale within a customers enterprise
Notes: (Required for all Medium and High ratings) Workflow processes related to the Standard Dedicated uCMDB implementation will primarily be the processes owned and developed by the customer. The only processes related to this initiative that are HP Enterprise Services developed is the governance process that controls the decisions during the sales cycle and steady state that validate whether the Standard Dediated uCMDB solution applies. Recommended mitigation strategy: (Required for all Medium and High ratings) <Insert comments>
V2.2 07-31-06
Page 21 of 37
Technical Risk Assessment 6: To what extent do the Business Processes employ the EDS industry frameworks? Topic: EDS Industry Frameworks References: Business Requirements EDS Enterprise Architecture
Not Applicable
Rating _ Low _ Medium _ High
Criteria The offering is based completely upon one of the industry frameworks. Process related components of the offering are based upon one of the EDS industry frameworks. Limited portions of the process related components of the offering are based upon one of the EDS industry frameworks.
V2.2 07-31-06
Page 22 of 37
Technical Risk Assessment 7: Are the tools supporting processes compliant with EDS technology Policy? Topic: Technology Policy Tools Compliance References: Business Requirements EDS Technology Policy EDS Enterprise Architecture
Not Applicable
Rating X_ Low _ Medium
Criteria Supporting technologies, if applicable, are all provided by EDS Alliance partners. Supporting technologies are provided by parties other than EDS Agility Alliance partners but are in conformance with the EDS process-related standards. Supporting technologies are not provided by EDS Alliance partners and are not in conformance with the EDS process-related standards.
_ High
Notes: (Required for all Medium and High ratings) All technologies utilized to support the processes related to HP Enterprise Services are provided by HP Software. Recommended mitigation strategy: (required for all Medium and High ratings) <Insert comments>
V2.2 07-31-06
Page 23 of 37
Technical Risk Assessment 8: To what extent are the processes specific to the tools that enable them? Topic: Tool Independence References: Business Requirements Product Release Plan EDS Enterprise Architecture
Not Applicable
Criteria Processes can be implemented using most tools in this space. Processes can be implemented using a subset of tools in this space. Processes are tool specific.
V2.2 07-31-06
Page 24 of 37
9: What is the level of effort in integrating the processes? Topic: Process Integration Effort References: Product Release Plan Business Requirements EDS Enterprise Architecture
Not Applicable
Rating _ Low X Medium
Criteria Most of the processes are already integrated with no manual intervention required. Integration can be achieved with existing technologies but some processes are yet to be integrated. Inputs and Outputs have been identified and aligned. Some processes require manual intervention, but inputs and outputs have been identified and aligned.
_ High
Manual intervention is required between processes and no inputs and outputs have been identified.
Notes: (Required for all Medium and High ratings) The process developed to provide governance has not yet been integrated to the overall sales and steady state process. Recommended mitigation strategy: (Required for all Medium and High ratings) The process and governance to manage the deployment of the Standard Dedicated uCMDB instance during the sales cycle and steady state will be developed during the design phase and integrated into the sales cycle. The same governance process will be integrated into the normal change process for steady state governance.
V2.2 07-31-06
Page 25 of 37
Technical Risk Assessment 10: To what extent can the processes be automated? Topic: Process Automation References: Product Release Plan Business Requirements EDS Enterprise Architecture
Not Applicable
Criteria Most of the processes employed are already automated and configurable Processes employed can be automated using existing technologies. Some automated processes are configurable Processes cannot be automated and are therefore not configurable. New investment required in appropriate technologies to make these processes automated and configurable
V2.2 07-31-06
Page 26 of 37
Technical Risk Assessment 11: To what extent can the effectiveness of the business processes be measured and monitored? Topic: Process Measurability References: Product Release Plan Business Requirements EDS Enterprise Architecture
Not Applicable
Criteria Measurement metrics have been pre-defined and the metrics collection mechanisms are all automated Measurement metrics have been pre-defined and some of the metrics collection mechanisms are automated Measurement mechanisms have not been pre-defined and most of the metrics collection mechanisms are manual or have to be incorporated
Notes: (Required for all Medium and High ratings) Metrics to measure the efficiency of running the solution are already defined, but the process required to measure the effectiveness of the governance process have not been determined or defined. Recommended mitigation strategy: (Required for all Medium and High ratings) As part of this project, one of the outputs will be a defined process and metrics to measure the effectiveness of the governance process used to determine custom versus leveraged solutions. The process and metrics will provide valuable information to the business regarding the governance process for the Standard Dedicated uCMDB solution.
V2.2 07-31-06
Page 27 of 37
Risk Assessment - Technical

1. How mature are the required technologies in todays market? Topic: Technology Alignment Reference(s): Business Requirements Product Release Plan EDS Technology Policy
Not Applicable
Criteria Existing technologies require minor modification(s) Existing technologies require major modification(s) Leading edge or new technologies required Aging technologies that are a challenge to support (e.g. New COBOL offering)
Notes: (Required for all Medium and High ratings) The existing technologies require minor modifications. These modifications will be done at the edge of the architecture which will not impact the core systems. Recommended mitigation strategy: (Required for all Medium and High ratings) <Insert comments>
V2.2 07-31-06
Page 28 of 37
Technical Risk Assessment 2. How stable are the technology providers? Topic: Company Stability and Potential Reference(s): Business Requirements Product Release Plan: Alliance and Vendor Usage EDS Technology Policy
Not Applicable
Criteria Existing, well-established, well recognized companies with a track record of product and technology success. Emerging companies with sufficient financial resources and management team with strong track record of success. OR Maturing companies with established client bases and documented track records of product performance.
_ High
Emerging companies with limited financial resources and little or no track record of success.
Notes: (Required for all Medium and High ratings) Technologies being used are either from HP or technologies that are prevalent in the marketplace and being utilized by HP software. Recommended mitigation strategy: (Required for all Medium and High ratings) <Insert comments>
V2.2 07-31-06
Page 29 of 37
Technical Risk Assessment 3. How complex are the integration issues surrounding these technologies? Topic: Integration Issues Reference(s): Business Requirements Product Release Plan: Preliminary Architecture Diagram EDS Technology Policy
Not Applicable
Criteria Integration methods are currently used and available either within EDS or in the marketplace Some integration methods will need to be developed by either EDS or technology vendors Some of the integration methods and/or their sources are unknown
Notes: (Required for all Medium and High ratings) The integration capabilities are not complex and already exist within HP Enterprise Services. No new integration technologies are being introduced or utilized in the solution. Recommended mitigation strategy: (Required for all Medium and High ratings) <Insert comments>
V2.2 07-31-06
Page 30 of 37
Technical Risk Assessment 4. How available are the required technologies? Topic: Technology Availability Reference(s): Business Requirements Product Release Plan Release Description Alliance and Vendor Usage EDS Technology Policy
Not Applicable
Criteria All required technologies are available from existing partners Most required technologies are available off-the-shelf from non-partner vendors New partnerships will have to be created before EDS has access to these technologies
Notes: (Required for all Medium and High ratings) All Technologies are either available from HP software or from vendors that HP already has established relationships with. Recommended mitigation strategy: (Required for all Medium and High ratings) <Insert comments>
V2.2 07-31-06
Page 31 of 37
Technical Risk Assessment 5. What is the state of the current standards supporting these technologies? Topic: Standards Reference(s): Business Requirements Product Release Plan: Release Description EDS Technology Policy
Not Applicable
Criteria Single defined standard Competing standards No globally accepted standards
V2.2 07-31-06
Page 32 of 37
Technical Risk Assessment 6. How many of the following technology and technology management categories will be involved in this initiative? Hosting Networking Wireless and Mobility Storage Distributed Systems and Desktops Application Services Security Workflow and Provisioning Topic: Technology Requirements Reference(s): Business Requirements Product Release Plan: Preliminary Architecture Diagram EDS Technology Policy
Not Applicable
Criteria 1 to 2 3 to 4 5
Notes: (Required for all Medium and High ratings) HP Software uCMDB8.02+. Java Secure File Transfer DCS from ESL, Network from Redfish, Distributed Desktop All these technologies are very mature and are prevalent in the market place. Recommended mitigation strategy: (Required for all Medium and High ratings) While there are multiple technologies involved in the project, all are very mature in the marketplace and are very sell defined and in production at a number of customer sites across the HP customer base. During the design phase, continued interlock between the service lines and the other owners of information like ESL, Redfish and the BMC Atrium tool will be held to make sure architecture aligns with the needs of the stakeholders..
V2.2 07-31-06
Page 33 of 37
Technical Risk Assessment 7. Are we changing the manner of 1) usage, 2) deployment, or 3) support of an existing technology (e.g., tool)? These are defined as follows: 1) Usage: Using a technology for a different purpose, or use by a different user community. This could also include a change in licensing scheme. 2) Deployment: Changing the way a technology is hosted or distributed, e.g. a desktop tool will now be centrally hosted.
3)
Support: Changing the level or manner of support, e.g. going from 8x5 to 24x7 support, or going from vendor support to EDS help desk support. Not necessarily related to a change in deployment, but if the deployment changes, it is likely support will change as well.
Topic: Standards Reference(s): Business Requirements Product Release Plan: Release Description EDS Technology Policy
Not Applicable
Criteria Minor changes to one of the three aspects More complex changes to one or two aspects Complex changes to two to three of the aspects
Notes: (Required for all Medium and High ratings) We are changing the deployment of the configuration management tool. Today the tool is only offered as a leveraged instance integrated with other tools within a leveraged stack. This offering will switch the deployment to a distributed or Standard Dedicated uCMDB that will need to be managed and supported from a leveraged model. If changes to the environment violate the Standard Dedicated model, actions will need to be taken to transition the support model to a custom or dedicated support model. Recommended mitigation strategy: (Required for all Medium and High ratings) <Insert comments>
V2.2 07-31-06
Page 34 of 37
3. Additional Risks
Instructions
Replicate the template below to capture pertinent information describing additional risks that need to be analyzed before moving forward. Use the following as guidelines when identifying additional risks: 1. Risks are intended to point out high-level show stoppers 2. Risks will cover only the technologies (not capabilities or offerings) -- technologies can exist even though the Capability or Offering does not! 3. Risks should cover general technologies (e.g., mature hosting technologies exist in this space, but the anticipated communications technologies are immature), but should not cover specific hardware or software products. 4. Risks may cover resource requirements at a high level (e.g., will require new security technologies, but most of the security organization is working on project X for the next 6 months) 5. Risks should address Portfolio Management-imposed restrictions (e.g., time-to-market is 3 months, 75% cost reduction, must use product "A" from supplier "Z", etc.)
Risk Description and Assessments

1. Risk: HP Enterprise Services has many Managed File Transfers solutions that can be used to deliver a secure file transport mechanism, but there is not particular component that has been identified to fill that gap within the current SRA application stack. Topic: SOE Standard Component References: Business Requirements Architecture Components
Not Applicable
Rating _ Low
Criteria Business has a well defined solution that has the appropriate business ownership and has been documented as the Managed File Transfer solution that can be used by other capabilities. Business has a solution that can fulfill the capability but lacks a clear business owner that is responsible for the solution.
_ Medium
V2.2 07-31-06
Page 35 of 37
Technical Risk Assessment X High There is no clear business owner for the managed file transfer solution and the managed file transfer solution is not documented within the current components available for use the solution design.
Notes: (Required for all Medium and High ratings) HP Enterprise Services has a technology that has been deployed in the Legacy EDS environments but lacks the following items: 1. No clear business owner for the solution 2. No clear technical owner responsible for ongoing development and integration into the overall architecture 3. No well defined support or deployment model Recommended mitigation strategy: (Required for all Medium and High ratings) This issue is currently being addresses within the ESM organization and will be documented as a risk or critical dependency within the Standard Dedicated uCMDB solution.
V2.2 07-31-06
Page 36 of 37
2.Risk: Release and Deployment Management does not reflect the interdependencies between each of the individual projects being worked within the ESM organization. Topic: Release and Deployment Management References: Business Requirements Architecture Components
Not Applicable
Rating _ Low
Criteria The Release and Deployment process has a very clear and mature process to determine interdependencies of business solutions and a means to schedule the release based on the dependencies of the individual components. The Release and Deployment does not have a clear or mature process to track the dependencies of components but the individual projects have an understanding of their dependencies on other components or projects. The Release and Deployment process does not have a clear and mature process to determine interdependencies of business solutions or a means to schedule the releases based on the dependencies of the individual components within those solutions.
_ Medium
X High
Notes: (Required for all Medium and High ratings) The Release and Deployment Management process does not have clear line of sight to the detailed dependencies each of the projects have on each other. A general dependency of the projects may exist, but there is no overall detailed dependency mapping that would allow the RADM team to determine what components can be deployed independent of any other components. Recommended mitigation strategy: (Required for all Medium and High ratings) Document at a component level within the project those dependencies on other architectural components that are required to deliver the solution to the business. The detailed dependencies will be supplied to the RADM team so they can appropriately schedule implementations based on these dependencies.
V2.2 07-31-06
Page 37 of 37

Technical Risk Assessment

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Technical Risk Assessment

Încărcat de

Drepturi de autor:

Formate disponibile

Portfolio Development