Appendix A

DETAILED BUSINESS CASE EXAMPLE/TEMPLATE

Ministry of Information

Management Information System (MIS) Deployment Project

Process Owner
Project Manager	email	Phone
Zia Melendez	z.melendez@moi.cr	(305) 555-5785 ext. 101
Signature		Date
Executive Sponsor
Minister of Information	email	Phone
Professor Xavier Bardo	x.bardo@moi.cr	(305) 555-5783 ext. 100
Signature		Date

 

Section A: Stakeholders

A1 Stakeholders

Name/Title	Role	Contact Info (email)
Professor Xavier Bardo, minister of information	Project sponsor	x.bardo@moi.cr
Zia Melendez, assistant director	Project manager	z.melendez@moi.cr
Chris Voehl, business analyst	Business analyst	c.voehl@moi.cr
Henry McCoy, senior engineer	Technical advisory	h.mccoy@moi.cr
Victor Creed, systems support manager	SME	v.creed@moi.cr
Margie MacDonald, CPHP chief duty officer	End user/stakeholder	m.macdonald@moi.cr
Ororo Monroe, Key West County training coordinator	End user/stakeholder	o.monroe@moi.cr
Conch Republic Ministry of Information	Stakeholders
Additional state level, county and municipal agencies receiving connectivity, systems support and/or services via the Conch Republic Ministry of Information	End users

 

Section B: Executive Overview

A2 Description, Background, and Strategic Assessment

A2.1 Executive Summary

The legislature of the Conch Republic has directed the Ministry of Information, to implement a national Management Information System (MIS). This includes security administration, tracking of entering- price data and software application licensing. This project will fulfill the need to transition from the existing manual system to an automated system including a Management Information Systems MIS dashboard.

The project includes assembly of this business case to evaluate whether to:

1. Hire and retain resources to completely design, develop, and administer the new system, utilizing new hardware purchased separately.
2. Contract a vendor to design, develop, administer, and maintain the new system.
3. Procure and implement a vendor COTS (commercial off-the-shelf) solution.

Recommendation:

Option C is recommended, due to the following factors:

• Costs related to this recommendation are similar to those of the other two options—approximately $500,000 to purchase the software and $250,000 in maintenance fees.
• Benefits: Total cost of ownership (TCO) will be reduced by approximately $2,000,000 once the system is up and running. The benefit-cost ratio is about 2.5.
• Time to deploy is diminished with this option: Less than one year.

Key Determinates:

• Installing the system will save the government $2 million per year in manual process cost, real estate leasing, overhead, storage, recycling, and disposal fees.
• Leveraging internal resources to gather requirements and perform initial system specification and process design will save costs that will go toward implementation.
• Cycle time from the general public’s viewpoint will significantly reduce deadly depending on the particular activity. For example, the average time to get a building permit approved is six weeks. With the new system, it will be reduced down to an estimated eight working days.
• Customer satisfaction/net promoter scores will improve from 62% to 80% the first year.

Cost Benefit AnalysisBENEFITS (in cost savings)
Manual process cost reduction	$750,000
Overhead, real estate leasing, and paper storage savings	$1,000,000
Recycling/disposal fee reallocation	$250,000
Total BenefitsCOSTS	2,000,000
Commercial vendor deployment estimation	$500,000
Implementation support, training, deployment management	$250,000
Internal resource time and labor costs	$50,000
TOTAL COSTS	$800,000
Net Present Value (NPV)	$1,200,000
Benefit-Cost Ratio	2.5

 

A2.2 Scope

The Ministry of Information requires a system that will automate national Management Information System (MIS) data collection and storage. The scope includes security administration, tracking of enterprise data, software application licensing and creation of an MIS dashboard.

The primary components of The Conch Republic MIS are computer systems hardware and software; data required for executive and local level decision making; design, documentation, and deployment of processes and procedures; and a Human Resource Management System for individuals and organizations.

The implementation scope and technical implementation approach will be to implement high-priority and high-risk elements first, to best identify workable solutions for the majority of top priority requirements. We will collect specific, useful, actionable information to facilitate a recommendation for the acquisition of a national MIS.

Should a COTS solution be chosen, the scope of this project will include writing an RFP (request for proposal), establishing criteria for evaluating the request for proposal (RFP) responses, choosing the vendor, and facilitating the implementation of the solution.

