Case Study Requirements

Trusty Carpets Case Study

VII.  Requirements Checklist

The purpose of this section is to document some examples of the requirements for the proposed system.  The section should begin with a brief introduction.  The requirements checklist communicates what the system is expected to do and how it is to perform.  For purposes of this business case, the requirements checklist will include five (5) requirements, each one stated as one complete sentence, for each of the following areas:

Save your time - order a paper!

Get your paper written from scratch within the tight deadline. Our service is a reliable solution to all your troubles. Place an order on any task and we will take care of it. You won’t have to worry about the quality and deadlines

Order Paper Now

A. Functional Requirements.  Five requirements statements that tell what the system must do.

A.  Data Requirements.  Five requirements statements for handling input, output and storage of data.

Building a Business Case

This document describes the course-long group project to develop a business case for an IT solution that will provide improvements for the organization in the Case Study (posted separately under Content>Course Resources).

 

What is a Business Case?

A business case is a tool used in making business investment decisions, such as: investing in an IT asset like a new information system, a new network, or additional storage capacity; entering a new business venture; or discontinuing a product or service. A business case is a structured proposal that provides the necessary information regarding how the proposed course of action would benefit the organization.  The developers of a business case have an obligation to use good information-gathering techniques, perform a thorough analysis, and use proven financial models to support the recommendations.  This strengthens the credibility of the business case and provides management with the information they need to make an appropriate, objective decision.

The scope of the information requires significant effort on the project team’s part. However, a strong business case provides decision-makers with the exact information they need to make an educated, well-informed decision. Without this level of effort, senior management may lack sufficient information and therefore delay making a decision, or in the absence of more complete information, management may make a poor decision. A poor decision could result in approving a solution that is not in the best interests of the organization, implementing a system that does not fit into the existing IT architecture, failing to take advantage of maximum benefits through a more comprehensive solution, or failing to support a solution that would meet the defined business need and add value to the organization.

 

Business Case Assignments

A quick web search will reveal a variety of templates for a business case proposal, and many organizations and agencies have a particular format that is consistently used within their organization. For this class the following template will be used by each team. The template is robust but recognizes the timeline of an eight week course and therefore provides a balanced product that meets course goals and provides experience developing each major area of a business case.

The teams will develop each section of the business case, to be submitted according to the class schedule and as shown in green in this document.  Using the outline below, each week team members should read the weekly assignment and develop the assigned section(s) of the business case, ensuring that everything called for in each section is included.  Sections should be numbered as shown, with sub-headings used as appropriate.  An introduction for each section that have multiple parts should be provided, explaining what is contained in the section.  Following the requirements for each section in the instructions below, an approach to developing the section is included.  Additional resources containing explanatory material are located in the weekly content areas and in the Course Resources area.

The instructions for some sections include questions to be answered.  These should not just be listed as questions and answers in the business case; they should instead be used to ensure your explanation covers all the important points.

Each week, the team will add to the previously developed components of the business case and submit the entire business case through the assigned sections, including the Appendix and References entries.  Corrections and improvements to previously submitted sections should be made as part of the next submission, using the feedback received.  Although teams should make corrections each week according to the feedback received, only the sections due for the particular week will be graded. The entire business case will be graded at the end of class.

The remainder of this document describes each section of the business case and provides the requirements and an approach to developing each section.  The grading rubric for each deliverable is provided with the assignment instructions in the Assignment Folder.

 

 

Sections of the Business Case

Executive Summary

  1. Background and Environmental Analysis
  2. Problem Analysis
  1. Expected Improvements
  2. Alternatives Analysis
  3. Feasibility Analysis
  1. Project Management
  2. Acquisition Strategy
  3. Risk Management
  1. Conclusion

References

Appendices

 

Executive Summary   included in the Week 8 Group Assignment

The executive summary is the first section presented in the business case and the last written, similar to an abstract for an article.  It is a high-level view of the entire business case document. It succinctly conveys vital information about the project and communicates the entire story to the reader. It explains, in plain language and in a condensed form (1 page or less), the problem that the project is intended to solve, the expected outcome, and the resources required to complete the project.  The resources include the initial investment cost and the on-going operational costs.  Since most business investment decisions are based on their returns on investment, the predicted ROI and a projection of when it should be achieved are also provided.  Because some stakeholders read only the executive summary, it is important to provide any essential information required for them to make an informed decision, yet should not repeat the level of detail contained in the body of the business case.   The executive summary should also briefly describe the document that follows (the business case), telling the reader what is contained.

