IT Company Tenders Proposal

1.     Introduction and Background

The Gothaer Insurance Group is a German insurance company was founded in 1820 and originally began operation as a fire insurance bank and mutual insurance company (Gotz et al. 2018). Over the many decades to come the company expanded to create many subsidiaries ranging across the insurance sector. In the 21^st century the group was growing rapidly; they formed the company Gothaer Systems, which allowed the group to expand into the IT sector and have their own telecommunications service provider in-house. In 2015, the Gothaer Group started the GoSMART program that works to combine commercial customer business with the requirements of digitalization by building and integrating a system that allows for the management of insurance products and policies throughout their life-cycle (Gotz et al. 2018). Gothaer is currently using the services of an external company called Alpha Systems as well as their own in-house solutions to work on the GoSMART program.

Gothaer Commercial (GCOM) and its policy system must be integrated with the organization’s existing systems, including what is being provided by the organization’s long-term IT service provider. The proposed solution is to engage an external company with SCRUM expertise to assist with development and implementation of the GCOM project and, more importantly, to develop internal expertise for long-term benefits through a real project. The purpose of this Request for Proposal document is to look for potential IT company tenders for the GCOM project with substantial agile software development experience (specifically SCRUM) to help assist in this methodology changeover.

2.     General Information

Vendors are expected to follow specific details outlined within this document when submitting their response to this RFP. When submitting all parties need to follow the required format when submitting the reply to the Request For Proposal. These replies also need to be submitted using email and in the form of an attached PDF document with specific format abided by. More details regarding the submission process can be found in Section 2.1 below. Any questions can also be submitted using email after the acceptance date which can be located below in Section 2.2. These questions do not need to be placed into a separate PDF file but instead can just be issued over email exchange using appropriate formatting. My personal details and all contact information can be found further in the report in Section 2.3

The policy system integration, development changeover and agile training is planned to be completed within 12 months of the contract signed with the successful vendor. All potential vendors are required to respond to the Request For Proposal and submit their proposal within 2 weeks of this request being sent out and publicly available. All questions relating to any of the contents within this request will need to be asked within 4 weeks after the request release, more details can be seen in the schedule, Section 2.2.

A single vendor will be chosen from the proposals, to which a contract will be signed with the successful vendor. This vendor upon being chosen as the successful applicant, will be notified within 3 business days towards the end of the schedule (Section 2.2). The Term of Contract will start effective immediately once the vendor has been informed. Shortly following this phase, the Term of Contract will commence which will complete the associated forms and the vendor will be approved and presented with payment of their expected costs to begin system development and integration. This will also include business meetings, training sessions and any included layover costs associated with resource allocation. It is expected for the beginning phase that a sample test demo, or mockup simulation of the policy system should be ready for presentation within the first month of the project. After this a useable test policy system should be ready before the 3^rd month has elapsed since the beginning of the contract for use as a standalone system (not needed yet for existing system integration). If the standalone policy system is useable during this time there will be available time to begin system and user testing, by performing black/white box testing and deploying user test tasks. Once 9 months since the contract started has elapsed, the policy system and all deliverables associated with the system is expected to be in its final stages of completion. During the months before and surrounding these periods, existing staff are expected to be training in agile software development and changing their processes where seen fit. Time will be allocated accordingly during these periods but is to be a second priority after the policy system development. After 11 months have elapsed, the policy system should be completely integrated into the existing system and after successful testing and bug fixing, presentations and meetings will be held to discuss deliverables met, the requirements outlined and basic performance standards. During this time if all requirements are met to great satisfaction, then additional incentives and payments may be provided to the successful vendor.

The successful vendor will be selected using a rating system defined by specific criteria when discussing proposals received. These same criteria will be used for all proposals sent in by all potential vendors, these criteria can be classed as follows:

The vendor will be selected based on:

• How efficiently they meet and respond to the selection requirements outlined in this request.
• How well they propose their costs in comparison to the available budget outlined for the project.
• The requirements met when allocating for that cost.
• Locality and industry expertise (the vendor will need to be present locally and not have their only offices overseas).
• Their acceptance and agreement to the Terms and Conditions (Section 2.4).

2.1  Instructions for Reponses

