mfnerc / student information system · pdf filemfnerc / student information system proposal...

Toll free: (866) 956-2727

Phone: (204) 956-2727

Fax: (204) 477-9421

67 Scurfield Boulevard

Winnipeg, Manitoba

Canada R3Y 1G4

www.protegra.com

MFNERC / Student Information System Proposal

For: MFNERC

Date: October 30, 2009

i

Table of Contents

1 EXECUTIVE SUMMARY ...................................................................................................... 1

1.1 PROTEGRA PROPOSAL CONTACT .................................................................................................. 2

2 VENDOR BACKGROUND .................................................................................................... 3

2.1 PROTEGRA ............................................................................................................................ 3

2.1.1 Company Background ..................................................................................................... 3

2.1.2 Key Management Information ......................................................................................... 4

2.1.3 Customer Base and References ....................................................................................... 5

2.1.3.1 Winnipeg School Division No. 1 ................................................................................ 5

2.1.3.2 SEED Winnipeg Inc. ................................................................................................ 5

2.1.3.3 FireSpirit/OCN ......................................................................................................... 6

2.1.3.4 Government of Manitoba ......................................................................................... 6

2.2 OUR PARTNER MAYET INFORMATION SYSTEMS (MIS) ...................................................................... 7

2.2.1 Company Background ..................................................................................................... 7

2.2.2 Key Management Information ......................................................................................... 7

2.2.3 Customer Base and Reference ........................................................................................ 8

2.2.3.1 Winnipeg School Division No. 1 ................................................................................ 8

2.2.3.2 Pembina Trails School Division ................................................................................. 8

2.2.3.3 Swan Valley School Division ..................................................................................... 8

3 PROPOSED SOLUTION ...................................................................................................... 9

3.1 MAP SOFTWARE TO BUSINESS REQUIREMENTS ............................................................................... 9

3.2 SYSTEM REQUIREMENTS ......................................................................................................... 10

3.2.1 System Architecture Diagram ........................................................................................ 10

3.2.1.1 Performance & Scalability ...................................................................................... 10

3.2.1.2 Hardware Recommendations ................................................................................. 11

3.2.1.2.1 Data Tier ......................................................................................................... 11

3.2.1.2.2 Application Tier ................................................................................................ 11

3.2.2 Explanation of Development Platform ............................................................................ 11

3.2.3 Installation and Implementation Methodology ................................................................ 12

3.3 IMPLEMENTATION PLAN .......................................................................................................... 13

3.3.1 Milestones and Expected Deliverables ............................................................................ 13

3.3.2 Deliverables ................................................................................................................. 14

3.3.2.1 Acceptance and Sign Off ....................................................................................... 14

3.3.2.2 Initiation .............................................................................................................. 14

3.3.2.2.1 Project Charter ................................................................................................. 14

3.3.2.2.2 Risk Register .................................................................................................... 14

3.3.2.2.3 Project Plan ...................................................................................................... 15

3.3.2.2.4 Status Reports ................................................................................................. 15

3.3.2.2.5 Change Request Forms ..................................................................................... 15

3.3.2.2.6 Issues List ........................................................................................................ 15

3.3.2.3 Scope Confirmation ............................................................................................... 15

3.3.2.3.1 User Stories and Acceptance Tests .................................................................... 15

3.3.2.4 Construction ......................................................................................................... 16

3.3.2.4.1 Software Component ........................................................................................ 16

3.3.2.4.2 Training and Training Materials ......................................................................... 16

3.3.2.4.3 Converted Data ................................................................................................ 16

3.3.2.4.4 Data Dictionary ................................................................................................ 16

3.3.2.5 Deployment .......................................................................................................... 16

3.3.3 Project Closeout ........................................................................................................... 16

3.3.3.1 Project Closeout .................................................................................................... 16

ii

3.4 TRAINING PLAN .................................................................................................................... 17

3.5 SUPPORT AND MAINTENANCE OPTIONS ....................................................................................... 17

3.6 PRICING ............................................................................................................................. 18

3.7 ADDITIONAL PRICING ............................................................................................................. 19

4 PROJECT MANAGEMENT ................................................................................................. 20

4.1 METHODOLOGY .................................................................................................................... 20

4.1.1 Protegra’s Lean Software Development Method: Lean LifeCycle ...................................... 20

4.1.1.1 Overview .............................................................................................................. 20

4.1.1.2 Iteration Planning ................................................................................................. 21

4.1.1.3 Change Management ............................................................................................ 21

4.1.1.4 Project Planning, Management and Control ............................................................ 21

4.1.1.4.1 Project Management ......................................................................................... 22

4.1.1.4.2 Project Team and their Responsibilities .............................................................. 22

4.1.1.4.3 Quality Assurance ............................................................................................. 24

4.1.1.4.4 Escalation Process ............................................................................................ 24

4.1.2 Core Project Team........................................................................................................ 24

4.2 DOCUMENTATION .................................................................................................................. 25

4.3 DATA CONVERSION ............................................................................................................... 25

4.3.1 Data Conversion Methodology ....................................................................................... 25

4.3.2 Data Conversion experience in Manitoba ........................................................................ 26

4.4 TECHNOLOGY ....................................................................................................................... 27

4.4.1 The application development environment ..................................................................... 27

4.4.2 The database(s) supported ........................................................................................... 27

4.4.3 Database server operating system(s) supported ............................................................. 27

4.4.4 Client or end-user operation system(s) supported .......................................................... 27

4.4.5 Network environment(s) supported ............................................................................... 27

5 ASSUMPTIONS ................................................................................................................ 28

APPENDIXES

MAP SOFTWARE TO BUSINESS REQUIREMENTS (SPREADSHEET)...................................................... Appendix A

RESUMES....................................................................................................................... Appendix B

This statement of work in its entirety is a confidential and proprietary document prepared for the MFNERC by Protegra Inc (Protegra). All information contained in this document has been provided solely for the purposes of evaluating Protegra’s offering. All other rights are reserved. Protegra Inc. 2009

© Copyright Protegra Inc., 1 MFNERC October, 2009, All Rights Reserved. Student Information System RFP Response

1 EXECUTIVE SUMMARY

Protegra’s response:

The MFNERC has issued a request for proposal (RFP) to address a complex and broad implementation of a data management system which will have positive impacts on the current operation of First Nation schools. The province-wide data management system will facilitate data driven decision making for improving education programs for First Nation students. An amalgamated system will ensure First Nations Education Authorities have congruent reporting structures and procedures for all of Manitoba.