The MIS will be implemented as a web/browser-based solution, either hosted externally or maintained on internal MIS servers. To ensure adequate backup and recovery, a data backup and restore process will be required and documented. Database(s) and reserves of confidential data will be encrypted for security. Additional application level security will be provided. It is anticipated that there will be thousands of end users across The Conch Republic.

After every six months of operation, the Ministry will reassess the usage and storage requirements, user satisfaction levels with the system, and recommend adjustments to ensure maintainability and usability of the program.

A2.3 Problem Statement

On January 1, 2013, the Conch Republic legislative body passed legislation requiring automation of manual/paper-based processes through about the various government agencies. Also, the current manual process has multiple opportunities for improvement, which implementation of the new system will address:

• New project approval may take 120+ days (worst-case scenario).
• 35% of approved projects fail to be completed, due to a lack of management visibility and effective resource allocation.
• The existing manual processes are paper intensive, which results in the excessive length of time, though only anecdotal data exists on the process’s cycle time.
• This results in reduced satisfaction levels and increased complaint calls to Congress.
• Finally, the existing manual testing process runs the risk of failing our stakeholders, resulting in a potential lawsuit and disenfranchisement/defections.

A3 Business Goals and Objectives

This project directly supports the strategic business goals and objectives specified in the MIS Strategic Plan 2012–2014 of Improving Performance of Key Processes by the establishment of a national MIS. Combined with the stakeholder requirement to automate manual/paper-based processes, the following business goals and objectives are the project drivers to ensure the continued success of the MIS implementation:

Business Goal/Objective	Description/Strategy
Goal 1: Improve stakeholder satisfaction	Key data will be gathered to calculate net promoter scores
Goal 2: Reduce costs	Cost containment analysis with all vendors to analyze preferred partner arrangements in exchange for cost reduction
Goal 3: Paperless by 2015	Reduce paper utilization, waste, and storage (file cabinets)
Goal 4: Improve visibility into key projects and processes	Establishment of a national MIS
Goal 5: Improve training and education	Improve workforce education, performance, and satisfaction
Goal 6: Improve process performance	Improve performance of key Ministry of Information processes through benchmarking, analysis, waste reduction, and metrics

 

A4 Project Objectives, Measures, and Outcomes

No.	Project Objectives	Measures /Outcomes
1.	Improved customer/stakeholder satisfaction	Net promoter scores > 90% Customer sat scores from 80% – > 90%
2.	Cycle time for project completion and new program development	Number of hours/days/weeks reduced (total cycle time reduction)
3.	Reduce costs	Cost savings in excess of 5% GDP
4.	Paperless processes	Reduce file cabinet/paper storage by 90%
5.	Automate key processes, including apply online for services, licensing, certification, and recertification	Number of systems automated Percentage of work automated Number of users trained
6.	Implement a working COTS solution	80% of the system functionality implemented by the go-live date of January 1, 2014

 

A5 Assumptions and Constraints

1. The executive branch supports the project.
2. The project schedule is well-detailed, and estimates are reasonable.
3. Appropriate stakeholders are identified and committed to participate in requirements-gathering interviews actively.
4. Ministry of Information, MIS deployment team staff have sufficient time to devote to project activities.
5. Project planning and analysis will address and identify potential solutions to implement.
6. IT resources will be available to the project on a consulting basis.
7. Sufficient funding is possible to complete the project.
8. The likely solution will include the vendor providing ongoing maintenance and support for the application.
9. The marketplace has vendors experienced in MIS national-level data collection systems.
10. The procurement process will not be protested.

Constraints

1. Limited availability of Ministry of Information staff/subject matter experts
2. Limited availability of IT staff
3. Limited availability of internal systems analysis and development resources
4. Though not anticipated, “scope creep” is a risk that must be managed on any project

A6 Proposed Technology Environment

A6.1 Proposed Software

Software Item	Description
COTS Package	To be provided by selected vendor/developer

 

A6.2 Proposed Hardware

Hardware Item	Description
Vendor or Ministry hosting	The Ministry will entertain either vendor-hosted or MIA-hosted solutions as long as they are consistent with the current department IT standards for security

A7 Requirements

Requirement Type	Requirement Description	Priority
	Reference Appendix B: Requirements Matrix

A8 Project Milestones/Schedule

	Milestone/Deliverable	Target Start Date	Target Completion Date
