System Acquisition Final RFP

System Acquisition Final RFP

Dr. Rich Halstead-Nussloch

IT 6423

By: Cecil Davis, Bradley Shedd, Diana Rabah, Kelvin Davis, and Oluwabusuyi Ojo

Date: December 5, 2013

101 Letter of Transmittal?

Table of Contents

100 Cover Sheet 1

101 Letter of Transmittal 2

102 Table of Contents 2, 3, 4

103 Figures and Tables 4

104 Abstract 5

105 Mission Statement 5

106 Introduction 6

107 Background 7

108 Purpose 7

109 Scope 7

110 Organization 7

111 Proposed Solution 7

112 Buy vs. Build Rubric 7

113 Technologies Needed 7

114 Schedule Time Management 7

115 Cost 7

116 Risk Management 7

117 Responsibilities 7

118 Integration Requirements 7

119 Software Requirements 7

120 Hardware Requirements 7

121 Conclusion and Recommendation 8

300 CMMI Points 8

3.1 Acquisition – Cecil & Diana & Brad 8

3.2 Agreement Management (AM) - Cecil 8

3.3 Acquisition Requirements Development (ARD) – Brad & Diana 9

3.4 Acquisition Technical Management (ATM) - Brad 9

3.5 Acquisition Validation (AVAL) - Cecil & Diana & Brad 10

3.6 Acquisition Verification (AVER) – Cecil & Diana & Brad 10

3.7 Solicitation and Supplier Agreement Development (SSAD) - Brad 10

4.0 Process Management - Kelvin & Cecil & Diana & Brad 10

4.1 Organizational Innovation and Deployment (OID) - Diana 10

4.2 Organizational Process Definition (OPD) - Brad & Diana 10

4.3 Organizational Process Focus (OPF) - Cecil 10

4.4 Organizational Process Performance (OPP) - Cecil 10

4.5 Organizational Training (OT) – Kelvin & Cecil & Diana 10

5.0 Project Management - Kelvin & Cecil & Diana & Brad 10

5.1 Integrated Project Management (IPM) - Brad 11

5.2 Project Monitoring and Control (PMC) - Diana 11

3.4 Project Planning (PP) - Kelvin 11

3.5 Quantitative Project Management (QPM) - Brad 11

3.6 Requirements Management (REQM) - Kelvin & Cecil 11

3.7 Risk Management (RM) – Cecil & Diana 11

4.0 Support 11

4.1 Causal Analysis and Resolution (CAR) - Kelvin 11

4.2 Configuration Management (CM) - Kelvin 11

4.3 Decision Analysis and Resolution (DAR) - Brad 11

4.4 Measurement and Analysis (MA) - Brad 11

4.5 Process and Product Quality Assurance (PPQA) - Kelvin 11

Appendices 11

Annotated Bibliography 11

Bibliography 11

ABSTRACT

The competition is heating up with the modern restraints on the neighborhood streets bringing in more customers with their technologies

GUIDELINES:

105 Introduction

Introduction will go here for the final RFP

106 Mission Statement

Mission statement will be here. “The mission statement is to…”

107 Background

108 Purpose

109 Scope

Scope outlined here with time frame and budget

110 Organization

DISCUSSION SECTION

111 Proposed Solution

112 Buy vs. Build Rubric

113 Technologies Needed

114 Risk Management

Risk	Risk Level L/M/H	Likelihood of Event	Avoidance
	H:	Likely
	H: 10 days	Certainty
	L:	Certainty
	L: Low	Certainty
	L: Knowledgeable of user area only	Likely
	L: More than 75% accurate	Unlikely
	L: Scope generally defined, subject to revision	Unlikely
	L:	Unlikely

Figure 1.3 Risk chart

115 Cost

The following is our financial resources for the proposed research with shipping and handling added.

Item	Units	Rate	Cost
Software Cost	16	$3689.00	$3766.20
Labor	16	$25.00	$400.00
Extra Phones	2	$154.00	$308.00
		Total	$4474.20

Figure 1.6 Cost Table

116 Schedule Time Management

This is a schedule of the tasks we will complete for this project.

Task	Date of Tasks
Task 1:
Task 2
Task 3:
Task 4:
Task 5:
Task 6:

	13	14	15	16	17	20	21	22	23	24
	November

Figure 1.2 Gannt chart

117 Responsibilities

118 Integration Requirements

An Engineering process area at Maturity Level 3

The purpose of Requirements Development (RD) is to produce and analyze customer, product, and product-component requirements.

Specific Practices by Goal

The requirements stand out as the descriptions of what the technology teams have to build. Analyses occur recursively at successively more detailed layers of a product’s architecture until sufficient detail is available to enable detailed design, acquisition, and testing of the product to proceed including functionality, support, maintenance, and disposal, the manufacturing or production concept produces more derived requirements, including consideration of:

1. Constraints of various types

2. Technological limitations

3. Cost and cost drivers

4. Time constraints and schedule drivers

5. Risks [2]

119 Software Requirements Software requirements will be described in detail and then go here in bullet points….

120 Hardware Requirements

Hardware requirements will be descried and detail and then go here in bullet points….

· Hardware

· OS

· Installation guide

121 Conclusions and Recommendation

300 CMMI Points

310 Acquisition – Cecil & Diana & Brad

320 Agreement Management (AM) - Cecil

330 Acquisition Requirements Development (ARD) – Brad & Diana

340 Acquisition Technical Management (ATM) - Brad

350 Acquisition Validation (AVAL) - Cecil & Diana & Brad

360 Acquisition Verification (AVER) – Cecil & Diana & Brad

370 Solicitation and Supplier Agreement Development (SSAD) - Brad

400 Process Management - Kelvin & Cecil & Diana & Brad

410 Organizational Innovation and Deployment (OID) – Diana

A Process Management process area at Maturity Level 5

The purpose of Organizational Innovation and Deployment (OID) is to select and deploy incremental and innovative improvements that measurably improve the organization's processes and technologies. Pilots are conducted to evaluate significant changes involving untried, high-risk, or innovative improvements before they are broadly deployed based on the following criteria:

· Improved product quality (e.g., functionality, performance)

· Increased productivity

· Decreased cycle time

· Greater customer and end-user satisfaction

· Shorter development or production time to change functionality or add new features, or adapt to new technologies

· Reduce delivery time

· Reduce time to adapt to new technologies and business needs

· Estimated costs of deploying process and technology improvements, and the resources and funding available for such deployment. Change and stability must be balanced carefully.

420 Organizational Process Definition (OPD) - Brad & Diana

A Process Management process area at Maturity Level 3

The purpose of Organizational Process Definition +IPPD (OPD) is to establish and maintain a usable set of organizational process assets. I will not be using this process, its not related to the make vs. buy product decision-making process.

430 Organizational Process Focus (OPF) - Cecil

440 Organizational Process Performance (OPP) - Cecil

450 Organizational Training (OT) – Kelvin & Cecil & Diana

A Process area at Maturity Level 3

The purpose of Organizational Training (OT) is to develop the skills and knowledge of people so they can perform their roles effectively and efficiently. This process is very important to our business as training is a basic need for the business, we don’t want to acquire new products and not let the employee train on it and get to know the functionality of the product, so they use it to its maximum.

Specific Practices by Goal

1 Establish an Organizational Training Capability

1 Establish the Strategic Training Needs

2 Determine Which Training Needs Are the Responsibility of the Organization

3 Establish an Organizational Training Tactical Plan

4 Establish Training Capability

2 Provide Necessary Training

1 Deliver Training

2 Establish Training Records

3 Assess Training Effectiveness

500 Project Management - Kelvin & Cecil & Diana & Brad

510 Integrated Project Management (IPM) - Brad

520 Project Monitoring and Control (PMC) – Diana

A Project Management process area at Maturity Level 2

The purpose of Project Monitoring and Control (PMC) is to provide an understanding of the project's progress so that appropriate corrective actions can be taken when the project's performance deviates significantly from the plan. This process is crucial to our project. If we are buying the product, will make sure that we are looking at the requirements intended for use only, not to deviate from the plan and purchasing extra services that will cost more and of no added value to the business. This process is important for the project as a whole not only concentrated on the product to be acquired.

Specific Practices by Goal

1 Monitor Project Against Plan

1 Monitor Project Planning Parameters

2 Monitor Commitments

3 Monitor Project Risks

4 Monitor Data Management

5 Monitor Stakeholder Involvement

6 Conduct Progress Reviews

7 Conduct Milestone Reviews

2 Manage Corrective Action to Closure

1 Analyze Issues

2 Take Corrective Action

3 Manage Corrective Action

525 Product Integration

A Support process area at Maturity Level 5

The purpose of Product Integration (PI) is to assemble the product from the product components, ensure that the product, as integrated, functions properly, and deliver the product. Review the integration strategy with developers and test and integration teams to confirm its feasibility and revise as necessary. This process takes time and money. I won’t be using this process.

530 Project Planning (PP) - Kelvin

540 Quantitative Project Management (QPM) - Brad

560 Requirements Management (REQM) - Kelvin & Cecil

570 Risk Management (RM) – Cecil & Diana

600 Support

610 Causal Analysis and Resolution (CAR) - Kelvin

620 Configuration Management (CM) - Kelvin