The due date for vendor responses to the Request for Proposal is 6pm AEST (Australian Eastern Standard Time)on Thursday 4^th October 2019. More details of the schedule and timeframes can be found below in Section 2.2. Vendors must respond by providing an electronic copy of their responses along with an additional paper copy sent to the company’s office address, more details can be found in Section 2.3 of this document. Vendors are required to ensure electronic copies are consist in format and submitted in PDF format with each section clearly outlined in a similar fashion to this document.

They are also expected to adhere to the following when submitting their response:

• Respond to each section identified in this document as requesting an answer from the vendor (including statements)
• Indicate your company’s approval of each item outlined
• Indicate any changes your company proposes
• Follow the number scheme used in this Request For Proposal when preparing your responses

2.2  Schedule

Schedule for RFP Process:
Event	Start Date	End Date
Company issues RFP	N/A	07/08/2019
Company accepts vendor questions	30/08/2019	27/09/2019
Company responds to vendor questions	Each Friday beginning 06/09/2019	6pm AEST 28/09/2019
Vendor proposals received by company	N/A	6pm AEST 04/10/2019
Company evaluates vendor proposals	05/10/2019	09/10/2019
Company announces short list (maximum of five)	N/A	4pm AEST 14/10/2019
Company schedules vendor in-person presentations	N/A	15/10/2019
Company checks short list vendor references	15/10/2019	18/10/2019
Short list vendors present their products	21/10/2019	25/10/2019
Company evaluates presentations	25/10/2019	30/10/2019
Company announces finalists	N/A	3pm AEST 30/10/2019
Company conducts site visits to finalists’ references	04/11/2019	05/11/2019
Company schedules custom demos	06/11/2019	08/11/2019
Finalist vendors conduct custom demos	11/11/2019	12/11/2019
Company and finalist vendors negotiate contracts	13/11/2019	15/11/2019
Company signs contract with one vendor	N/A	22/11/2019

(Tayntor 2002, p. 53)

The timeframe from issuing the Request For Proposal to finalizing a contract with a vendor is expected to take a maximum of 3 months. Questions will be opened for potential vendors after the first week since the request has been sent out, and then lasting for a further 4 weeks. Vendors are expected to prepare demos shortly after being short listed. Once meetings and presentations are completed the short-listed vendors will be evaluated and a final vendor will be chosen before the end of November 2019.

2.3  Inquiries and Contacts

All points of contact are to be made to myself, Joe Freya, between 9am – 6pm during working business days. Please use any of the contact methods below.

Phone:	04 1234 1234
Email:	joe.freya@gothaer.com
Contact Address:	Gothaer Allee 1, Cologne, GERMANY 50969

I will be the only contact during this process for vendor questions and responses. Questions submitted in regard to the Request For Proposal, the proposal itself, as well as information regarding the project processes outlined, including submitting the application for the project can also be directed towards myself. Myself (project lead), along with a small board of selected project managers will be the ones who decide on the successful applicant. Please note that the time period for questions to be accepted is 30^th August to 27^th September 2019. I will be responding to questions on a weekly basis by 6pm at the end of every Friday starting 6^th August and finishing after 3 weeks on the 28^th August.

2.4  Vendor Selection Criteria

Vendor expense: Gothaer will not reimburse the vendor for any expenses incurred in the preparation of the Request For Proposal and subsequent negotiations.

Company Right Reserved: Gothaer (the company):

• May discontinue the Request For Proposal process without selecting a vendor
• Is not obligated to select the lowest cost proposal
• May negotiate with more than one vendor concurrently
• May request additional information from any vendor
• May negotiate a contract based on terms and conditions other than those proposed by the vendor
• Will not provide reasons for rejection of any vendor

Nondisclosure and publicity: The vendor may not disclose any company information that it receives during the Request For Proposal process, not may it publicize that fact that it has received an Request For Proposal from the company.

Limitations of company liability: Gothaer has no financial liability to the vendor and that issuing the Request For Proposal does not in any way obligate the company to select a vendor or sign a contract.

I, Joe Freya, as the project lead and request contact, hold the following rights:

• To withdraw this Request For Proposal before a vendor is selected
• To request further information from potential vendors
• To refuse contract negotiations based on the vendor’s requirements
• To NOT provide a reason as to why a vendor was not chosen for the project
• To dispute the end result provided by the vendor if requirements and deliverables are not met