Protegra is partnering with Mayet Information Systems (MIS) to deliver this solution. If we are selected to deliver this solution, you can expect us to a) deliver a fully integrated solution tailored to suit your needs and b) deliver impeccable ongoing customer service. While it may sound cliché, we will approach you as our only customer, and make all efforts to ensure that you receive what you require when you require it, instead of being limited by the priorities of other customers as is the typical mode of operation for product companies. At the same time partnering with MIS will allow us to leverage best practices and features across all of MIS’s customers for optional implementation. We will work together with you to prioritize improvements that make sense for you within the constraints of the project. Our goal is to develop a long-term win-win relationship with you so that you may provide value to the First Nations communities across Manitoba.

Our proposed solution meets all of the required requirements of the RFP. From a customization perspective, the main gap with MIS’s existing system involves the Gradebook and the Parent Web Access. We will work with you to customize the application to close all gaps while remaining on MIS’s application upgrade path. MIS currently supports 3rd party integration of a web-based Gradebook and Parent Web Access system that could help to offset initial customization costs. We propose to work with you to determine if a 3rd party system or custom development best suits your needs in the short and long term.

Assuming a contract start date of November 23, 2009 the initial setup effort of loading the data, feature tailoring and training can be accomplished by the end of June and be ready for production for the 2010/2011 school year in September 2010.

Protegra & MIS Advantages:

We believe the combination of Protegra and MIS offers a very strong response to the MFNERC’s needs. In addition to the stated requirements, we would like to highlight the following advantages of selecting Protegra and MIS:

• We recognize that although this RFP has been created by the MFNERC, the system must recognize the local needs of each school. We offer the ability to give schools autonomy by allowing them to map their own language to the divisional and provincial standards.

• The partnership of Protegra and MIS allows you to use the advantages of a small flexible company with the dedicated capabilities of Protegra. We understand that to support this project in Manitoba and possibly beyond, both of these attributes will be important to you and the project.

• An active MIS software license includes receiving all fully tested application updates requested by any of their clients. Additionally, MIS has been in discussions with the Frontier School Division about implementing Mayet and we would be willing to explore a partnership with you between the MFNERC and Frontier School Division about sharing the cost of any customizations required to support rural schools in Manitoba.

• We offer an extremely flexible ad hoc query interface that can enable users to find and report on the information they need without having to make special reporting requests.


• We have worked closely with First Nation organizations in the past. We have previously worked with you in developing a Service Report Tracking System to track and record specialist service calls. Also, FireSpirit is a joint venture between MKO and Protegra to focus on delivering employment services and capacity building to Aboriginal people and northern communities while connecting employers to a skilled Aboriginal workforce.

• MIS has been committed to the Manitoba School Information System industry since 1998. As such, they already have established methods for extracting provincially required reporting data and for importing data from provincial school and student data directly into Mayet to decrease data conversion efforts.

• MIS has recently been prototyping ‘syndromic surveillance’ to allow schools to report on the spread of disease or health issues in First Nation communities. Absence codes used in daily attendance records such as “Influenza Like Illness” along with the student address and family information will allow reports to show the spread of specific health issues over time, space, and relationships. That is, it could simultaneously monitor siblings, classmates, the entire school as well as the entire school division and plot the entire spatio-temporal distribution of a selected health issue moving within the children who presumably are a proxy for the population at large. Officials at the virology lab have agreed that the idea has merit. This project is still in the research phase, but we would welcome the chance to talk more about it with you.

About Protegra:

In business since 1998, Protegra provides Business Performance Consulting and Information Technology Solutions to organizations in Canada, the United States, Europe and Japan. Protegra applies lean principles, similar to those developed by Toyota, to streamline client operations and accelerate business performance. While experts in customized software development and virtual IT services, Protegra offers much more, including business process improvement, executive-level innovation workshops and strategic planning.

About Mayet:

Mayet Information Systems (MIS) is a privately held Canadian information technology developer and service provider. Since 1998 MIS has specialized in servicing the K-12 Education Sector by offering student information management applications, together with a full suite of custom software design, development, reporting and implementation services. MIS has focused its efforts on delivering centralized software solutions to Manitoba school divisions that provide standardized data collection and management tools that meet the reporting and management needs of the school division while providing a broad level of flexibility and customization to the schools that use the systems on a day to day basis.

1.1 Protegra proposal contact

The key contact for this proposal is:

Diego Beltran, Principal Consultant

Protegra 67 Scurfield Blvd Winnipeg, Manitoba R3Y 1G4 (204) 956-2727 [email protected]


2 VENDOR BACKGROUND

2.1 Protegra

2.1.1 Company Background

Protegra is a Canadian company headquartered in Winnipeg that helps clients achieve a higher level of performance and we’ve been doing this for 11 years with organizations in Canada, the United States, Bermuda, Europe and Asia. We set high expectations for ourselves and have high standards for everything that we do. This commitment has made Protegra the #1 Employer in Canada1 and the #3 Best Workplace2 right behind Google. We’ve also been recognized by Profit Magazine 3 years in a row as one of the fastest growing companies in Canada. Our people are what make Protegra great. Our investment in continuously improving and keeping our people is our strength and is the reason for our success on projects and as a company. It’s our people who made Manitoba’s Parks Reservation Solution and that system was recognized as being award winning by the Project Management Institute and the Canadian Information Productivity Committee. Protegra is founded and operates on the principle of partnership with its customers. We believe successful information technology partnerships are based on a complete understanding of our customers’ businesses, solid technology delivery capability and clear communication. Protegra employs 65+ professionals, is 100 per cent employee-owned and since inception has produced an impeccable track record of delivery. Protegra’s entire delivery capability is built around the best business process, information and technology professionals in the business. Our professionals have an average of 11 years of experience with broad industry and technology exposure. Many of our team members are leaders in their field with reputations they have worked hard to earn and work equally hard to keep. Relevant to ths project, our professionals have experience working with non profit agencies and possess technical excellence in Java technologies, SQL Server, Crystal Reports, and infrastructure. From a broad perspective, Protegra’s professionals have expertise in:

• Internet/intranet technologies • Requirements analysis & design • Software development processes • Data conversion • System & product architecture & infrastructure • Business performance consulting • Strategic planning • Business process modeling • Architecture and data strategies • Database & object modeling • Project management • Reporting

Protegra has no real or potential conflicts of interest which would prevent us from acting in the best interests of the MFNERC. 1 As ranked by the Queens School of Business, Hewitt and the Globe and Mail 2 As ranked by the Great Place to Work Institute and the Globe and Mail


2.1.2 Key Management Information

Protegra’s culture is a team approach that means we don’t build or maintain an organization chart. However, Protegra’s senior management team is:

• Wadood Ibrahim, CEO • Cari Hunter, Director of Finance and Administration • Gord Braun, Director, Information Technology • Dan Perron, Lead Business Performance Consulting • Ian Scatliff, Offerings Manager • Barb Spurway, Principal Consultant • Cheryl Hedley, Principal Consultant • Cheryl Smith, Principal Consultant • Diego Beltran, Principal Consultant • Frank Conway, Principal Consultant • Terry Bunio, Principal Consultant • Todd Burton, Principal Consultant

For a list of proposed personnel with corresponding job function, title, qualifications and experience required to effectively and efficiently complete the subsequent contract, please go to section 4.1.2


2.1.3 Customer Base and References

We are pleased to offer the following relevant references for Protegra. The following references include Protegra clients who use one of our licensed product offerings and have engaged with us to provide customizations according to their needs. Please advise us before contacting our references.

2.1.3.1 Winnipeg School Division No. 1

The Winnipeg School Division / Winnipeg Adult Education Centre / Adult English as an Additional Language Program began to use Protegra’s licensed software Correlate in September 2006. Over 60 EAL program staff now use the system intensely to manage a wide array of courses offered from seven locations around Winnipeg.

Administrative staff use the system to configure course offerings and register students in classes, including a great deal of churn as students arrive in the country, change language levels, leave for work and personal reasons and return to the programs. A wide variety of reports support this work and allow the staff to focus on their jobs, instead of paperwork.

Teachers’ work is supported through quick access to their students’ data, and the ability to easily enter attendance and report card data.

The system allows the electronic exchange of student data with Provincial Government systems to support student referrals and funder reporting.

Correlate has supported rapid growth in the WSD Adult EAL program and has evolved according to changing organization and funder needs, including the implementation of automated processes that support increased productivity

Contact Name Jill Tardiff – Vice Principal

Company Address 700 Elgin Avenue

Contact telephone number (204) 775-0416

Contact FAX number (204) 786-3041

Contact e-mail address [email protected]

2.1.3.2 SEED Winnipeg Inc.

SEED Winnipeg Inc. is a non-profit agency that fights poverty and helps renew Winnipeg’s inner city. Protegra implemented our licensed application Correlate as a web portal for the agency to improve administrative processes and data integrity in support of their growing Asset Building Programs. The system included a reporting infrastructure to meet client, agency and funder needs while providing a single record for all clients, managing data across multiple programs. The application supported access by, and integration of data for partner agencies delivering programming in collaboration with SEED.

Contact Name Cindy Coker – Executive Director

Company Address 80 Salter Street, Winnipeg, MB, R2W 4J6





2.1.3.3 FireSpirit/OCN

Protegra has developed solid working relationships with some of Manitoba’s First Nation organizations through its investment and ownership position in FireSpirit Inc. Over the past five years, Protegra collaborated with Manitoba Keewatinowi Okimakanak (MKO) to develop the FireSpirit business plan, secure the contract to develop and support Manitoba’s Job Referral System, and launch FireSpirit. Protegra has provided business leadership, administrative services and technology services in support of FireSpirit operations since the start of business operations. Protegra’s Correlate system also constitutes a key FireSpirit system for Job Seeker tracking and case management.

Protegra has been working with Opaskwayak Cree Nation (OCN) over the past 18 months, developing a solution concept that would include business consulting, quality assurance, change management, business processes and a technology platform/systems to help OCN achieve breakthrough performance in the area of member service delivery, governance transparency and efficient processes. The Protegra team has worked with OCN’s senior management team (with former Chief Glen Ross) to bring this concept to the proposal stage, delivered presentations and system prototypes. Glen Ross, former Chief of OCN and Marv Tiller, president of Canadian Shield Enterprises and Director of FireSpirit, would be pleased to act as Protegra references and are well positioned to speak to Protegra’s awareness of First Nation culture and issues, and to Protegra’s abilities when it comes to delivering business and technology solutions

Contact Name Glen Ross - former Chief of OCN


Contact Name Marv Tiller – President of Canadian Shield Enterprises Inc., Director of FireSpirit

Company Address 43 Middle Gate, Winnipeg, MB, R3C 2C5




2.1.3.4 Government of Manitoba

The Government of Manitoba engaged us to plan and develop the Job Referral System in partnership with MKO. This project focused on delivering employment services and capacity building to Aboriginal people and northern communities while connecting employers to a skilled Aboriginal workforce.

Contact Name Phong Duong – Senior Manager, Manitoba Infrastructure and Transportation

Company Address 1000-259 Portage Ave, Winnipeg, MB, R3B 3P4





2.2 Our Partner Mayet Information Systems (MIS)

2.2.1 Company Background

Protegra is the lead and prime vendor for this proposal and we are proud to be able to strengthen our offering by working with MIS. MIS is well positioned in Manitoba and makes for a strong partner to work with Protegra and the MFNERC in delivering a School Information System to the First Nation communities.

Mayet Information Systems (MIS) is a privately held Canadian information technology developer and service provider. Since 1998 MIS has specialized in servicing the K-12 Education Sector by offering student information management applications, together with a full suite of custom software design, development, reporting and implementation services. MIS has focused its efforts on delivering centralized software solutions to Manitoba school divisions that provide standardized data collection and management tools that meet the reporting and management needs of the school division while providing a broad level of flexibility and customization to the schools that use the systems on a day to day basis.

Mayet Student Information System is a comprehensive district-based solution for student information management. Mayet has been designed and implemented as a centralized system to provide real-time information on students and schools throughout the district. Built for Intranet or Internet deployment with standard data exchange facilities, Mayet has emerged as the solution for school districts wanting to leverage existing investments in human and technical resources.

Mayet Report Card is an enterprise-wide web based solution that provides school districts a comprehensive tool-kit to manage student achievement reporting from within an extremely flexible and configurable software infrastructure.

MIS’s success has been based on building strong, long-term relationships with our clients that address all aspects of system development and implementation.

2.2.2 Key Management Information

MIS’s senior management team is: • Chris Adamopoulos, President • Shane Petroff, Vice President

For a list of proposed personnel with corresponding job function, title, qualifications and experience required to effectively and efficiently complete the subsequent contract, please go to section 4.1.2


2.2.3 Customer Base and Reference

The following is a list of MIS’s major clients who are currently using Mayet. Please advise us before contacting our references.

2.2.3.1 Winnipeg School Division No. 1

Contact Name Doug Edmond – Director, Research, Planning and Systems Management

Company Address 1180 Notre Dame Ave, Winnipeg, MB, R3E 0P2




2.2.3.2 Pembina Trails School Division

Contact Name Don Reece – Director of Information Technology

Company Address 181 Henlow Bay, Winnipeg, MB, R3Y 1MZ




2.2.3.3 Swan Valley School Division