1.	Internal project initiation/scoping	Mon 6/03/13	Fri 6/28/13
2.	Elicit and document requirements	Mon 7/01/13	Fri 8/30/13
3.	Develop business case	Mon 7/29/13	Fri 8/30/13
4.	Create advertisements (RFP/ITN)	Mon 9/02/13	Mon 9/30/13
5.	Vendor contract acceptance	Tue 10/01/13	Thurs 10/31/13
6.	Vendor construction of MIS: Phase 1	Fri 11/01/13	Fri 6/13/14
7.	Testing, defect/issue reporting, resolution	Thu 1/01/14	Fri 6/13/14
8.	Change management, training, and communication	Mon 5/26/14	Fri 7/11/14
9.	System deployed	Tue 7/01/14	Fri 7/25/14
10.	Formal acceptance/celebration	Mon 7/28/14	Thu 7/31/14

Section C: Proposal Evaluation

A9 Benefits

This business case, developed by the Ministry of Information, MIS deployment team, supports the Conch Republic Mission: To promote the participation of all people in the Conch Republic.

Cost-Benefit Analysis

BENEFITS (in cost-savings)

Manual process cost	$750,000
Overhead and storage	$1,000,000
Recycling/disposal	$250,000
TOTAL BENEFITS	2,000,000

COSTS

Commercial vendor deployment estimation	$500,000
Implementation support, training, deployment management	$250,000
Internal Resource Time and Labor Costs	$50,000

TOTAL COSTS                                                                                                  $800,000

Benefit-Cost Ratio                                                                                                     2.5

Also, intangible benefits resulting from the primary outcomes of the MIS Deployment project, which will enable the transition to the new MIS System, are as follows:

• Automate the import of applications from local agencies to sup- timely port processing, improve data quality, and reduce the overall cycle time.
• Communicate with end users to ensure they are informed about changes that may impact them, how to proceed, and where to go if questions arise.
• Train project stakeholders in the new system by inviting them to participate in guided user acceptance testing sessions.
• Provide appropriate means to ensure the project stakeholders convey instructions to the remaining user population and can answer any questions that may arise.

A10 Federal Mandate Impact on Solution Selection

The Conch Republic will be the first micronation to mandate automated paperless government processes. Any system implemented must have a minimum shelf life of 10 years. This excludes unanticipated changes in global information management standards, and any regular maintenance activities necessary to maintain the system, such as vendor COTS upgrades, which may necessitate the corresponding database, operating system, or hardware upgrades.

A11 Impact Analysis

Minimal Internal Impact: By contracting a project manager and an analyst dedicated to this initiative, limited use of IT resources will be required for consultation during solicitation and procurement activities.

Positive Stakeholder Impact(s): Once the new system is in place, it will benefit both internal and external customer, as well as community and regulatory stakeholders, by introducing efficiencies in automating currently manual processes, while improving the speed of service delivery and reporting.

A12 Funding

Funding Source	Amount
Federal budget	$750,000
Cost Estimates	Amount
Commercial vendor deployment estimation	$500,000
Implementation support, training, deployment management	$250,000
TOTAL	$750,000

A13 Alternatives Analysis

The Ministry conducted an analysis that resulted in the decision to move forward with a proposed buy solution.

The proposed technical solution is the implementation of a COTS pack- an age that will provide an automated means of collecting, storing, and present data, validating the data, generating error and compliance reports to be sent to key stakeholders, and facilitating the timely completion of processes and projects.

Hosting by vendors or the Ministry are acceptable proposed solutions. Three primary options were considered and described below. Maintaining the current legacy system “as-is” and failing to keep compliance were not regarded as viable alternatives and were exempted from the analysis.

Alternative 1

Procure COTS system from a vendor: Hosted with the vendor

Alternative 2

Develop a new in-house application by hiring and retaining resources for the design, deployment, and administration of the Management Information System.

Alternative 3

Develop a new in-house application with resources utilizing contract services.

 

Determining factors include their view of other states implementation experiences, RFP vendor responses, and costs that showed the level of functionality available on the market for a low price as well as the increased amount of time and money it would take internal resources to match that functionality.

The precedent exists for the procurement of a COTS system from a vendor, which we recommend being presented for approval.

A14 Risk Analysis

Where project risks have been identified, a Risk Priority Number (RPN

1) has been calculated based on the potential for occurrence, severity, and current prevention controls. A summary of the selected risk mitigation strategies and resulting RPN recalculation (RPN 2) are listed below.