Approach to Developing this Section

After the entire business case is finished, develop a one-page (or less) summary as described above, and include the most important facts for the decision-maker.  Read the article on writing an executive summary from the UMGC Library, located in the Week 8 Content.  First impressions are important. Get this right!

 

Week 1 Group Assignment:  Section I; include the Title page.  Also, the Appendix and References pages should be created in Week 1 and submitted even if they are blank.  They will be there each week and can be updated according to the weekly assignments.

  1. Background and Environmental Analysis

 

(Notice the proper formatting above with Roman numeral and heading capitalization; use these for your business case.)  The purpose of this section is to give a clear introduction to the business case and project. It provides the background on the core aspects of the business and its operation in sufficient detail to set the stage for the explanation of the problems, opportunities, or changes that will follow.  This section also contains an analysis of the environment within which the business operates, identifying problems or opportunities in a number of areas, setting the stage for Section II, where the team will identify one problem or opportunity area for which a technology solution will be proposed in the business case.

 

Approach to Developing this Section

 

  1. Background. Begin with an introduction (A.) to the situation portrayed in the case study to provide a background on the organization and its current operation. Include the important points, but do not just reiterate the information in the case study.

 

  1. Environmental Analysis. Conduct some research on industry analysis and trends for the business in the case study, and select those that could impact the business. Include a description of at least one problem or opportunity in each of the following areas:
    • An opportunity or change to the Business Vision, Strategy or Objectives
    • Business processes or technologies which are not operating efficiently or have been rendered obsolete
    • New technology trends (or opportunities resulting from new technologies)
    • Commercial or operational trends which are driving changes in the business or industry
    • New or better products, technologies or processes in use by competitors
    • Changes to statutory, legislative or other environmental requirements.

Provide facts or evidence to support the conclusions drawn above, using one or two sentences with citations/references as appropriate.

 

Week 2 Group Assignment:  Sections II, III, & IV

  1. Problem or Opportunity Analysis
  2. This section describes the one fundamental business problem or opportunity which the resulting proposed solution will address. Depending on whether the team has selected a problem or an opportunity, provide the following information in Section II:
  • Business Problem – Provide a summary of the core business problem, including:
  • A description of the core issue
  • The reasons why the problem exists
  • How the problem aligns to the business strategy or vision
  • The elements which create it (e.g., human, process, technology)
  • The impact it is having on the business (e.g., financial, cultural, operational)
  • The timeframes within which it must be resolved
  • The reason the problem was chosen from among those identified in Section I.

OR

  • Business Opportunity – Describe the business opportunity which has been identified, including:
  • A summary of the business opportunity (not a solution)
  • How the opportunity was identified
  • How the opportunity aligns to the business strategy or vision
  • Any supporting evidence to prove that the opportunity is real
  • A timeframe within which the opportunity will likely exist
  • The positive impact that realization of the opportunity will have on the business.
  • The reason the opportunity was chosen from among those identified in Section I.

 

Approach to Developing this Section

As the team examines the problems and opportunities identified in Section I, it should focus on which problems/opportunities are most important to the business and should be addressed first.  Select one problem/opportunity area (or, two or three closely related problem/opportunity areas that lend themselves to a single solution).  Since the business case is being developed to support an IT solution, the problem or opportunity must be appropriate to an IT solution.  Describe the business problem or opportunity which the resulting project will directly address. Note:  this is a discussion of the problem or opportunity, and no solutions should be identified or discussed yet (that will come in the next section of the business case).

 

  • Proposed Solution

 

This section provides a one-paragraph high level description of the solution.  The solution must include a commercial software product.  The product name, a brief description, and essential information to support the expected improvements in Section IV should be included.

 

Approach to Developing this Section

Research solutions appropriate to the business problem or opportunity identified and the type of business in the case study.  Team members should research, identify and select an appropriate commercial software product.  There are a wide variety of industry-specific software solutions available.  The team should also decide on the type of implementation – will the software be installed and maintained on premise/site or will a hosted solution be used?  Each member of the team will use this software solution to develop his or her individual in-depth technical description, to be submitted separately according to the class schedule.

  1. Expected Improvements

 