630 Decision Analysis and Resolution (DAR) - Brad

640 Measurement and Analysis (MA) - Brad

650 Process and Product Quality Assurance (PPQA) - Diana & Kelvin

A Support process area at Maturity Level 2

The purpose of Process and Product Quality Assurance (PPQA) is to provide staff and management with objective insight into processes and associated work products. Delivery of high quality products through implementation of planned processes and handling non-compliance issues by providing feedbacks to project managers and staff on the results of quality assurance activities and ensuring that noncompliance issues are addressed. In today’s competitive times cost alone is not going to be a factor behind the success or failure of a product. It is going to be Product Quality. Another factor of cost if we decide to build in-house.

Specific Practices by Goal

1 Objectively Evaluate Processes and Work Products

1 Objectively Evaluate Processes

2 Objectively Evaluate Work Products and Services

2 Provide Objective Insight

1 Communicate and Ensure Resolution of Noncompliance Issues

2 Establish Records

Validation (VAL)

An Engineering process area at Maturity Level 3

The purpose of Validation (VAL) is to demonstrate that a product or product component fulfills its intended use when placed in its intended environment. It is very important to verify the usage of the product after we acquire or it we build it, is it fulfilling the business objective, is it working as the business needed it to work.

Specific Practices by Goal

1 Prepare for Validation

1 Select Products for Validation

2 Establish the Validation Environment

3 Establish Validation Procedures and Criteria

2 Validate Product or Product Components

1 Perform Validation

2 Analyze Validation Results.

Verification (VER)

An Engineering process area at Maturity Level 3

The purpose of Verification (VER) is to ensure that selected work products meet their specified requirements.

Specific Practices by Goal

1 Prepare for Verification

1 Select Work Products for Verification

2 Establish the Verification Environment

2 Verify Selected Work Products

1 Perform Verification

2 Analyze Verification Results

Conclusion:

It is much cheaper for us to buy the software of the shelf. The initial cost of software, hardware, setup, and training is less than the cost of the developing the system in-house. We are looking for a solution that saves us time, and automates the business. Several factors we can consider when buying: first make sure of the quality of the company that built the software and hardware.
2^nd Buying strictly on price: Make sure no hidden costs like missing features that would have saved time or money, technical support fees, or supplemental services you did not realize you would need and making sure these were included in the final cost.

3^rd, making sure to pick the sfw that has all features and requirements for the business included in it; features that could really help your business.

And finally, purchasing a service contract as part of the purchase and Paying for disaster recovery and data loss support.

Appendices

Annotated Bibliography

Bibliography

Diana:

1. (n.d.).CMMI-DEV 1.2 303/1102 - 31 sub articles. Retrieved from

http://chrguibert.free.fr/cmmi12/cmmi-dev/text/pa-oid.php

2 . http://hci-itil.com/CMMI/CMMI_processes/engineering_requirements_development.html

3. R Copyright ® 2007 by James R. Persse. e q u i r e m e n t s M a n a g e m e n t u n d e r C M M I. Retrieved from http://altairsol.com/linked/requirements_management_under_cmmi.pdf

4. (n.d.) CMMI, CMM, and Capability Maturity Model are registered in the U.S. Patent and Trademark Office. Retrieved from http://www.software-quality-assurance.org/cmmi-supplier-agreement-management.html#intro

5. (n.d.) CMMI, CMM, and Capability Maturity Model are registered in the U.S. Patent and Trademark Office. Retrieved from http://www.software-quality-assurance.org/cmmi-organizational-innovation-and-deployment.html#intro

6. http://www.tutorialspoint.com/cmmi/cmmi-process-areas.htm

7. Ryan. T (March.5.2012) 10 costliest pos restaurant buying mistakes. Retrieved from http://www.bngholdingsinc.com/03/the-10-costliest-pos-restaurant-system-buying-mistakes-business-owners-make/blog/

Brad:

Ahern, Dennis M., Aaron Clouse, and Richard Turner. CMMI Distilled: A Practical Introduction to Integrated Process Improvement. Boston: Addison-Wesley, 2004. Print.

Ahern, Dennis M. CMMI Scampi Distilled: Appraisals for Process Improvement. Upper Saddle River, NJ: Addison Wesley Professional, 2005. Print.

Dhan. "Case Study: How NOT to Manage a Project Team." Case Study: How NOT to Manage a Project Team. 14 Sept. 2012. Web. 10 Nov. 2013. <http://it.toolbox.com/blogs/musings-pm/case-study-how-not-to-manage-a-project-team-53020>.

Phillips, Mike. CMMI® for Acquisition (CMMI-ACQ) Primer, Version 1.3. Pittsburgh: Carnegie Mellon, Mar. 2011. PDF.

Homepage