In summary, some steps have already been taken to mitigate the risks identified. If the remaining recommended risk prevention strategies listed below are followed, project risk should be significantly reduced. Jointly participating in and monitoring project performance is the only way to effectively mitigate risks during the software development lifecycle (SDLC).

No.	Risk	Initial RPN 1	Prevention/Mitigation	Projected RPN 2
1.	Availability of continued funding	Medium 120/1000	Ensure processes and procedures are followed for timely collection of revenue.	Low 60/1000
2.	Project completion target dates not achieved	High 392/1000	If the project milestones/ timeline are approved by management to ensure realistic baselines, risk will be significantly reduced.	Med-Low 96/1000
3.	Requirements gathered are incorrect	High 392/1000	Validate requirements to ensure correct/complete.	Med-Low 96/1000
4.	Some requirements are identified as high risk (payment, automation)	High 200/1000	Technical implementation approach will be to implement high-priority and high-risk elements first to adjust early (if required) for the majority of top priority requirements.	Med-Low 90/1000
5.	Scope-creep (changes) during development	High 200/1000	Prioritize and negotiate necessary requirement changes. Allocate resources or schedule for Phase 2 or a later release.	Low 45/1000
6.	Components not tested, causing user-facing errors	High 160/1000	Utilize requisite pro Use Cases Traced to Features Report.Create scenarios traceable to Test Cases to manage the testing process.	Low 32/1000

 

No.	Risk	Initial RPN 1	Prevention/Mitigation	Projected RPN 2
7.	Tested components do not function in conformance with requirements	High 140/1000	Establish regular Agile style review, tuning, and testing of vendor developed components. Automated testing (if possible) would further increase testing replication and accuracy, leading to reduced risk.	Medium 90/1000
8.	Unacceptable vendor performance	High 180/1000	Regular Agile iterations’ review and testing of COTS (vendor developed) components will quickly red flag any issues early on in the development cycle, instituting corrective action process improvement plan.	Med-Low 81/1000
9.	End user/ stakeholder dissatisfaction with the final product	Medium 112/1000	Proactive change management practices including end-user training, communication, and feedback should mitigate this risk. Providing opportunities to elicit feedback during user acceptance testing (UAT), and providing options for postdeployment system help and support, provide further safeguards.	Low 54/1000

 

A15 Technical Requirement Questionnaire

The business case development team provides the following answers to questions that the executive review committee might have.

Question	Y/N or Number	Describe
Will this application be implemented on Ministry of Information servers?	N	Vendor hosted or hosted at the data center
Is there a specific technology or database platform required?	Y	Windows 2010 SQL server®
Will this application be used by people outside of your specific office?	Y	Ministry of Information, and local agency end users

 

Question	Y/N or Number	Describe
Will this application be available to external users? How many users?	Y	Local agency end users, numbering upward of 5,000
Will your office provide programming resources to develop this application?	N
Will your office provide resources to support the development and implementation?	Y	A contracted business analyst and a systems administrator will be supporting the solution
Will your office provide programming and infrastructure resources to support this after it moves into production?	N	One FTE (full-time employee) will support the solution in an administrative capacity
Will your office be providing training to all end users of this application?	Y	Supplemented by vendor
Will this application interface with other applications?	N
How many total users will this application have?	TBD	Est. 5,000+
Will this application have multiple security roles (e.g., administrator, user, view only)?	Y	Describe the individual user roles
Will this application contain financial or confidential data?	Y	Both financial and confidential data
Are there any Legislative mandates for the implementation of this application?	Y	Federal Statute 101.23— Technology cost containment
Are maintenance and support costs for this application fully funded?	Y	Tourism taxes

A16 Definitions

Term	Description
TCR	The Conch Republic
MIA	Ministry of Information
COTS	Commercial off-the-shelf/vendor software application
FMEA	Failure mode and effects analysis; for design projects use DFMEA
RPN	Risk priority number (as severity × occurrence × detection)
FTE	Full-time equivalent

 