The purpose of this section is to explain why the project is needed.  It should address the following:

  • How will the proposed solution address the stated problem in Section II, or how will the proposed solution take advantage of the business opportunity identified in Section II?
  • How does the proposed solution align with the business strategy and/or objectives?
  • What benefits can the organization achieve from this solution? Use the following categorizations and identify some benefits in each area:
    • Financial benefits
    • Non-financial benefits
  • What other value might the organization gain from this solution?

 

Approach to Developing this Section

Develop a clear and concise explanation of how the proposed solution (from Section III) directly addresses the problem or opportunity identified in Section II.  Then, review the case study to explain how the proposed solution aligns with the business strategy and/or objectives.  The team may need to infer business strategies and objectives from the information presented about the direction in which the business is headed.  There are several ways to categorize benefits (other than just financial or non-financial benefits).  The Week 2 readings provide some insights into strategic alignment and business benefits.

 

Create a list of benefits that the business can expect to achieve from implementing the proposed solution.  Determine which categorization is most appropriate to the benefits listed.  Then, categorize and explain in a sentence or two each of the benefits that have been identified.  If there are other ways that the organization would obtain value from implementing the system, those should also be discussed. One way to present the benefits is in a table, with a lead in sentence to the section.

 

 

 

 

 

Week 3 Group Assignment:  Sections V & VI

  1. Alternatives Analysis

 

(Note:  The use of the term “alternative” means an “option” for meeting the defined need.  Alternatives are not presented so that, in case the proposed solution is not approved or does not work, the stakeholders can just choose another of the listed alternatives.)

 

The purpose of this section is to list and describe several alternative ways of solving the problem or taking advantage of the opportunity identified, compare it to the proposed solution, and explain why the solution being proposed is the best of the alternatives listed.  The section should begin with a brief introduction.

 

An organization has the option of doing nothing – that is, maintaining the status quo.  The system solution the team is proposing is one of several ways to address the problem/opportunity.  It will be included as one of the “alternatives” considered.  Then, the team should come up with two other ways to address the problem/opportunity – one will involve a different IT solution, and the other will be a change to the business processes without using any additional IT capability.  The team will then have four possible ways of dealing with the problem/opportunity:

  1. Status Quo
  2. The Proposed Solution
  3. A Different IT Solution
  4. A Process Change

 

Each of these will be described, compared and contrasted as described below.

 

  • First, for each of the four possible solutions (notice there are six subsections to be included):
    • Describe the solution
    • Describe the major benefits and the extent to which it solves the problems identified in Section II
    • Identify the major cost elements and provide an estimated cost for the solution
    • Discuss the general feasibility of the solution – whether or not it is feasible and the reasoning behind the statements
    • Identify the top three risks (organizational, financial, IT, etc.)
    • Describe the major defining issues – things that would make it a less desirable solution than the proposed solution, or, in the case of the proposed solution, why it is the best alternative in general.

 

  1. Comparison of Alternatives. Next, compare the four alternatives using the following table and drawing the positive and negative aspects from the descriptions above.  Provide a label and a brief introduction for the table.

 

Name of Alternative Positive Aspects Negative Aspects
     
     
     
     

 

  1. Justification for Proposed System. The final step is to justify the selection of the system being proposed.  Summarize the primary reasons to justify why this option was chosen over each of the other three options and how it is the best choice to address the business needs identified in Section II.

 

Approach to Developing this Section

Read the HHS Feasibility Study and Alternatives Analysis, located in Content>Course Resources, beginning with section 2.8, to learn about one way that alternatives are analyzed.  The first two alternatives, the status quo and the proposed system solution, have already been determined.  The description of these two will draw upon information previously presented in the business case.  Do some research to identify another possible IT system solution that would meet the needs identified and use it for the third alternative.  Finally, for the processes that the proposed system will perform, describe how those processes could be improved by changing how the processes are performed without additional IT capability.

 

Describe each alternative following the list of areas provided above.

 

Then, summarize the four alternatives for comparison in the table provided above.  Review the description of each alterative and select the positive and negative aspects and include them in the table.

 