Contact Name Cam Mateika – Director of Research and Technology

Company Address 1481 3rd Street North, Swan River, MB R0L 1Z0





3 PROPOSED SOLUTION

3.1 Map Software to Business Requirements

For the detailed mapping of existing Mayet functionality to your business requirements, see the spreadsheet in Appendix A. A summary of the mappings is provided here:

Count of Requirements marked ‘Required’ (Total of 239)

Area Yes * Partial No

Assessment 4 0 0

Attendance 25 2 0

Demographics 7 0 0

Discipline 7 3 0

General 45 10 0

Gradebook/Transcript 56 5 0

Health 13 0 0

Parent Web Access 1 2 0

Scheduling 55 3 0

Special Ed 0 1 0

Total 213 - 89% 26 - 11% 0 - 0%

* Some customizations required

Count of Requirements marked ‘Desired’ (Total of 78)

Area Yes Partial No

Assessment 7 1 0

Attendance 14 1 1

Demographics 1 0 1

Discipline 5 1 1

General 8 1 1

Gradebook/Transcript 10 1 2

Health 3 0 0

Parent Web Access 2 0 5

Scheduling 11 0 1

Special Ed 0 0 0

Total 61 - 78% 5 - 6% 12 - 15%


3.2 System Requirements

3.2.1 System Architecture Diagram

Mayet Student Information System - Resource Schematic

Data Tier Application Tier

Centrally Managed Resources

Client Tier

All Database access

via JDBC interfaces

from Application Tier.

Client Protocol

RMI

Protocols

HTTP

FTP

Report Server

Client Protocol

HTTP

Client to Application Tier communication

can be facilitated through a number of

configuration options. Including:

Encrypted VPN

Firewall Tunnel / Proxy / NAT / PAT

SSL (128 bit keys)

Direct Connection

SQL Server 2005

Web Server

Report Card

Application Server

Apache Tomcat

Batch

Report Server

Interactive

Report Server

Mayet

Application Server

Client Protocol

HTTP

Supported Java VM

SUN JVM 1.6+

Supported OS

Microsoft XP+

Macintosh V10+

Linux Variants

3.2.1.1 Performance & Scalability

The application with the architecture above and the hardware recommendations below is more than sufficient to support the performance and scalability needs of the MFNERC’s initial project and vision for a national product. This architecture currently supports 33,000 students, 3,000 users and 85 schools for Winnipeg School Division. Protegra and MIS expect to work together to monitor and improve the performance and scalability of the application as the number of students, users and schools increases.

With the uncertainty surrounding the networking performance in rural communities, we will work with you to diagnose any performance and scalability issues as they arise on a time and materials basis.


3.2.1.2 Hardware Recommendations

All server hardware should be acquired from Tier 1 vendors.

3.2.1.2.1 Data Tier

The typical data tier is configured on a single host server with the following recommended profile:

• 64 bit multi processor server architecture • 4 x Quad Core 2GHz Xeon Processor • 16 GB RAM • RAID 1+0 Drive Array – 1Tbyte capacity

3.2.1.2.2 Application Tier

The typical application tier can be configured on a single host server running virtualization software such that each virtualized instance is configured with the following recommended profile

Report Card Application Server

• 64 bit multi processor server architecture • 2 X Quad Core 2GHz Xeon Processor • 4GB RAM • 400GB Disk Space

Mayet Application Server

• 64 bit multi processor server architecture • 1 Quad Core 2GHz Xeon Processor • 2 GB RAM • 100GB Disk Space

Web Server

• 64 bit multi processor server architecture • 1 Quad Core 2GHz Xeon Processor • 1GB RAM • 100GB Disk Space

Report Servers

• 64 bit multi processor server architecture • 2 X Quad Core 2GHz Xeon Processor • 2-4GB RAM • 200-400GB Disk Space

3.2.2 Explanation of Development Platform

Mayet including all of its web based components are developed in the Java programming language and fall within the Java SE platform (we do not use EJB technologies). All of the code is backwards compatible with the Java Runtime Environment (JRE) version 1.4, but we recommend deployment to the JRE version 1.6 update 16, Sun Microsystems’ current stable build. All of the main modules including User Interface, SSL, networking and database access are handled via the Sun API's.


3.2.3 Installation and Implementation Methodology

The installation of Mayet Student Information System and Mayet Report Card has been designed as a fairly simple procedure and as such a complex methodology has not been required. MIS will walk through the implementation procedures and the Administrator Reference Guide with an administrator from the MFNERC. This process usually does not take more than 1 day. See section 3.3 for further information on the timing of the installation.


3.3 Implementation Plan

Assuming a start date of November 23, 2009 and the currently understood scope, the following table outlines the milestones for the project, the required resources from the MFNERC, and any deliverables that will be produced or milestones that may be met.

Protegra will not be responsible for any project delays associated with availability of the required resources from the MFNERC.

3.3.1 Milestones and Expected Deliverables

Dates Project Activities The MFNERC resources

Deliverables / Milestones

Nov 23, 2009 Contract Negotiation Project Director, Project Acceptor

Diego Beltran, Steve Rogalsky, Chris Adamopoulos, Shane Petroff

Nov 30, 2009 Initiation

- Initial development activities (environment and software setup)

Scope Confirmation

- Confirm customization scope, cost and schedule

Project Director, Project Acceptor

Diego Beltran, Application Architect(s), Technical Architect, Project Manager, and Developer(s)

Jan 4, 2010 Construction (2 week Iterations)

- Delivering tested, production ready code every iteration.

Project Director, Project Acceptor

Application Architect(s), Technical Architect, Project Manager, and Developer(s)

Feb, 2010 Train the Trainer sessions

- based on existing functionality

Project Director, Project Acceptor, Trainers

Chris Adamopoulos, plus MIS’ trainer

Mid June 2010 UAT Support Project Director, Project Acceptor, additional users

Application Architect(s), Technical Architect, Project Manager, and Developer(s)

Mid June 2010 Train the Trainer sessions

- based on customizations

Project Director, Project Acceptor, Trainers

Chris Adamopoulos, plus MIS’ trainer

Sept 2010 Go Live of first 10 schools 2nd level support 3rd level support

Sept 2011 Go Live of next 16 schools 2nd level support 3rd level support



Sept 2014 Go Live of final 10 schools 2nd level support 3rd level support


3.3.2 Deliverables

This section describes the deliverables that will be provided for this project. Each deliverable includes a statement to describe the acceptance criteria, and how each deliverable will be accepted (i.e.: is a review or sign off required).

3.3.2.1 Acceptance and Sign Off

Sign off of deliverables by way of a simple e-mail acknowledgement that a deliverable (or a batch of deliverables) are accepted.