Term	Description
SDLC	Software development life cycle
Stakeholder requirement (STRQ)	Elicits inputs from relevant stakeholders (including state statutes, executives, and end users) and traces the input down to system requirements
Functional requirement (FEAT)	Describes features of the system. e.g., “users shall login to the system via a web portal interface”
Nonfunctional requirement (SUPL)	Supplemental constraints that define the scope of the solution, e.g., security, performance, availability, usability
Use case (UC)	Describes the end users as actors, performing actions in the system to reach a goal; the use cases document a fully detailed scenario for the requirements
Scenario (SC)	Scenarios extend use case alternative paths, and form the bases of (and are traceable to) test cases
SLA	Service-level agreement

Section D: Process, Requirements, and Change Management

The following individual appendices are included:

Section 17: Process Map/Process Design Model: Desired future state (proposed)

Chapter 18: Requirements matrix

Article 19: Build/buy decision methodology Section 20: Change management

A17 Process Map: Desired Future State (Proposed)

The “swim lane” process map depicts the proposed redesign of the license renewal process automation (Figure A1.1).

A18 Requirements Matrix

The following table presents the practical and supplemental requirements for the primary system objectives.

FIGURE A1.1

The “swim-lane” process map depicts the proposed redesign of the License Renewal process automation.

Requirement Category/Type	Description	Priority1 = Critical 2 = Important 3 = Useful
Functional Requirements
Feature	FEAT1: Applicant Account CreationThe applicant shall navigate to the website and choose the option to create an account. The system shall validate that an account does not already exist. The applicant shall enter his/her first name, middle name (if applicable), and last name; date of birth, email address, mailing address, and phone number, create a user name, choose a security question(s), and provide answers.	1 = Critical
Feature	FEAT2: New Account VerificationOn “save,” the system shall verify all required fields have been filled out.	1 = Critical

 

 

Requirement Category/Type	Description	Priority1 = Critical 2 = Important 3 = Useful
Feature	FEAT3: Required Field CompletionWhen all fields are complete (and the user clicks save), the system shall display a message confirming successful account creation. A temporary password will be sent to the email address they entered.	1 = Critical
Feature	FEAT4: New Program Application Applicants apply for new project approval by accessing the system and entering a newapplication, including the agency name, address, city, state, zip code, phone number, and email address.	1 = Critical
Feature	FEAT5: Program Application ValidationThe system shall validate that required fields have been addressed before the application can be submitted by applicant. Applicants have the opportunity to enter corrections or later reapply.	2 = Important
Project PMO Application
Feature	FEAT6: Project Application Request (PAR) The user shall create a new project application request (PAR), by providing request type, date,projected completion date, esignature, and signify if the project meets federal funding requirements. An existing applicant can be tied to the request, or a new one can be created by choosing the Create New Applicant option.	1 = Critical
Feature	Feat7: Request TypeThe request type field shall include the following options: public works project, infrastructure improvement project, environmental assessment, system enhancement, new release/upgrade, new system deployment.	1 = Critical
Feature	FEAT8: Individual Request for Information ApplicationThe applicant shall complete their individual request for information application by supplying the following: last name, first name, middle initial, mailing address, city, state code, zip code, area code, phone number, extension, email address, certification (checkbox) the applicant is a legal resident of the Conch Republic.	1 = Critical

 

Requirement Category/Type	Description	Priority1 = Critical 2 = Important 3 = Useful
Feature	FEAT9: Data ManagementThe system shall automate the existing data collection, management and reporting processes. The data shall be made available via browser based interface/dashboard, and provide for basic usage and compliance reporting.	2 = Important
Feature	FEAT10: Data Dashboard AdministrationA data dashboard administration module shall be available for authorized administrators to assess the validity, reliability, and accuracy of the data, configure data import queries, and the dashboard graphs, charts, and reports as required.	2 = Important
Supplemental (Nonfunctional) Requirements
Type	Description	Stakeholder Priority
Security	SUPL1: SecurityPersonal information such as credit card, date of birth (DOB) and Social Security number (SSN) shall be protected via transport layer security (TLS) to provide HTTPS data encryption.	Critical
Reliability	SUPL2: ReliabilitySystem downtime shall be minimized to an agreed upon maintenance window. System uptime during regular (nonmaintenance) hours shall meet or exceed 99.9%.	Critical
Usability	SUPL3: UsabilityThe system shall support stakeholder requirements to achieve specified goals with effectiveness, efficiency, and satisfaction, within specified context and use cases.	Important
Performance	SUPL4: PerformancePerformance characteristics, including availability, response time, and peak throughput, shall be validated against the following characteristics: scale, meter/metric, target, constraint/LCL, benchmark.	Critical
Implementation	SUPL5: Data ValidationThe system shall automate the collection and/or import of local agency applications to support timely processing, improve data quality, and secure data.	Critical

 