Finally explain and justify why the system being proposed is better than each one of the other three alternatives presented.

 

  1. Feasibility Analysis

 

The purpose of this section is to explain the readiness of the organization and its ability to implement and benefit from the proposed solution.  It should begin with a brief introduction. Then, you will assess the economic/financial, organizational/operational, and technical feasibility of the proposed solution, and express the likelihood of success for the proposed solution.  Each of the following areas should be addressed in paragraph form (remember not to use a question and answer format, just include all the required information):

 

  1. Economic/Financial Feasibility
    • In what economic environment is the business currently operating?
    • Is the proposed project within the financial capability of the organization?
    • How long should it be until the business starts recovering the costs of implementation through increased efficiencies, increased profits, reduced costs, etc.?
  2. Organizational/Operational Feasibility
    • How well does the proposed system solve the problem(s), or take advantage of the opportunity identified?
    • How easily can the proposed system be integrated into the existing business processes?
    • Is there a need for additional staffing?
    • Will staffing be reduced, and if so, how will that likely impact the organization?
    • Will a reorganization of the staff be required?
    • Is retraining feasible?
  3. Technical Feasibility
    • What assurance is there that the proposed system will perform the expected functions?
    • How will the proposed system fit with other IT already in use; does it fit into the current IT architecture?
    • How difficult will it be to implement the solution in the organization?
    • How difficult will the technology be for the employees to learn to use?
    • How difficult will it be for the organization to manage the proposed solution?

 

Approach to Developing this Section

Read Sue Conger’s introduction to feasibility analysis located under Content>Course Resources>Feasibility Study.  Also, read section 2.7 of the HHS Feasibility Study and Alternatives Analysis, located in Content>Course Resources.  Develop a paragraph or two for each area of feasibility, incorporating responses to each of the questions asked above.  Include a convincing argument for the likelihood of success of the proposed solution.

 

NOTE:  There is no group assignment due in Week 4.

 

 

 

Week 5 Group Assignment:  Sections VII and VIII

 

  • Requirements Checklist

 

The purpose of this section is to document some examples of the requirements for the proposed system.  The section should begin with a brief introduction.  The requirements checklist communicates what the system is expected to do and how it is to perform.  For purposes of this business case, the requirements checklist will include five (5) requirements, each one stated as one complete sentence, for each of the following areas:

  1. Functional Requirements. Five requirements statements that tell what the system must do.
  2. Data Requirements. Five requirements statements for handling input, output and storage of data.
  3. Technical Requirements. Five requirements statements setting out the system performance specifications.
  4. Security Requirements. Five requirements statements covering various aspects of system, data, and transaction security.

The result will be a list of 20 requirements statements, separated into the categories above.

 

Approach to Developing this Section

To gain and understanding of what constitutes well written requirements, read the “Writing Good Requirements” (and the other readings) provided in the Course Content.  It explains the correct way to write a requirement statement; your requirements must follow the guidelines presented there.

The area that requires the most careful consideration is determining into which category the requirement should be placed.  Almost all requirements are “functional” – but those which have to do with security or system performance or directly with data should be put into those categories.  “Functional” has to do what the system processing needs to do for the user.

Use information from the case study to develop the functional and data requirements.  Technical and security requirements may come from team members’ previous experience or learning, or from research.  Each requirement must specifically tie to the case study and the proposed solution.  Five well-written requirements are to be developed for each category:  functional, data, technical and security requirements, for a total of 20 requirements.  An introduction to the Requirements Checklist should precede the list.

You should understand that, although it is beyond the scope of this business case (and should not be included), to be able to trace requirements through the system development process, additional information is normally provided in the Requirements Checklist, including:  Category, Number, Statement of Requirement, Source of the Requirement, Where it is implemented in the system, how it is to be tested, and a place to indicate that each requirement has been implemented in the system.  In a total list of requirements for a system, there would also be many more requirements than this, but just listing the 20 requirements statements is enough to demonstrate the ability to identify and write requirements in the various categories.

  • Context Diagram

 