During project initiation:

1. We will agree upon acceptance turnaround times per deliverable during project initiation.

2. We will agree upon a course of action if a deliverable or software component is not accepted.

3.3.2.2 Initiation

A formal project kick-off will be conducted with the key stakeholders of the project to:

• Review and confirm the project work plan (this document) and budget.

• Establish team roles, responsibilities and individual expectations.

• Agree upon target dates and times for key project delivery milestones.

• Agree upon a project meeting and reporting strategy.

• Establish a project change control mechanism.

• Establish escalation process.

The following deliverables will be produced during this phase:

3.3.2.2.1 Project Charter

The project team will meet with the client stakeholders to jointly define the scope and rules of engagement for the project.

Acceptance Criteria: Must define roles and responsibility for project members. Sign off required.

3.3.2.2.2 Risk Register

The project team will meet with the stakeholders to identify the possible risks to the success of the project. Risk mitigation strategies will be identified as appropriate. Risks and risk mitigation will be tracked throughout the project as part of the weekly project status

Acceptance Criteria: Must accurately capture risks for the project on an ongoing basis. Sign off required only on initial creation.


3.3.2.2.3 Project Plan

The Project Plan is a tool to provide the ultimate guidance for completing the project deliverables, the start and finish times and effort, the resource assignments, and the dependencies of the various deliverables and activities. The project plan defines the activities in each project phase and each development release and constitutes a benchmark by which to evaluate the project’s progress.

Acceptance Criteria: Must define the schedule for the project. Review only, sign off not required.

3.3.2.2.4 Status Reports

The Status Report is used to communicate and maintain a record of the project’s progress and performance compared to the published Project Plan. Status reports are typically sent to the client on a weekly basis.

The reports communicate items such as current team members, status summary, milestones and their delivery dates, project cost to date, activities planned for the upcoming week, and the status of activities planned for the week that passed.

Acceptance Criteria: Must define the progress and status of the project for the last reporting period. Review only, sign off not required.

3.3.2.2.5 Change Request Forms

This deliverable provides a means to express what change is requested in the system, and impact this change will have on scope (time, budget, functionality).

Change Request (CR) forms require client sign-off as they usually indicate a change to the commitment agreed to in the contract.

Acceptance Criteria: Must define the impact of the described change for the project in terms of budget, schedule, and scope. Sign off required.

3.3.2.2.6 Issues List

An itemized record of all project issues and their associated resolution activities. Issues shall be classified into technical and business issues.

Acceptance Criteria: Must define active issues for the project. Review only, sign off not required.

3.3.2.3 Scope Confirmation

The project team will use the requirements spreadsheet along with stakeholder conversations and create more detailed specifications in preparation for software construction.

3.3.2.3.1 User Stories and Acceptance Tests

A list of acceptance test cases for each user story based on the scope identified in the requirements spreadsheet.

Acceptance Criteria: The test cases must answer the question: “How will I know when I’m done?” Prior to building each component, it is expected that the single acceptor will review and solicit acceptance tests from all schools where applicable. Sign off required.


3.3.2.4 Construction

The project team will proceed with software construction. During this phase the project team will develop, review and refine the software components required for the solution and will continue preparations for delivery.

3.3.2.4.1 Software Component

The Software component is the physical implementation of the functional specification.

Acceptance Criteria: Must pass all documented acceptance tests. Sign off required on completed components every two weeks.

3.3.2.4.2 Training and Training Materials

Initially, training and training materials will be provided for the existing system without customizations. Updated training and training materials that reflect any customizations will be delivered near the end of the customization effort.

Acceptance Criteria: Must reflect the current application. Review only, sign off not required.

3.3.2.4.3 Converted Data

A repeatable process to convert data from the schools to be implemented that school year will be created. Acceptance tests (usually in the form of QA reports) will be defined to determine if the process has been completed properly.

Acceptance Criteria: Must pass all documented acceptance tests. Sign off required one each school has been converted.

3.3.2.4.4 Data Dictionary

A map and description of all the database tables and fields. This documentation will enable skilled staff from the MFNERC to respond to internal reporting needs.

Acceptance Criteria: Must reflect the current database. Review only, sign off not required.

3.3.2.5 Deployment

Deployment to test servers will happen at the end of each iteration. If desired, deployment to production servers can occur at the same time.

3.3.3 Project Closeout

The Project Close phase is very important from an organizational learning perspective. The Post-Mortem deliverable will provide a summary of “what went right”, and “what went wrong”.

3.3.3.1 Project Closeout

The closeout document is the single most important artefact to support continuous improvement efforts. This deliverable is produced from the minutes of the closeout meeting. This meeting should be attended by members of the Project Team, project directors, and a member of both the MFNERC and Protegra who are responsible for the continuous improvement of their processes.


3.4 Training Plan

User training will be conducted through a “Train the Trainer” approach. The Protegra/MIS team will provide two one-time training sessions. We suggest using a “Train the Trainer” approach because it allows a person knowledgeable with the users and their issues to show them how to use the system according to their needs. MFNERC’s trainers are better equipped to customize the training to provide relevant examples and case studies of how the application can be used in each environment. MFNERC trainers will be able to translate their knowledge and experience into a better training experience for the users of the system. The first session will include application training for up to 10 individuals from the MFNERC or the school divisions. The MFNERC will then provide training to other users in the schools, divisions or within the MFNERC. The second session will include training for the MFNERC IT staff to instruct them how to install and administer the system on an ongoing basis. Training material will be customized for the MFNERC’s needs. The “Train the Trainer” courses will occur in Winnipeg at Protegra’s facility and will include training material that can be customized and used for further training. The MFNERC will provide all necessary trainers, training facilities, and equipment for subsequent user or administrative training. See section 3.3 for further information on the timing of the training. See section 3.6 for further information on the pricing of the training.

3.5 Support and Maintenance Options

Protegra and MIS will provide a five year support and maintenance agreement. We will work with you to design a warranty program that meets your requirements including disaster recovery and after hours support if required. The support contract includes:

• Setting up a production, test and development environment. This assumes appropriate hardware is setup and ready.

• All provincial reporting requirements (100% EIS compliant). • 120 hours of 3rd level support on working days 9am to 5pm CST to receive calls from the

MFNERC. This includes a 24 hour call return guarantee and 7 day (or sooner) issue resolution 90% of the time. Any additional hours required will be billed at $110.00/hour.

• All fully tested application updates from any client for the duration of the license. This may include new features, bug fixes and JVM compatibility issues

• User manuals. • Unlimited users per school. • We recognize the unique working environment for this solution and so we will work with the