Type	Description	Stakeholder Priority
Implementation	SUPL6: Business Rule ValidationThe system shall provide the ability to administratively configure/modify state–specified business rules for validation of submitted data.	Important
Implementation	SUPL7: Automated NotificationThe system shall provide the ability to configure specific communication-triggered events, such as a data submission validation error or timeliness of submissions.	Important
Physical	SUPL8: Data ManagementThe system shall maintain transaction based database of MIS data.	Important
Interface	SUPL9: Data Export/ExchangeThe system shall facilitate automation of the export of data.	Critical
Manageability	SUPL10: ReportingThe system shall provide the ability to generate reports based upon user-configurable report criteria.	Important
Usability	SUPL11: Change ManagementThe system shall feature online help functionality and basic end-user training, via system–guided tutorials and/or job aids.	Critical
Implementation	SUPL12: Release ManagementThe system shall be developed in modules that are released iteratively to allow for concurrent construction, initial deployment of Phase 1 priorities, end-user acceptance testing (UAT), and future releases.	Critical
Supportability	SUPL13: Service Level Agreement and MaintenanceA standard service level agreement shall be developed to specify components and metrics for standard SLA management and reporting. A maintenance window shall be established to minimize unscheduled downtime.	Critical
Supportability	SUPL14: Risk ManagementThe system shall have policies in place for security, preventively routing Internet traffic, load balancing, data backup, storage, and disaster recovery.	Critical

 

A19 Build versus Buy Decision Methodology

The Ministry of Information analyzed whether to build or buy a solution. The Ministry defined a structured decision- making a process that took into account the nature of the organization, the operations under consideration, the technology environment, and the state of packaged solutions and their vendors. The analysis yielded sufficient information to allow the Ministry staff to make an informed decision as to the appropriateness of a “build versus buy” solution for the requirements. The build/buy assessment methodology utilized to determine the feasibility of a build versus buy approach consisted of the evaluation of several categories of consideration. They are described as follows:

Business Considerations:

• Reduced risk
• Reduced cost
• Reduced time to implement
• Reduced support requirements

Functional Considerations:

• Percentage of functional fit
• Maintainability
• Compatibility with existing equipment (Windows PC environment)
• Compatibility with existing systems (for conversion purposes)
• Additional architectural/technical considerations
• Compatibility with local, federal, and international standards

Each category was weighted, evaluated by the project team by specific questions, and scored to determine the appropriateness of the build versus buy of this solution. An RFP was presented with vendor information regarding functional fit, cost, and implementation schedule considerations as well as analysis of other similar federal systems implementation projects.

Scoring indicated a firm buy decision. This analysis resulted in the decision to move forward with a proposal to seek vendors of commercial off-the-shelf software (COTS). Determining factors included:

• Review of other failed national MIS implementation experiences, RFP vendor responses, and costs.
• This showed the level of functionality available on the market for a low price versus the value of time and money it would take the Ministry of Information resources to match that functionality.

A20 Change Management

The approach to change management being adopted by the Ministry of Education is to reach the constituents, stakeholders, and end users being impacted by the change, via a variety of media.

Communication

Email, face-to-face, memos, and video messages will set the stage for change. The process of communication will depend on the demographic, and level within the organization. In many cases, key stakeholders will receive change management communications from a variety of channels. For example, senior staff will receive high-level briefings, a team not likely to be impacted by the change will get an email, and those in the direct line of change will accept all forms of communication and go through training and receive job aids to enhance their access to real-time how-to information.

Training and Job Aids

Adults learn in a variety of methods and need to be reached accordingly if real change is to take hold.

1. Some are auditory learners and will review guided learning sessions with a prerecorded video outlining the key components of program changes. Conferences will be held to explain the diversity.
2. Some are visual learners and will benefit from mixed media PowerPoint presentations and videos.
3. Some are kinesthetic learners, who benefit from hands-on interaction with new systems, on-the-job training, and classroom-based training.

Regardless of the media or channel, training on the new MIS will be in direct alignment with individual performance management plans.

A21 Performance Management and Measures of Performance

