Alternatives

Document Sample
Alternatives Powered By Docstoc
					                                          Alternatives

Project:       _________________                       Date:

Core System:


Intended audience: Executives, IT managers, business managers
Who fills this out? I.T. and Business Managers
Purpose of this tool:
The intent of the Alternatives tool is to help organize reasons for considering or not
considering specific alternatives for a proposal.
A proposal may have components of more than one alternative. For example, a
proposal may be to re-host and to modify a system. This tool can help identify a
specific alternative, a set of alternatives, or a combination of alternatives to consider in
the proposal.
The project team should analyze each alternative considered in the proposal with the
“Impact Analysis” tool. The Impact Analysis will help the team determine what actions
and considerations they need to add in their project plan based on the chosen
alternative(s).




D:\Docstoc\Working\pdf\d00d1f7f-ae27-4318-a5dd-2faafc59ac84.doc
Modify. The “Modify” alternative may include one or more actions. These actions may
include refurbishment, renovate, re-engineer, extend, or enhance.

Modify              √ Rationales:
                        1. It may be most cost effective to modify the existing
                           application. There will be low or no cost to purchase
                           anything.
                        2. Difficult to obtain necessary funds for replacement.
                           Modification requires the fewest resources (people, software,
                           hardware).
                        3. Expertise is available within the University or through a
                           vendor to perform the modifications. There is sufficient
                           internal knowledge, documentation, and training available to
                           modify the application.
                        4. Large parts of the application work well. The application
                           already meets customized business needs. Replacement
                           would require rewriting complex business rules. Lower risk
                           than replacing or rebuilding.
                        5. Customers like the system.
                        6. Modification will take less time than a re-host or replacement.
                        7. Platform and architecture (e.g., database engine,
                           programming language) are still viable.
                        8. Technology exists that can extend and enhance system
                           capabilities.
                        9. Application complexity is not so high that it precludes
                           modification.
                        10. The functionality improvements and user requirements are
                            relatively minor. The line where modifications are reasonable
                            versus not reasonable has not been crossed.
                        11. The requirements for the application change little and
                            infrequently. With some modifications, the existing
                            application can meet the state’s needs into the future.




D:\Docstoc\Working\pdf\d00d1f7f-ae27-4318-a5dd-2faafc59ac84.doc
Re-Host. The “Re-Host” alternative means moving the system from one host to
another. The host may be hardware, software, or a combination of the two. You should
define a migration process for moving the system to the new host without extensive
code changes.

Re-Host             √ Rationales:
                        1. The existing application’s maintenance costs are high. Re-
                           hosting the application will lower the maintenance costs.
                        2. Burning platform – antiquated hardware, software, or storage.
                           Existing vendor may not be viable. Little or no vendor support
                           for current host. University’s ability to maintain and support
                           the application is severely at risk.
                        3. Existing system meets business requirements; therefore,
                           complete replacement is not necessary.
                        4. Can move to a new host without many changes to code,
                           database, or other application elements. This reduces cost,
                           time, and risk compared to the “modify” and “replace” options.
                        5. The current host does not adequately meet interface
                           requirements.
                        6. Opportunities may exist for additional functionality and
                           options with the new host.
                        7. A new host will deliver performance improvements. The
                           existing application is not providing adequate performance
                           and this cannot be improved by modifications to the
                           application.
                        8. Modern tools and good quality documentation with the new
                           host may allow faster changes and more controlled
                           maintenance for the application. The new host may offer
                           more efficiency in a number of other areas.




D:\Docstoc\Working\pdf\d00d1f7f-ae27-4318-a5dd-2faafc59ac84.doc
Replace. The “Replace” alternative refers to replacing an entire system.