MFNERC to design an escalation process for software related service outrages. The support contract does not include:

• Customization efforts. • Break/fix support of any production feature (except within the 120 hours specified above) • Training of 2nd level support and administrative staff as specified in section 3.3. • Updates to the Training Manual as a result of customization efforts. • Travel outside of Winnipeg. • Hardware costs. • Data conversion or migration.

See section 3.6 for further information on support and maintenance pricing.


3.6 Pricing

All pricing is provided in Canadian currency and is exclusive and net of any applicable Provincial and Federal taxes. MFNERC is responsible for any mutually agreed upon expenses including airfare and lodging that may be incurred by Protegra.

Licensing - A perpetual unlimited-user license for the Mayet solution is $5,000.00 / school due the first day the school goes “live” with the software.

Support and Maintenance - Support and maintenance fees are $16,800.00 / year, and the first payment is due the first day of go-live.

Training – Based on the train the trainer approach outlined in section 3.4, the training costs will be $30,000.00 including customized training materials.

The licensing, training, support and maintenance outlined in the following example assumes that 10 schools will go live in 2010, 16 in 2011 and 10 schools in each of 2012, 2013, 2014.

Rates - Protegra proposes a single blended rate of $110.00 / hr for all customizations and data conversion efforts.

Customizations – We reviewed and estimated the gaps between the Mayet solution and all of your required functionality. In order to close the gaps we propose to custom develop the required functionality including partial and currently non-compliant features. We estimate this effort to be in the range of $700K to $1.10M.

This pricing is provided only to give a sense of the size of customizations needed to meet your requirements. Re-estimation will occur at the end of the Scope Confirmation phase. Effort and cost will vary as we learn more, when scoping assumptions we’ve made are refined.

We recommend focusing to deliver only required functionality in year 1, and defer delivering the desired functionality to year 2 and year 3. After more reflection, perhaps there is required functionality that can be deferred until a later time. This may be done to reduce the initial cost of implementation in year 1. We look forward to partnering with you in defining those features that will provide the most value to the First Nations communities.

Given that Gradebook is our largest gap, we may wish to investigate 3rd party Gradebook and Web Portal tools that could be integrated with Mayet. If selected, we will work with you to balance the cost of 3rd party tools vs. customization.

Scope Confirmation phase – Prior to beginning any customizations, we recommend an initial Scope Confirmation phase to confirm the required versus desired requirements. Assuming we would review only the required requirements, we estimate this phase may take approximately $75K.

Data conversion – Data conversion effort will be charged in “time and materials” business terms, using the rates described above. We expect that as we encounter a conversion from the same product we will become more efficient at performing the required data conversion. This cost has not been estimated, and we will work with you to determine the number and types of data conversions that must be undertaken.

What’s not included – MFNERC is responsible for client and server hardware, operating system software and database management system software. See Hardware requirements in section 3.2.1.


3.7 Additional Pricing

See Hardware requirements in section 3.2.1


4 PROJECT MANAGEMENT

4.1 Methodology

4.1.1 Protegra’s Lean Software Development Method: Lean LifeCycle

We propose the use of Protegra’s Lean Lifecycle agile software and project management method for eliminating the gaps between Mayet’s current solution and the mandatory requirements of the MFNERC.

This section provides a brief overview of this method.

4.1.1.1 Overview

Lean development is a style of software development that emphasizes customer satisfaction through continuous delivery of functional and fully tested software. In contrast to traditional software development methods, lean developers liaise continuously with business clients. Their objective is to deliver working software as frequently as every two weeks during a project, and welcome changes to the requirements in response to evolving business needs.

The most crucial aspect of Lean LifeCycle is the execution of the project in iterations and quick feedback loops that are made possible with the use of iterations. It is essential to note that these iterations do not just apply to construction; they also apply to the following tasks:

• Project Management and Planning

• Analysis

• Technical Design

• Testing

• Deployment

Traditionally, System Integration Testing (SIT) is the first time that release system builds are performed and tested. The problem with this approach is that issues with putting everything together are not discovered until after construction is complete and there is less time and budget to adjust and correct for these deficiencies in the system.

Lean Lifecycle proposes a paradigm shift in the project team’s approach to project execution. Instead of distinct serial phases of a project, all phases are incorporated as an ongoing project process. There is value to be gained by performing the first system builds as quickly as possible after construction has begun.

Protegra understands that a system development life cycle methodology must be appropriately balanced between policy and innovation. Policy allows system development companies to achieve consistent results through “Best Practices”. However, rigid processes become cumbersome for small projects, and specific project situations may require various process modifications to achieve optimal results. The challenge is to create the correct adaptations for a given project.

The deliverable-based and modular nature of Lifecycle allows for effective scaling of the process to suit small, medium, and large projects. Care has been taken to ensure that the overall essence and principles of quality planning and project management remain intact.


4.1.1.2 Iteration Planning

Iteration planning is the key planning initiative. Iterations need to be planned in conjunction with the client to accomplish the following:

• Deliver functionality to define the tempo of the project.

• Deliver functionality to deliver real value to the project (working code that can be and is tested).

• Deliver functionality to minimize risk for the entire project.

• Allow the team to respond to scope changes or tradeoffs at regular intervals throughout the project.

• Lessons learned from one iteration must feed into subsequent iterations so that we don’t (just) execute the project in iterations with similar results, but that we execute the project in iterations with better results.

• The project team executes better, smarter, and quicker.

• The project team goes through the process of forming, storming, norming and performing quicker.

4.1.1.3 Change Management

The Change Management process is fundamental to the successful delivery of the project. The Change Management process ensures that each change introduced to the project environment is appropriately defined, evaluated and approved prior to implement. Change Management within Lean Lifecycle tries to balance welcoming scope changes in response to evolving business needs while remaining attentive to schedule and cost.

The following activities will be done as part of the Change Management process:

• Request for Change Forms should be completed, estimated, submitted for approval and prioritized against the currently undeveloped features.

• During each iteration planning meeting the backlog of remaining prioritized work is re-evaluated and re-prioritized. This may mean that some new changes are prioritized above existing scope and that existing lower priority scope is removed from scope if cost and schedule is affected negatively.

• Affect on cost, schedule and scope are tracked and published for each scope change.

4.1.1.4 Project Planning, Management and Control

Protegra focuses on forming long-term relationships with our customers and therefore, we place the utmost importance on understanding our customers’ business, technology, and operating environment. We believe effective project delivery is based on solid communication and management practices.


4.1.1.4.1 Project Management

Protegra’s project management approach emphasizes partnership, communication, disciplined risk management and effective issue resolution to:

• Focus resources and schedule activities to satisfy project objectives and user/client needs.