3.     Vendor Profile

Please provide information as accurately as possible when answering the questions below so we can better understand the operation and working practices of your business.

General Vendor Questionnaire:
QUESTION:	ANSWER:
Can you briefly outline your company’s current financial status?
What are your current total revenues in regard to system software projects within the past financial year?
What is the total staff count for your current employee base? Are these employees available for this particular project?
Of these staff how many are allocated to software development and support?
How long has your company been involved in the software development business?
How long and what percentage of the company’s staff has experience in the field of agile SCRUM methodology?
What are some previous highly successfully projects your company has created of been involved with? Can you provide references to these projects?
Why do you believe your company should be selected when compared against others?
Indicate what your company believes differentiates your company from other software vendors.

Commercial Vendor Assessment Questionnaire:
QUESTION:	ANSWER:
What version of software are you currently selling?
When was the initial version of this package first implemented?
When was the current version of this package first implemented?
How many developers are working on this package?
How many customers have this package installed and in full production?
How often do you release new versions of the software?
What is the warranty period for the software?
What support is included in the purchase price?
What other services do you provide?
What hours or days is help desk support available?

OPTIONAL: If your company operates in multiple countries and has employees working in various countries please answer the questions below, otherwise you are not required to fill out this qustionnaire.

Multinational Vendor Questionnaire:
QUESTION:	ANSWER:
In what countries does your company operate?
What is your total staff in each of those countries?
What number of employees would be available to work on the company’s account?

Include below these questionnaires the answers to the following questions regarding your customer profiles and details:

• Include a list of customer references
• An indication of the company’s market share in your industry field
• Methods in which your company assesses customer satisfaction and the results of those assessments

4.     Term

The time for the policy system to be integrated with existing systems and for staff to be trained in agile software development is 12 months. When the successful vendor has been selected, notified and contract signed this term will begin effective immediately. All vendors need to take note that some contract extensions can be granted, however depending on the situation and details surrounding the extensions, certain penalties will be enforced if they significantly break the terms and conditions outlined.

If your company wishes to make amendments the above term details, you are allowed to do so. Please indicate in this section if you agree with the above stated term, or if you wish to make changes, indicate your proposed term.

5.     Termination

During this project timeframe there may be a need for a termination of contract between the company and the chosen vendor. If this occurs, there will be an agreement put into place between myself and this specific vendor. This agreement will ensure that certain actions are put into place to make the termination process as simple and as smooth as possible. During this time there will be meetings held about the current and future plans of the project going forward between both parties involved. A termination notice period will be put into place if this occurs to which the vendor will need to negotiate with myself and the company alternative solutions for future project processes. All vendors need to be aware that there will be possible consequences for unexpected contract termination which will largely be dependent on the reasons behind the termination. Possible termination causes are, either one of the parties involved breaches the terms and conditions of the contract OR neither party of the contract is at fault, but both parties agree on a termination of contract due to external factors that favor convince. If a termination of contract is to occur, further details and standard protocols will be put forward during the termination notice period.

6.     Specific Project Requirements

The most important stakeholders for the project will be the end users of the policy system, myself as the GCOM project manager, and the selected vendor as the software integrator and agile development trainer. It’s important that the vendor keep these stakeholders in mind when developing the system and meeting with existing staff or using existing system applications.

I would like the policy system to include the following features:

• Protected and secure data stored within the policy system
• The system will be able to operate on desktop computers using the 3 main operating systems (Windows, MacOS, Linux)
• The design of the policy system needs to be visually appealing but not complicated so that it impacts usability
• The system content must heavily populated with policy information relating to the business practices of the company. Policies and associated details should be easily accessible by agents and users
• A complex but elegant database to store information
• Setup a privacy policy and user manuals for the system. These manuals and instructions must be obtainable by the lead managers of the project so that they can create and/or manage changes themselves as deemed necessary
• Provide a manual for the system that contains information on how the policy system functions. This will include maintenance of the system itself, updating contents within the system, navigation of the system layout and any specific hosting services that may be included in the process, this may also involve technical support assistance

Below includes a list of Technical Requirements for the project:

• The policy system will be built primarily for desktop PC (Windows, MacOS, Linux) usage (mobile or tablet support does not need to be included during this stage of the project)
• A database will be needed to be created and hosted to accompany the policy system
• Data and information stored in the database needs to be protected and stored securely with administrative rights granted for specific staff able to access the back-end software
• Malware safe guards will need to be activated and put into place protecting the system
• The required uptime of the system must not fall below 99%
• The system must be easy to use, straight-forward to understand and simple to navigate for all staff and users
• The design of the system will be consistent throughout
• The system is to look attractive and be familiar to its intended audience

Below includes a list of Functional Requirements for the project:

• The system information front-end and database back-end will need to be easily searchable due to the policy system holding vast amounts of data
• The system will classify 2 types of users, policy holders and insurance types
• Both policy holders and the insurers can have profiles
• Policy holder profiles should allow a rating of an insurance provider if they have used their services before, review a claim giving them ratings, keep a journal of completed claims and save upcoming payments that will be needed to be completed in the future
• Display data and information on the main home screen should have their policies and any future payments outlined
• This information about the insurers should include the type of insurance taken out with that particular company, their on-site location address, the times they are open and the main person that user should report to about their insurance policies
• The insurance types will have ranking systems, cost and money saved, and have information about the different types of insurance they provide
• This information and the ranking system are required so that the system include an analytics dashboard. These analytical capabilities include, showing the user the best insurers by ranking, best policy types by their needs, other user reviews and other things where the system compares rankings and information to display calculated results
• The system should be able to allow for sharing of upcoming policies on social media websites, by both users and insurer agents

Below includes a list of Performance Standards for the project:

• The system will be responsive to user interaction and include smooth transitioning between content
• The included search capabilities must be effective and efficient when querying information
• The system needs to be inviting to the intended audience and provide a variety of user-friendly options
• Layout needs to be logical and easy to follow
• Test tasks need to be carried by potential users once the system has been integrated into the existing systems
• Time needs to be allocated to allow for changes to be made when testing

Below includes a list of Deliverables for the project:

• A fully designed and implemented system that is effectively able to display policy and insurance information to users.
• A database that compliments the system and stores all information in a secure manner.
• A hosting service for the system so it can operate over the internet.
• A Content Management System that is used to update content by the owner and/or managers in an easy way.
• A user manual for the owner(s) of the system.
• A period after project completion that includes ongoing support to staff when needed. The timeframe period of this support is unknown at this stage, details of this will be further discussed and agreed upon in meetings during the initial stages of development with the successful vendor.

Using the requirements listed above and the following requirements matrix, accurately complete the table below using these details and also details from your system:

Requirement	Included in Base Software	Not Included; Available at Extra Cost (Specify Cost)	Not Included in Current Version; Will be Available in Future Release (Specify Date)	Not Included; Not Planned for Future Releases

(Tayntor 2002, p. 57)

7.     Program Management

The follow section details management within the project and answers are required to the following questions regarding the services you may be providing when undertaking the project. As a potential vendor, provide answers to the following questions:

• Do you intend to include levels of management in the project? If so, how many do you propose?
• How frequently do you intend to alternate key individuals of management?
• What is your communication structure and frequency?
• How would you address dispute resolution?

Answers to these questions will help the company addresses issues with certain practices that may conflict with existing practices used within the project.

8.     Vendor Staffing

Vendors are required to note that any expenditures incurred as a direct result of the preparation and submission of the response to this Request For Proposal will not be held responsible to the requesting company. This also includes the processes involved up until the signing of the contract with the successful vendor. The use of time and finances spent using staff during this process will be held entirely accountable by the proposing vendor and their affiliates.

After vendor selection, if the vendor’s staff are required to work at onsite locations, then the vendor is required to abide to the company’s staff security checks and staff policies whilst onsite. These will include police background checks and potential drug tests which may apply.

You are required to also inform the company within this section of the Request For Proposal any use of sub-contractors within your business. If you do not or are not planning on using sub-contractors for business purposes, then please indicate below. If you plan on using sub-contractors, you are required to state your intention below. The company will hold the vendor responsible for all acts and omissions of sub-contractors as if they were employees of the vendor.