Replace             √ Rationales:
                        1. The existing application’s maintenance costs are high.
                           Replacing the application will lower the maintenance costs.
                        2. Burning platform – antiquated hardware, software, or storage.
                           Existing vendor may not be viable. Little or no vendor support
                           for current host. University’s ability to maintain and support
                           the application is severely at risk.
                        3. Agency needs to provide this service but the existing
                           application is not meeting the needs. Business requirement
                           is still there.
                        4. There are more skilled people readily available to implement
                           and maintain a new system than the existing system. Skills
                           and expertise to run the existing application are becoming
                           rare.
                        5. The symptoms of the current application are looking very bad.
                           Symptoms can include ability to meet business needs,
                           maintenance backlog, data quality, business disruptions,
                           customer satisfaction, performance, vendor support
                           commitment, staff expertise, system documentation,
                           operation costs, and maintenance costs & effort.
                        6. The efforts to complete the necessary changes are so
                           complex and large that modification is not a viable option.
                           When the requirements are collected and documented, a
                           replacement solution will meet the requirements more
                           completely and economically then the other alternatives.
                        7. Data conversion is not too difficult. Customers will have an
                           improved user experience from the standpoint of the
                           interface, system functionality, and/or support.
                        8. Customers do not like or will not use the existing system.
                           Customers will have an improved user experience from the
                           standpoint of the interface, system functionality, and/or
                           support.
                        9. A new application will deliver performance improvements.
                           The existing application is not providing adequate
                           performance and this cannot be improved by modifications to
                           the application.
                        10. Business requirements will be changing frequently in the
                            future. The existing application is not easy to change
                            compared to a replacement.

D:\Docstoc\Working\pdf\d00d1f7f-ae27-4318-a5dd-2faafc59ac84.doc
Replace: Develop. The “Replace: Develop” alternative refers to replacing an entire
system by developing a new system. All the rationale for the “Replace” alternative are
applicable here. The following rationales are specific to those replacements done by
developing a new system.

Replace:            √ Rationales:
Develop
                        1. Institutional knowledge available in-house.
                        2. No products readily available on the market (e.g., the
                           application may be small or very customized so not many
                           companies would respond to an RFP).
                        3. Lots of customization required if you were to purchase an
                           application.
                        4. Treat the development process as an in-house training
                           experience to develop new competence in existing staff. This
                           will also help support the application once it is in production.
                        5. The documentation for requirements, business rules, and
                           logic is sufficient to support development requirements and
                           design.




D:\Docstoc\Working\pdf\d00d1f7f-ae27-4318-a5dd-2faafc59ac84.doc
Replace: Develop: In-House. The “Replace: Develop: In-House” alternative refers to a
replacing an entire system by developing a new system by University staff. All the
rationale for the “Replace” and “Replace: Develop” alternatives are applicable here.
The following rationales are specific to those replacements done by developing a new
system by University staff.

Replace:            √ Rationales:
Develop: In-
House
                        1. Lower cost than through a vendor.
                        2. Better expertise available in-house than through a vendor.
                           Control over the project’s risk, scope and complexity is within
                           the grasp of the agency, provided the agency has the
                           resources to do the development.
                        3. Knowledge of the application does not exist in the
                           marketplace.
                        4. Reduced maintenance cost because agency staff who built
                           the application will be very knowledgeable about the
                           application.
                        5. The University will own the source code at the end of the
                           project.
                        6. More sense of ownership if developed by the University.




D:\Docstoc\Working\pdf\d00d1f7f-ae27-4318-a5dd-2faafc59ac84.doc
Replace: Develop: Vendor. The “Replace: Develop: Vendor” alternative refers to a
replacing an entire system by developing a new custom system by vendor staff. All the
rationale for the “Replace” and “Replace: Develop” alternatives are applicable here.
The following rationales are specific to those replacements done by vendor staff
developing a new system.

Replace:        √ Rationales:
Develop: Vendor
                  1. Expertise to staff the project is not available within the
                     University.
                         2. Experienced vendors are available to develop the application.
                         3. Vendor development for complex applications lowers the risk
                            to the University because the vendor takes on responsibility
                            and has proven expertise.
                         4. University can use contractual controls to shift risk and
                            accountability to the vendor. The University can contract for
                            price, schedule, deliverables, and documentation and hold
                            the vendor to the terms.
                         5. Portfolio Management principles and ISB guidelines
                            encourage vendor development for complex applications.
                         6. The vendor can provide useful tools and methodologies
                            otherwise not available to the University to complete the
                            project.
                         7. Vendors may be able to speed development by applying
                            more resources than are available to the University.




 D:\Docstoc\Working\pdf\d00d1f7f-ae27-4318-a5dd-2faafc59ac84.doc
Replace: Develop: Combined. The “Replace: Develop: Combined” alternatives refers
to a replacing an entire system by developing a new system by the University and
vendor staff. All the rationale for the “Replace” and “Replace: Develop” alternatives are
applicable here. The following rationales are specific to those replacements done by
University and vendor staff working together to develop a new system.