• Manage objectively in response to all project reviews, opinions and issues.

• Use participatory decision-making that involves all team members in various capacities.

• Implement continuous review and improvement to enhance the quality of the deliverables throughout the project.

MS Project is used by Protegra to develop and implement the project plan. Key milestones, tasks and product delivery dates will be incorporated into the plan. This project plan will be confirmed as a part of the project initiation meeting. Status reporting requirements and plan revisions are completed in accordance with the MFNERC project team’s requirements.

The development of a project charter is a fundamental component of Protegra’s project management environment. This document incorporates a refined scope of work addressing each project phase together with written procedures for internal project team communication, staffing and administration. It also incorporates key project milestones, quality assurance criteria and other project processes as required by the MFNERC.

4.1.1.4.2 Project Team and their Responsibilities

An effective project team involves many roles, including those held by:

• The MFNERC IT staff

• The MFNERC stakeholders and system users

• Protegra project staff.

We structure our project teams to capitalize on the skills of our delivery personnel as well as the specific requirements of each client implementation.

The following diagram illustrates a typical project organization structure for the implementation of a Protegra solution:


A general description of the key roles and their responsibilities is set out below.

Protegra and the MFNERC will each assign a project director. The project director is the principal contact for each organization responsible for project delivery commitment, contract and organization-to-organization relationship. Where a dispute arises over any issue, the MFNERC project director and the Protegra project director will make the final decision jointly.

The MFNERC is required to appoint a Project Acceptor for overall project implementation. The role of the Project Acceptor is to sign off on all deliverables and authorize the project team to proceed with the next development stage. In many cases, the MFNERC’s project director will also fill the Project Acceptor role.

The Project Acceptor is the MFNERC’s representative and acts on behalf of the MFNERC’s management, stakeholders, application users and information technology team. The Project Acceptor is responsible for determining the appropriateness of project timelines and budget. The final responsibility of the Project Acceptor is to provide formal acceptance of each project deliverable, changes to scope and final contract acceptance.

Many projects receive direction, input and requirements from all parts of a client’s organization. In these situations, Protegra recommends the formation of a Steering Committee comprised of the MFNERC Project Team and key business users. The Protegra Project Director will also be a member of the Steering Committee.

The joint the MFNERC/Protegra project teams will share responsibility for completing the deliverables on schedule and on budget. Successful completion of this project depends on the cooperation of all parties and the strict adherence to the project timelines.


4.1.1.4.3 Quality Assurance

Quality assurance is integral to the Protegra Lifecycle method. We apply a consistent plan-do-check-act process that incorporates regular peer reviews, client approvals at key project milestones and regular feedback mechanisms. Protegra offers a complete quality assurance program including test case development, testing, automated test tool development and functional testing upon request.

Protegra maintains an active solution issue/bug tracking database for each implementation. This database includes information on problem identification, status, resolution actions, priority and responsibility. This information is shared with the client project team on an ongoing basis.

4.1.1.4.4 Escalation Process

Technical implementation and scope management conflicts are referred to the project director/acceptor for resolution. Failure to agree on a course of action at this level may potentially require a meeting between the MFNERC and the Protegra project directors.

Protegra and the MFNERC will work together to create a decision-making framework and tempo that places emphasis on intent, efficiency of time and resources, and overall technical suitability. Unreasonable delays in the resolution of conflicts can result in change requests.

4.1.2 Core Project Team

Protegra has a great deal of strength and depth in qualified resources for the various positions required on the project. Protegra’s consultants average 11 years of experience. The final team will be negotiated once the project is under way but the following core project team is expected to be involved throughout this project. Resumes are available in Appendix B.

Application Architect

The application architect will envision the application and its use to design a solution.

The application architect will envision the application and its use to design a solution. They are responsible for the functional design of our systems solutions, including feature sets, data model, storyboards and other project design artefacts. This role provides the bridge between the business and the technical delivery team. To do this, the application architect communicates often with the business analyst, domain experts, project manager, and technical architect.

Application Architects proposed for this project:

• Steve Rogalsky (Protegra)

• Chris Adamopoulos (MIS)

Technical Architect

Protegra technical architects design technical solutions, manage Protegra assets and are responsible for the technical feasibility and performance of our solutions. The technical architect can demonstrate leadership competency and has solid design, development, implementation and consulting experience.

Technical Architects proposed for this project:

• Colin Foulkes (Protegra)

• Shane Petroff (MIS)


Project Manager

The project manager possesses extensive experience in managing moderate to complex IT projects, within a process-driven and client- focused environment. They can foster teamwork on the project team right from the start as well as promote innovation and creativity to ensure on-time, on-budget completion of the project to the satisfaction of our clients.

Project Manager proposed for this project:

• James Niessen (Protegra)

Senior Developer

A Protegra Developer is responsible for the coherent and consistent design, development, delivery and documentation of a solution to a particular business problem. This solution is generally but not exclusively a software solution.

Senior Developer proposed for this project:

• Derek Moore (Protegra)

4.2 Documentation

The following documents are currently available:

• User Guide

• Training documents

• Administrative Reference Guide

The documents are available as stand-alone documents and integrated as web documents into the on-line help system. All documentation will require updating as customizations are completed.

4.3 Data Conversion

4.3.1 Data Conversion Methodology

The typical approach used in previous data conversion projects is a systematic process that identifies legacy to Mayet data mappings. Unstructured legacy data are parsed into structured Mayet objects to estimate legacy data object redundancy and duplication. Conversion programs are developed to execute conversions in such a way that duplication is reduced or eliminated.

A typical conversion project flow consists of the following process:

• Analysis – Legacy system data analysis and business rule identification

• Data mapping - Legacy system to Mayet data field mapping

• Conversion routine – Custom combination of data scripting and software program development that implements the data mappings identified.

• Integrity checking - Quality Assurance reports are developed that compared existing legacy data records to converted data records. Record validation software built into Mayet identifies inconsistent records and facilitates data cleaning efforts

• Post-conversion clean-up – QA procedures will identify inconsistent records and a manual effort using Mayet is used to clean records identified as either inconsistent or incomplete.


4.3.2 Data Conversion experience in Manitoba

Mayet has developed conversion routines to convert student management data from both custom relational database schemas as well as from established Student Information System vendors.

Winnipeg School Division - SAS

The Winnipeg School Division legacy student information system was an internally developed product that used the Ingres relational database to manage data. SAS generated primarily structured data whose data mappings to Mayet where clearly identified. SAS business rules were identified and those rules were integrated into the conversion routines to validate exported data. Conversion programs were developed to parse unstructured legacy data objects such as address into structured Mayet data objects. A number of quality assurance reports that compared data from the legacy system to that in Mayet were used to monitor converted data fidelity.