The purpose of this section is to provide a context diagram to illustrate the various types of system users and the types of interactions they will have with the system.  The context diagram supplements the requirements listed in Section VII to further illustrate the system requirements and solution.

  • Since this diagram will be placed in the Appendix, this section should include a brief explanation of the diagram and make reference to it.
  • The diagram shows the boundaries or scope of the proposed solution, the external entities involved, and the data that flows between the system and the external entities. Each type of system user should be included among the external entities.

 

Approach to Developing this Section

In developing this section, the team should be sure that the diagram matches the system description and includes all of the entities that interact with the system.  In developing the context diagram, the PowerPoint presentation “Context Diagram Explanation” (located in Course Content) provides an example and a brief explanation, and the icons can be copied and used for the team’s context diagram, if so desired.  Your diagram must be constructed as shown in the “Context Diagram Explanation.”  The system is in the center and the “actors” that interact with it are shown along with what data flows between the “actors” and the system.

 

In Section VIII, create an explanation of the context diagram and refer to it in the Appendix, and place the context diagram in the Appendix, with an appropriate Title for the diagram.

 

 

Week 6 Group Assignment:  Sections IX & X

 

  1. Project Management

 

This section of the business case provides a summary of the team’s plan for managing and implementing the proposed project.  Its purpose is to convince the decision-maker(s) that the project will be managed effectively, so that the stated objectives will be met within the time and budget allocated to the project.  A complete “Project Management Plan” would be separately developed and contain much more detail than is required here.  This section should begin with a brief introduction followed by three subsections (A, B, C.), with a lead in statement for each:

  1. Project Management. Write a description, using a paragraph for each, explaining how the following aspects of the project will be managed:
  2. Project Scope
  3. Time/Schedule
  4. Cost
  5. Quality
  6. Communications
  7. Stakeholders
  8. Project Team. List the members of the project team by their roles (not by name).
  9. Provide a schedule that lists the major tasks involved and how much time they require.  The schedule should be detailed enough to cover all the important activities, but does not need to include a Work Breakdown Structure.

 

Approach to Developing this Section

The six management areas listed come from the Project Management Body of Knowledge (PMBOK) list of about 10 knowledge areas.  Use the resources provided in the Week 6 Content to fully understand what is to be included for each of the above management areas.

In developing the list of the project team members, keep in mind the scope and budget for the project.  The project team should have all the required skill sets, but team members may function in multiple roles.  In order to keep costs low, the team should be as small and efficiently designed as possible.  The team should include both functional and IT personnel.

The schedule should be developed with the understanding that when the business case is approved, many of the project planning and analysis and design steps will have been completed.  So, using the information previously documented in the business case, the team should identify the major steps that remain to fully implement the project, and determine reasonable timeframes for them to be accomplished.  The schedule should be presented as a table with tasks, duration, and participants, including the person who has the lead for that activity.  The following table may be copied and used, if so desired:

 

Task Duration Leader Participants
Task 1      
Task 2      
Etc.      

 

  1. Acquisition Strategy

 

This section provides a recommendation and rationale for how the system will be acquired.  Often a combination of acquisition strategies are used, especially when both end-user hardware and enterprise systems are part of the solution. Begin this section with a brief introduction.  Then, determine which categories below apply to your solution, adding others as appropriate to your solution.  Be sure that everything that is needed is included. (The explanations for the sections numbered 1-3 follow the list.)

 

  1. End User Hardware. This includes all hardware to be used by the individuals who will use the system.
  2. Contract(s).
  3. Proposed System. This is the proposed system – how it will be acquired for use by the organization in the case study.
    1. Contract(s).
  4. Connectivity to Proposed System. This includes whatever is needed for the end users to connect to the proposed system (both from the business locations and remotely, as appropriate).
  5. Contract(s).

 

Then, for each category of components, include the answers to the following questions that are applicable to that item (remember not to use the question and answer format, but include the information in paragraph form):

  • Scope of what to buy:
    • What items in this category need to be acquired (list)?
    • Buy as a product or service? (some items may be purchased and others may be acquired as a service)
    • Commercial-off-the-shelf (including open source) or custom?
    • Will in-house staff or external contractors support custom development, integration, or sustainment?
  • What infrastructure will need to be acquired?
    • Will system hosting services be needed?
    • How will connectivity be made available?
    • What security considerations should be included in the contracts?
    • Will any specific hardware or software need to be acquired to provide security?
    • Will Business Continuity requirements need to be included in the contract(s)?
    • Will separate Business Continuity solutions or components need to be included or acquired?
    • Are there any data management considerations to be included in the acquisition(s)?
  • What type of contract(s) should be used?
    • Purchase order?
    • Local commercial purchase?
    • Service Level Agreement?
    • Lease?
    • Subscription?
    • Service Agreement?
    • Competitively awarded contract?
    • Time and materials contract?
    • Fixed price contract?

 

 

 