Replace:            √ Rationales:
Develop:
Combined
                        1. This option can reduce costs by targeting vendor involvement
                           in areas the University does not have expertise or resources
                           and by using University staff in areas where resources are
                           available and knowledgeable.
                        2. Experienced vendors are available to develop the application.
                        3. The University can achieve knowledge transfer in certain
                           selected areas from the vendor.
                        4. The vendor can provide useful tools and methodologies to
                           complete the project.




D:\Docstoc\Working\pdf\d00d1f7f-ae27-4318-a5dd-2faafc59ac84.doc
Replace: Purchase. The “Replace: Purchase” alternative refers to a replacing an
entire system by purchasing a new system. All the rationale for the “Replace”
alternative is applicable here. The following rationales are specific to purchased
replacements.

Replace:            √ Rationales:
Purchase
                        1. Expertise to staff a development project is not available within
                           the University.
                        2. The vendor provides references that use the purchased
                           system. It works well in other places so it has a proven
                           record of accomplishment.
                        3. Choices exist. Purchased systems provide functionality.
                           Mature, proven applications are available from a variety of
                           vendors that are likely to meet majority of anticipated
                           requirements.
                        4. Implementation will involve less time, cost, and risk than
                           developing a new application.
                        5. The talent pool to staff implementation and maintenance with
                           a purchased application may be larger than for a custom
                           application.
                        6. Opportunities may exist for a broader feature set than can be
                           produced by a developed application.
                        7. Opportunities may exist for additional functionality and
                           options with the new host.
                        8. Modern tools and good quality documentation with the new
                           host may allow faster changes and more controlled
                           maintenance for the application. The new host may offer
                           more efficiency in a number of other areas.
                        9. Third party tools and features are available.
                        10. Speed of deployment is quicker. Greater availability and
                            faster time to market (depending on customizations required).
                        11. The application design facilitates enterprise use.




D:\Docstoc\Working\pdf\d00d1f7f-ae27-4318-a5dd-2faafc59ac84.doc
Replace: Purchase: Commercial. The “Replace: Purchase: Commercial” alternative
refers to a replacing an entire system by purchasing a new commercial system from a
vendor. All the rationale for the “Replace” and “Replace: Purchase” alternatives are
applicable here. The following rationales are specific to purchased commercial
replacements.

Replace:             √ Rationales:
Purchase:
Commercial
                        1. May be able to test drive an existing implementation of
                           system as part of feasibility study.
                        2. Implementation will involve less time, cost, and risk than
                           developing a new application.
                        3. Commercial application offers a higher commitment to
                           technical support and maintenance.
                        4. Contractual protections on maintenance, performance, and
                           functionality.
                        5. Rigorous upgrade schedule. A commercial application is
                           likely to stay current with technology trends and software
                           upgrades by other companies.




D:\Docstoc\Working\pdf\d00d1f7f-ae27-4318-a5dd-2faafc59ac84.doc
Replace: Purchase: Public Domain. The “Replace: Purchase: Domain” alternative
refers to a replacing an entire system by obtaining a public domain system. All the
rationale for the “Replace” and “Replace: Purchase” alternatives are applicable here.
The following rationales are specific to obtaining a public domain replacement.

Replace:         √ Rationales:
Purchase: Public
Domain
                   1. Cost effective. Low or no cost to purchase.
                        2. Public domain system provides functionality. Mature, proven
                           applications are available from a variety of vendors that are
                           likely to meet majority of anticipated requirements. University
                           may borrow an application from another state.
                        3. Public domain software may have a more open architecture
                           and available source code than commercial software.
                        4. Implementation will involve less time, cost, and risk than
                           developing a new application.




D:\Docstoc\Working\pdf\d00d1f7f-ae27-4318-a5dd-2faafc59ac84.doc
Replace: Outsource. The “Replace: Outsource” alternative refers to a replacing an
entire system by outsourcing the entire operation to a vendor. All the rationale for the
“Replace” alternative is applicable here. The following rationales are specific to
outsourcing a replacement system.

Replace:            √ Rationales:
Outsource
                        1. A vendor offers an outsourcing option that meets
                           requirements. The vendor has expertise in an area that is
                           outside the University’s core competence.
                        2. No University staff required for developing and maintaining
                           the application.
                        3. Vendor has a proven record of accomplishment.
                        4. Lower cost and less risk to use an outsourced application.
                        5. Less time to implement an ongoing operational outsourced
                           application.




Next Steps?
  The next step of the process involves developing the Business Justification Outline.




D:\Docstoc\Working\pdf\d00d1f7f-ae27-4318-a5dd-2faafc59ac84.doc

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:3
posted:4/5/2012
language:English
pages:12