The Mayet rollout at WSD followed a school by school phased-in approach that required the conversion to run daily for a two-year period.

Trevlac

Trevlac data originates from a file based system that is imported into a relational data model for further analysis. The Trevlac student information system allows user in schools to create at hoc codes and data in a variety of fields which creates data mapping uniqueness. While an organization that enforces consistent coding helps alleviate these issues the reality is that most Trevlac conversion experiences we have had require that a unique data mapping effort is required for each converted school. Most Trevlac conversions require a significant data cleaning effort and QA processes. Standard conversion routines have been developed to convert data from Trevlac to Mayet. However, in each Trevlac to Mayet conversion significant modifications to the data mapping and significant data cleaning were required. One key problem area in converting Trevlac records is with respect to academic history. The most consistent solution to this problem is to have the school being converted have the academic history for each student be requested from the Province of Manitoba student records branch. MIS has successfully imported the provincial government records into Mayet.

School Plus

The School Plus student information system was a main-frame software implementation that was hosted on a Prime supermini computer at the Assiniboine South School Division. This was a binary file based system that used variable valued fields. A custom program was developed that would export the binary School Plus files into ASCII text files that expanded variable value fields into subordinated file structures. Due to the proprietary nature and closed-code base of the School Plus system a conversion routine was developed that mapped all School Plus fields to Mayet data records and School Plus business rules were interpreted and integrated into the data mappings. Quality assurance reports were developed that compared converted data to the static School Plus files and an iterative approach was utilized to correct errors and data inconsistencies.


4.4 Technology

4.4.1 The application development environment

Mayet is currently developed within the Intellij IDEA integrated development environment, available through JetBrains Inc., however the project could be compatible with any development tool, Netbeans and Eclipse being the most obvious competitors. The projects have dependencies on:

• Apache Tomcat Web container

• Apache MyFaces Trinidad Component/Ajax library

• Apache MyFaces Tomahawk Component library

• Apache Xerces XML parser

• Apache Commons Utility Library

• Spring Framework v2.5.5 or higher

• Hibernate 3.2.5 or higher

• And any compliant JDBC driver (e.g. Microsoft SQL Server JDBC Driver version 2+).

All of the development tools are cross platform and can run under many operating systems.

4.4.2 The database(s) supported

Mayet is designed to be database agnostic. That is, none of the code depends on specific database features and all of the SQL is formulated in a SQL92 compliant manner. SQL92 complaint JDBC drivers may utilize database specific SQL through the JDBC extensions mechanism, so that expressions like CONVERT are translated into database specific dialects. Hibernate also supports all of the major enterprise grade dbms dialects (e.g. MS SQL Server, Oracle, IBM DB2, Postgres etc.) Currently all of our clients have migrated to our recommended database platform: MS SQL Server 2005.

4.4.3 Database server operating system(s) supported

The application and database servers can be run on Windows NT4, Windows 2000 server, Solaris, and most Linux variants.

4.4.4 Client or end-user operation system(s) supported

We currently have clients running Microsoft Windows 2000, Windows XP, Windows Vista, Mac OS X, and Red Hat Linux. We have also performed minimal testing under Ubuntu Linux.

4.4.5 Network environment(s) supported

The application can be supported on both Windows and Novell Netware environments.


5 ASSUMPTIONS

1. The licensing outlined in this document assumes that 10 schools will go live in 2010, 16 in 2011 and 10 schools in each of 2012, 2013, 2014.

2. Protegra and MIS will be responsible for regular deployments to one development server, one test server and 1 production server while developing the application. MFNERC will be responsible for deploying the application to client computers and to any additional servers for both production and testing.

3. The MFNERC stakeholders will be available for workshops, meetings, signoffs, decisions requests, and issue resolution in a reasonable and timely manner. Unreasonable delays created by the limited availability of the MFNERC staff may result in a change request. Accepted turnaround times per deliverable will be agreed upon during project initiation as per section 3.3

4. The MFNERC will be deemed to have accepted the final deliverable when the system is performing as detailed in the Test Strategy/Plans or once the system is put into production, whichever event occurs first.

5. The business implementation planning and activities for this project will be the responsibility of the MFNERC.

6. The MFNERC will be responsible for:

a) Providing required information on system requirements including, but not limited to:

i. Business procedures and workflows

ii. Business requirements

iii. Non functional requirements (i.e. performance, security, etc)

b) Ensuring requirements communicated to the Protegra project team address the priorities of the MFNERC.

c) Reviewing and testing the software and its customizations

d) Reviewing and approving deliverables in a timely manner as agreed to in section 3.3.

7. The MFNERC will be responsible for identifying and organizing appropriate staff for participation, where relevant, in individual project tasks.

8. If selected, the required and desired requirements will be reviewed and clarified to confirm the scope and cost of each requirement.

9. The MFNERC will provide a single acceptor for acceptance of the system with the authority to make decisions on behalf of the MFNERC and all of its schools.

10. The Protegra project team will work out of the MFNERC’s offices. Mayet resources will work part time out of the MFNERC’s offices.

11. Source and source control will be housed at Protegra. The MFNERC will provide appropriate VPN hardware so that the project team can access the source from the MFNERC.

12. The single acceptor will be 100% available to the project and on site with the Protegra team at the MFNERC office.

13. Prior to building each component, it is expected that the single acceptor will review the functionality and confirm the acceptance tests.

14. The MFNERC will be required to fully test each completed deliverable in each iteration. Because of this, the final UAT Acceptance period will only require a reduced project team.


15. Since there are no performance requirements listed in the RFP, Protegra and MIS will work with the MFNERC to determine and execute performance requirements for the application once selected. Due to the unknown nature of the rural network speeds, improvements to performance will be done on a time and materials basis. This could include network profiling, data replication, and other related tasks.

16. Protegra will provide the computer facilities to be used for development by Protegra staff.

17. Any expenses associated with conducting this project will be billed at cost, although no expenses are anticipated at this time. Approval for any such expenses will be obtained in advance from the MFNERC.

18. Protegra is not responsible for delivery dates or phase commitments until the scope and schedule have been jointly reviewed and confirmed.

19. All test and production hardware and infrastructure costs are the responsibility of The MFNERC.

20. Updated Training or Training Manuals as a result of customizations is not covered under the licensing costs.

21. Source code will remain the property of MIS and will not be delivered to the MFNERC.

22. All applicable Provincial and Federal taxes are in addition to this proposal. These costs are the sole responsibility of the MFNERC.

23. All pricing is in Canadian dollars.

mfnerc / student information system · pdf filemfnerc / student information system proposal...

Documents