Approach to Developing this Section

Before beginning this section, read the “Basics of Defining Information System Acquisition Strategies,” in the Week 6 Content.  It explains how to approach acquisition planning and will help in responding to the questions above.  That document provides a guide to completing the documentation for a full acquisition strategy plan, which would include many of the same topics as are included in the business case.  For this section, focus on responding to the questions above, as they apply to what will need to be acquired for the system you are proposing.  Multiple acquisition strategies may be identified for the proposed solution.  For example, some components may be purchased outright, other products or services may be leased or available by subscription/service contracts.  If such is the case with the proposed solution, all of the applicable questions for each type of acquisition recommended need to be considered and responses should be provided if they apply to what is being acquired.  Some questions may not apply to the component being acquired (e.g., there does not need to be a data management strategy identified for a printer that is to be purchased).  Keep in mind that the full security requirements and solution will be covered in Section XII (yet to be developed), but your solution should have identified what security hardware and software would need to be acquired, and you should include here any security requirements that should be included in contracts or service requests associated with your solution.

Week 7 Group Assignment:  Sections XI, XII, & XIII 

  1. Risk Management

 

The purpose of this section is to identify potential risks to the project, and convince the decision-maker(s) that the risks will be managed, so that they will have minimal impact on the project.  It also alerts the stakeholder(s) to the most significant risks and what needs to be done to manage and mitigate them. Following the cost-benefit analysis, the next most important item to most senior leadership teams is risk.  They want to know what risks will be introduced by the proposed solution and how they can be managed.  In well-managed projects a separate “Risk Management Plan” is developed and used throughout the project.  For the business case, a summary of the most significant risks is provided along with a completed Risk Matrix.  This section will consist of the following:

  • An introduction to the section that explains the approach to managing the project risks and introduces the Risk Matrix.
  • A completed Risk Matrix as shown below. Since the Risk Matrix will be placed in the Appendix, this section should include a brief explanation of the Risk Matrix and make reference to it.
  • A summary that points out the most significant risks and what the stakeholder(s) must do to manage and/or mitigate them.

Risk Matrix

 

Risk Category

 

Description

Probability of Occurrence Impact

 of Occurrence

Strategy for Mitigation  

Contingency Plan

Strategic          
Business          
Feasibility          
Capability to Manage Investment          
Organization and Change Management          
Dependencies and Interoperability          
Security          
Surety (Asset Protection)          
Privacy          
Project Resources          
Schedule          
Initial  Cost          
Life Cycle Cost          
Technical Obsolescence          
Technology Environment          
Reliability of Systems          
Data and Information          
Overall Risk of Investment Failure          

 

 

Approach to Developing this Section

Work on this section should begin with filling in the Risk Matrix.  The “How To Guide to Risk Management” (located in Content>Course Resources>Risk Management) provides an explanation for each of the Categories of Risk. It was published by a government agency, the Indian Health Service (an agency in the Department of Health and Human Services) for its component organizations to use in assessing risk associated with proposed IT projects.  The guide fully and simply explains risk and risk management throughout the life cycle of a project.  Appendix A contains a complete Risk Management Plan outline.   Appendix B explains the risk analysis methodology and provides definitions for the risk categories listed in the Risk Matrix.  Appendix C provides an example of a completed risk assessment, although it is in a different format with slightly different data required.  Appendix D provides assistance in completing a particular form required by the U.S. Office of Management and Budget (OMB); it is not important for this class.  Additional information about risk categories is provided in the document “OMB Risk Types Definition” (also located in Content>Course Resources>Risk Management).