For real change to take hold within organizations, individual performance development profiles (IDPs) are established by Human Resources, which align with departmental objectives, which in turn align with organizational vision, mission, and objectives. Measures of performance will be determined by aligning project goals with expected behaviors. Key input, in-process, and outcome performance indicators (KPIs) will be collected to validate performance versus program and individual performance goals.

Obstacles to Change—There are two primary obstacles to change that the BCD team is trying to overcome, by instituting comprehensive change management methods and practices within the organization:

1. The first obstacle is a cultural resistance to change.To overcome this, people must be provided with enough information to gain an understanding of why the change is needed. We will communicate with employees, stakeholders, and constituents in a meaningful way by reaching out to them through a variety of media—communications via email, face-to-face, memos, video messages, etc.
2. The second is limited resources.To overcome this ever-present resource limitation, the goal is to redistribute resources toward high yield projects, by reallocating funds from supply drains—those “dead” or dying projects that were either stalled or so significantly behind schedule their chances of successful implementation were virtually nil.

The BCD team developed the following change management action plan:

1. Plan the details of the changes, in alignment with this business case and change management action plan. Incorporate this into the project plan if possible.
2. Communicate why the change must happen, via text blast announcements, email, and video messages targeted to key stakeholders.
3. Assess the impact of the change on those who will be most affected. Perform a detailed risk assessment of processes, tasks, and activities targeted for elimination or automation.
4. Communicate the training requirements through Learning Management Systems (LMS). Test for understanding using the LMS if possible to also track competency and comprehension with the changes being communicated and training modules.
5. Perform targeted follow-up communications and distribute job aids to people that include an overview of the purpose of the amendment, a snapshot of the desired future state, step-by-step directions on how to reach a goal within the new system, and tailor this so every- one knows—based on their role—how to do their part to facilitate successful transition to the new system(s).
6. Audit for compliance during the development and continue collecting data on the project and process goals and performance measures previously established. Provide real-time performance metrics so the organization and its leaders can adapt and provide real-time guidance of the change initiative(s). The auditing and monitoring can be scaled back or discontinued, once the implementation of the business case and its associated project is complete.
7. Plan for nonmonetary recognition and rewards for meeting or exceeding performance expectations and schedule a formal celebration to communicate the attention and results.

REVISION HISTORY

Version	Description	Date	Updated by:
1.0	Business case DRAFT, project overview	8/28/12	C. Voehl
1.5	Proposal evaluation, risk analysis	9/05/12	C. Voehl
2.0	Should-be (proposed) process maps completed	9/11/12	C. Voehl
2.5	Requirements extract from requisite pro	9/11/12	C. Voehl
3.0	Requirements validation (exemptions)	9/18/12	C. Voehl
3.5	Requirements validation and changes	10/01/12	Z. Melendez
3.6	Training program as-is map updates	10/04/12	C. Voehl
4.0	Requirements validation and changes	10/08/12	C. Voehl
4.1	Timeline updates for project meeting	10/11/12	C. Voehl
5.0	Updates to requirements and process maps	10/18/12	C. Voehl
5.5	Timeline extension, data updates	11/09/12	Z. Melendez
6.0	Requirements validation and changes	11/28/12	Z. Melendez

 

Title TBD

Version	Description	Date	Updated by:
6.5	Scheduling requirement added	12/03/12	C. Voehl
7.0	Individual certification process maps updated	12/07/12	C. Voehl
8.0	Changed obsolete references	2/15/13	C. Voehl
9.0	New requirements for implementation	2/21/13	C. Voehl
10.0	Added nonfunctional performance requirements	3/14/13	C. Voehl
10.5	Updated project schedule/timeline	4/02/13	C. Voehl
10.7	Updated technical requirement questionnaire; definitions, funding; alternatives, risk analysis	4/10/13	C. Voehl
11.0	Rewrote, reformatted exported SUPL requirements; added Functional Requirement section headings	4/24/13	C. Voehl
12.0	Formatted business case template for reuse	4/30/13	C. Voehl
12.5	Updated outdated references	5/13/13	C. Voehl
13.0	Updated executive overview	5/30/13	C. Voehl
13.5	Revisions based on executive review	6/06/13	C. Voehl
14.0	Updated impact analysis	6/08/13	C. Voehl
14.5	Updated change management action plan	6/09/13	C. Voehl
15.0	Updated table of contents; finalized document	1/25/14	C. Voehl