9.     Work space and other vendor requirements

As new staff may be required to work at on-site locations in providing training support as well as face-to-face meetings there will be a need for space location arrangements. Please indicate in this section what type of office space you will require and any administrative support or office equipment that may be needed. Please outline each requirement below and include an estimated cost of those changes.

10.  Vendor Tools

It is required in this section for all vendors who will provide their services to indicate whether or not you are planning on using proprietary tools to provide those services. Answer the questions below regarding the use of the aforementioned tools:

• Will you be using such tools as mentioned above? Provide additional details regarding these tools where you deem necessary.
• Will these tools be embedded in the final work product?
• Specify what rights your company has to use these tools and indicate whether a royalty-free license is available to be used.

11.  Cost Proposal

Cost proposals must be submitted electronically in a separate file from the technical proposal through the SPO Online system, refer to Section 4.1 for instructions. Cost proposals must provide a total proposed cost for completing the requirements of this RFP. Include a detailed itemization of the cost proposal (e.g. breakdown of the project costs, direct and indirect expenses, total number of hours at various hourly rates, overhead, travel, etc.).All costs must be stated in U.S. currency. Any commodities being imported must be identified, and the price must include any applicable customs, brokerage agency fees, and duties.Offeror should describe any discount terms for prompt payment. Discounts for prompt payment will not be considered in evaluating costs.

12.  Proposed Schedule

Vendors will need to provide implementation services for the integration of the policy system into our existing systems. You are required to answer the following in detail regarding implementation of the system:

• Indicate the normal timeframe for implementation of your software for a project of this size and complexity.
• Complete the following schedule below and indicate (mark ‘x’) your proposed timeframes when completing the tasks listed.

MONTH:

1

2

3

4

5

6

7

8

9

10

11

12

LEAD

SYSTEM FESABILITY:

System compatibly checks

Audit of existing systems

Prior software additions

SYSTEM INTEGRATION:

New system integration with existing systems

Changes to existing systems

Internal Testing

User Testing

Upgrades and performance testing

Training of staff to use new system

AGILE DEVELOPMENT TRAINING:

Review of old waterfall methodology

Changes to old system and processes

Planning integration of new agile development methodology

Staff training in new agile development

Final commitments to existing processes

Project Lead: Indicate who you intend to be in-charge of overseeing those particular areas during project development.

13. Payment Terms

The budget for this project is $500,000 US dollars.

40% of this budget will be paid outright to the successful selected vendor once the contract is signed between both parties with another 40% of the budget to be paid at the contract term end when the project owner is satisfied with system integration, performance and functionality and signs off on project completion. The remaining 20% of the budget will be paid once training of staff in agile development is deemed completed and signed off. If the project runs over-time and over-budget, further payment for the project will be withheld, and the vendor may be responsible for delivering a partial system which is insufficiently integrated into the existing systems, along with insufficient staff training. Settlement terms negotiations will take place if termination occurs due to a breach in the contract by either party.

14.  Vendor Nonperformance

Gothaer Insurance Group (the company) has the right to withhold payment for any services not performed in regard to the outlined specifications within this Request For Proposal. Any problematic issues or errors caused during the vendor’s performance whilst working on the project will be correct at the expense of the vendor, and not the requesting company. The company also holds the right to withhold payment if the vendor fails to correct said issues at their own expense.

15.  Changes in Scope

During the project’s operations, either party may be inclined to suggesting un-planned changes depending on the situation and progress of the project. Whilst not breaking any conditions of the contract, either party is entitled to add or remove specific work items within the project that both can make agreements on. These changes will be made with budget in-mind and therefore additional alterations will be made in that department as well.

Additional changes will be determined by either providing payments allocated from the total budget or by adding/removing project work items agreed on by both parties, depending on the situation at hand. All terms and conditions will remain the same under the original contract signed.

References:

• Gotz, O, Wai, Y, Klein, S, Gras, M, Werner, M, Robmehl, M, Basten, D 2018, ‘The (Go)SMART way to agility: managing a Scrum subproject in a waterfall environment’, Journal of Information Technology Teach Cases, 8, pp149-160.
• Tayntor, C 2002, Successful Packaged Software Implementation, Auerbach Publications, Boca Raton.