Note:  There are many different ways to analyze and manage risk.  For this class, the instructions here must be used.  Probability and impact are categorized as High, Medium or Low, not as numeric values.  A mitigation strategy must be provided for every risk category; it is not appropriate to say “accept risk,” for example.  A contingency must be provided to tell what to do if the risk becomes a reality and actually occurs.  Be careful that what you write is not a mitigation strategy that can be used to help avoid the risk, but an action to be taken if it occurs.

Using the Case Study, the above resource documents, and the IT solution being proposed, copy the table and complete the risk matrix provided above, describing for each Category of Risk:

  • One aspect of how that risk category applies to the proposed IT solution for the Case Study (i.e., what risk in each category may be caused or influenced by implementing the proposed IT solution)
  • The probability (High/Medium/Low) of its occurrence,
  • The impact (High/Medium/Low) on the organization if it does occur,
  • A strategy to mitigate the risk (what should be done to prevent the risk from happening or protect the organization if it happens), and
  • A contingency plan for what should be done in the event that it occurs.

 

Provide one example risk for each category listed in the Risk Matrix.  Explanations of each of the Categories of Risk are available in the document “How to Guide to Risk Management,” pages B3-B7.  Definitions for probability of occurrence and impact may be found on page 7, an example of a mitigation strategy is given on page 9, and an explanation of a contingency plan is on page 8 of the same document.  Do not limit responses to the space shown in table, but provide complete answers for “Description,”  “Strategy for Mitigation,” and “Contingency Plan.”

 

In addition to the matrix, this section should introduce, explain and summarize the risk matrix, and indicate that the full Risk Matrix is located in the Appendix.

Finally, this section should identify and discuss the most important risks and how they will be handled.  These are the risks that the sponsor, stakeholders and senior leadership should be aware of throughout the project.  Some of them may be able to be mitigated; if mitigation is not feasible, the decision-makers need that information as well.  This should be explained for the stakeholders.

  • Security

 

This section of the business case provides a general discussion of the important security aspects of the proposed solution, and the plan for protecting the data, the applications and systems, the network and the physical facilities (related to IT).  This portion of the business case summarizes what assets need protection and describes at a high level how they will be protected.  A full “Security Plan” would be developed separately from the Business Case; in the Business Case, only the topics provided here need to be covered.  This section should be written for a business person, not using highly technical terms.  A brief introduction should be provided.  Then, you will include security issues and protection mechanisms for each of the following:

  1. Data
  2. Application Software
  3. Systems
  4. Networks
  5. Physical Facilities Related to IT

 

Approach to Developing this Section

Refer to the Risk Matrix to identify specific security-related areas that are in need of protection.  Provide an explanation of the security issues associated with each of the aspects to be protected (data, application, systems, networks and physical facilities-each must be included).   Mechanisms (policy, procedure, technology solutions, etc.) to protect against each of the issues identified should be presented and explained in business terms for the decision-makers’ awareness.

 

  • Additional Implementation Issues

 

The purpose of this section is to identify any implementation issues not already covered in the previous sections of the business case.  First, provide a brief introduction to this section, then identify and explain three issue areas and how they will be handled in the implementation of the proposed system.

For each of the three, create a sub-heading and write a paragraph that:

  • Identifies the issue
  • Explains why it is an issue
  • Describes how it should be handled during the implementation of the proposed system.

The issues identified could come from any aspect of the system; the following questions may give you some ideas, but issues do not have to be limited to these areas:

  • What else should the organization consider?
  • What things should the project team keep in mind?
  • Are there any ethical or cultural considerations?
  • What impact will there be to the employees if processes and/or systems are changed?
  • What impact will there be on the workplace?

 

Approach to Developing this Section

Consider the system being proposed and the organization in the case study, and identify three issues that have not previously been discussed in the business case.  Consider the questions above, as needed, to assist in the analysis.

 

 

Week 8 Group Assignment:  Final business case, including Sections XIV & XV, and Executive Summary

  • Performance Measures

 

The purpose of this section is to let the decision-makers know how they can determine whether they are receiving the expected benefits from the system, beyond whether they are receiving the financial return on investment.  If the system proposed in the business case is approved and implemented, the organization will, at some point, need to assess whether it is receiving the expected benefits.  To assist in determining this, performance measures are used.  These measures refer to the impact the system is having on the business, not IT system performance measures used to determine how well the system itself is performing.  The performance measures are derived from the business problems and/or opportunities and the expected benefits documented in the business case.  The team should identify four performance measures related to the expected benefits and/or support the organization’s goals and objectives.

First, provide an introduction to this section.  Then list four performance measures and explain how the proposed system will enable or support the measure.

  1. Performance Measure #1 (use name of Problem or Expected Improvement as listed in the table below)
  2. Performance Measure #2 (use name of Problem or Expected Improvement as listed in the table below)
  3. Performance Measure #3 (use name of Problem or Expected Improvement as listed in the table below)
  4. Performance Measure #4 (use name of Problem or Expected Improvement as listed in the table below)

Finally, introduce the table below and include the completed table.

Performance Measures

Problem or Expected Improvement Metric – used to measure Source of Data Baseline Target Time-frame
           
           
           
           

 

 

Approach to Developing this Section

Review Sections II and IV, in particular, of the business case.  In Section II, the business problem(s) and/or opportunities were identified, and in Section IV the improvements/benefits to be realized from the proposed solution were identified.  Now select and quantify four improvements or benefits and determine how success can be demonstrated, once the solution is implemented.

For example, if one business problem is to increase the number of employees, and the proposed solution would contribute to increasing the number of employees, then the entries in this table would identify:

  • The problem – increase the number of employees
  • The metric – what “item” can be measured to determine if the number of employees are increasing (e.g., total number of employees)
  • The source of the data – information to be used to determine if the target has been met (e.g., number of employees on the payroll)
  • The baseline – what the source of the data reports for the current way of doing business, prior to system implementation (e.g., number of employees on the payroll before the system is implemented)
  • The target – that shows how much improvement over the baseline is expected (e.g., how much should the number of employees increase), and
  • The timeframe – timeframe (“immediately,” “six months after implementation,” etc.) by which the target should be attained (e.g., how long after system implementation the number of employees should reach the targeted improvement number).

 

The table must have an appropriate introduction to put it into context in the business case.  Each of the performance improvements listed should also be briefly explained to show how the system being proposed in the business case will actually impact in those areas.  So, for the example above, if the proposed system were a Supply Chain Management (SCM) system, then it should be explained how implementing an SCM and having a more complete inventory of goods would contribute to an increase in the number of employees.  (Note: Do not use the example, as it is not an effective performance measure for the Case Study.)

 

  1. Conclusion

 

This section concludes the business case and leaves the decision-maker with a clear understanding of the decision to be made.  It should be a clear and compelling call to action. Take the time to do this correctly.

Approach to Developing this Section

Read the article from the UMGC Library, in the Week 8 Content area to understand how the conclusion should be written.  Summarize the decision to be made and provide a rationale for moving ahead with the decision in a timely way.

 

In addition to the Conclusion, the Executive Summary is developed at the end of the business case process.  Both sections summarize the Business Case, but for different purposes and in different ways.  The Executive Summary is described above in that section.  The Conclusion simply provides the summarization and the expresses the decision to be made and why it should be made (and made soon).

 

The References page and Appendices are to be created, updated and submitted each week along with the sections of the business case through that week’s assignment.  A placeholder page for each should be created in Week 1 and then completed in the updated business case as appropriate.  For the Final Business Case, the Table of Contents entries should be hyperlinked to the appropriate section.  Pages should be numbered.

 

REFERENCES

List, in APA format, the references for all in-text citations.

 

APPENDICES

When included in the main body of the paper, large illustrations or tables can be distracting or cause the reader to “lose the flow” of the narrative.

As the tables and figures listed below are developed as part of the sections of the business case, they will be added to the appendix.  (Short tables will be included in the body of the business case.)  A brief overview of each of the following should be included in the body of the business case with a reference to the appropriate appendix item.  You may include other diagrams, illustrations or lengthy lists as additional appendices; they should be labeled and included in the order in which they are referred to in the main body of the paper.  At least these two must be included:

Appendix A   Context Diagram

Appendix B   Risk Matrix

 

Each item will have its own appendix.  Each appendix should start on a new page.  Appendices should be listed in the Table of Contents.   In the main text, you should refer to the Appendices by their labels (e.g., “Appendix A” (without the quotes)).