Please see Scope Requirements

Question:
how many data sources and what are they, SQL, API, CSV.

are the data source on premise or in the cloud

is the Fabric tenant all ready provisioned and managed by the university

Answered on 20/Jul/2026 09:58 AM:


1/2. 14 Sources

2x SQL, Vendor Tenant (Postgres, SQL Server)

6x API, Vendor Tenant

2xSQL, On Premise (MySQL, SQL Server)

1xFlat File, Vendor Tenant

1xFlat File, Provided

2xestablished SQL Server Data Marts, on premise (SQL Server)

3. Yes.

Question:
The RFQ refers to information from a “prior SOW” that included transformation design documentation and source-to-target mappings. It also asks suppliers to confirm whether they “have reviewed, or will review” these materials, which indicate differing levels of familiarity with CQU's current state.



To support a considered response, could CQU please:

- Confirm whether there are any documentations outside the current RFQ pack that suppliers are expected to consider when preparing their proposals;

- Confirm whether all suppliers will be provided with equivalent access to these documentations (e.g., prior SOW, transformation designs, source-to-target mappings) before the RFQ closes; and

- If these materials cannot be made available during the RFQ period, confirm the technical assumptions that suppliers should adopt regarding the current CQU environment.

For example, details on the maturity of existing fabric implementation, completeness of source-to-target mappings, accessibility of the 12 MVP data sources, and any known integration or data-quality complexities.

This will enable us to propose a delivery approach and effort estimate that are realistic within the October 2026 timeframe.

Answered on 20/Jul/2026 10:00 AM:


1. No. All relevant materials are in the pack.

2. Materials will not be supplied to any vendor as part of this RFQ. The vendor who completed the prior engagement is able to bid.

3. Technical Assumptions to Consider.

- A process for bronze layer data ingestion is 'settling in', covering database and API ingestion. A CQU Team is responsible for this and progressing. Approx half have initial ingestion approach and data available for refinement. Work will be ongoing over the period prior to engagement commencement.

- Approximately 160 individual data elements are required for the dashboards. About half have local teams with sound knowledge of the data, while the other have "new to cqu" data - with a local knowledgeable sandbox team to support understanding and resolution of issues. Some information (~10-20 fields) likely require some business review and development of rules. More complex sets of data have possible alternate sets available to use if necessary.

Question:
1. In the Scope of Works Requirements, Stream A Data Ingestion, reference is made to transformation design documentation and source-to-target mapping documentation 'from the prior transformation design SOW', with a requirement to confirm review of this documentation. Can you please provide this documentation?

2. The same section also highlights that several of the ingestion pipelines are already built. Please confirm the number of pipelines required to be designed and required to be built under this engagement. Please also confirm the status of the built pipelines - are they operational and/or will they require review, testing, rework under this project?

Answered on 20/Jul/2026 10:03 AM:


1. This documentation is not available as part of the RFQ. A description of findings is above.

2. The intention is to have most ingestion pipelines built by the time the successful firm is on site. However, these are the initial ingestions for CQU, and the vendor should expect to contribute to reviewing the pipeline outputs, and contributing knowledge to potential fixes and improvements.

Question:
We are very keen to put our best foot forward, as such is there a possibility for an extension on the close date?

Answered on 20/Jul/2026 10:46 AM:


Unfortunately our timelines are tight and are not able to be moved.

Question:
Inside the tender documents - you refer to the prior SOW. Can you please provide this document?

"Suppliers should confirm they have reviewed, or will review, the transformation design documentation from the prior SOW."

Answered on 20/Jul/2026 10:49 AM:


This is an incorrect statement. A summary of findings are provided in Q2, Item 3.

Question:
CQU - In one of the tender documents, it mentioned Regions of Service Locations. Are there any issues with delivering services remotely and/or offshore?

Answered on 20/Jul/2026 11:02 AM:


There is no issue with delivering services remotely. Partial offshore delivery may be possible.

Question:
- Are you open to a remote delivery model with travel to your office on a as needed basis?

- Are there any specific Procurement Panels ( QITC-specific / Queensland Government Specific / CQU specific ) to be part of in order to respond to this Tender?

- If not will a registration into the VendorPanel Marketplace suffice for a response.

Thanks in advance

Answered on 20/Jul/2026 11:25 AM:


1. Yes. This is our normal mode of operation and we are very comfortable with online cooperation.

2. We would prefer to use an applicable SOA like the 1303B or any other if applicable but otherwise we will work together through creating a General QITC contract

3. VendorPanel suffices

Question:
Is it possible to get an extension by 2 working weeks?

Answered on 20/Jul/2026 11:39 AM:


Unfortunately our timelines are tight and are not able to be moved.

Question:
Hi CQU team

Please provide responses for the following questions:

1. Please provide the complete list of the 12 MVP source systems ( which are in scope).

2. For each source system, what is the technology platform (SQL Server, Oracle, SaaS application, API, flat files, etc.)?

3. What are the estimated data volumes/Current size for each source system /Databases?

4. Are source systems accessible via APIs, direct database connectivity, file extracts, or existing integration platforms?

5. Would CQU provide the existing Transformation Design, existing architecture diagrams or data models?

6. How many dashboard pages are expected for SOAP and EER Dashboard Requirements?

7. What are the priority KPIs required for SOAP MVP?

8. What academic outcome measures are required for MVP (retention, progression, re-enrolment, completion, etc.)?

9. Are wireframes/sample reports/mockups for SOAP & EER Dashboard already available?

Answered on 22/Jul/2026 03:28 PM:


1/2.

14 Sources

2x SQL, Vendor Tenant (Postgres, SQL Server)

6x API, Vendor Tenant

2xSQL, On Premise (MySQL, SQL Server)

1xFlat File, Vendor Tenant

1xFlat File, Provided

2xestablished SQL Server Data Marts, on premise (SQL Server)3. 3. CQU currently handles the required data (and associated volumes) on premise, and our Fabric implementation has been purchased to support their migration. 3. We very roughly estimate 500MB - 1GB.

4. This is being handled by our Infrastructure team.

5. CQU is at the beginning of our Fabric journey. The Transformation Design status is described in Q2 above.

6. 5-10 pages each (or complex widgets and widget interactions on less pages)

7. Coverage of key information and accuracy.

8. These Dashboards have a broad intent and cover 7 domains (Student Details, Enrolment Details, Progression Status, Engagement Patterns, Financial Circumstances, Sentiment & Sense of Belonging, Engagement & Participation). The input of the factors described in each area will be considered again goals in all these areas. Key members of the team are able to articulate these clearly in relevant circumstances.

9. AI mockups are available.

Question:
Q1 Data Ingestion: Describe what interface types are available to ingest the source data from the source systems eg: api/database access?

Q2 Data Ingestion: Are existing pipelines reusable as-is, or do they require remediation/refactoring/uplift?

Q3 Data Ingestion: Of the 12 MVP sources, how many ingestion pipelines are already built and production-ready to support dashboard development? And are there any that required addition infra/network config?

Q4 Data Ingestion: Describe the volume of tables , record count and columns that will need to be ingested into the Bronze

Q5 Transformation: Can you please share information on the transformation framework that has been established for the silver , gold layers (transformation)

Q6 Data Modelling: How many silver entities and gold tables ( facts/dimensions ) are expected for MVP?

Q7 Security: Describe the row security level required to be setup from Fabric to the data sources within this project 

Q8 Security: Are the dashboards for internal consumption only i.e. access to partners , access via applications

Q9 Dashboard/Reporting: What is the expected number of SOAP and EER dashboarding sections/pages. , metrics , mobile ?

Q10 Dashboard: What CQU Power BI standards documentation exists (visual design, naming conventions, accessibility/WCAG requirements)?

Q11 Delivery: What is CQU's preferred sprint/iteration length and stakeholder availability for validation checkpoints?

Q12 Technical: What Azure DevOps or version control setup exists for the Fabric environment (repos, branches, PR process)?

Q13 Commercial: What post-deployment support period is expected, and what SLAs would apply?

Q14 Data Quality: Are there any known data quality issues in source systems that may impact transformation complexity?

Q15 Delivery: What level of CQU resource availability is committed for requirements validation and UAT?

Answered on 20/Jul/2026 11:30 AM:


"1. Database and flat file ingestion is established. API ingestion is underdevelopment in a similar methodology.

2. Metadata driven pipelines are available. As these are initial implementations, they are likely to need some ongoing development.

3. 5 Some tweaking of ingestion rates may be needed. The infrastructure is production ready.

4. As for Q8/p3 above.

5. We have not yet developed a stable approach for these transformations.

6. Silver 30-50. Gold is not yet scoped - simplistic AI developed models are available, but these are not yet tested or reviewed by appropriate PowerBI/Dimensional Modelling experts.

7. Access to and capability to download report data must be restricted. Some row level security is highly desirable for particular case types from our CRM. The build needs to provide the capability to restrict access by roles at a fairly broad level (cohort groups or widgets).

8. Internal only.

9. See Q8/6.

10. We have some standards for our datawarehousing work - our brief is to NOT look like them.

11. This project has a short timeframe to develop. Sprints will be 1-2 weeks (we will take your advice). Stakeholders will be available as needed.

12. Initial attempts only.

13. Please provide your normal SLA's or otherwise these will be developed with the successful vendor in the contract stage.

14. Of course. We intend to provide clear information on known faults and limitations, and are supported by our Business Owner to do this.

15. 1x Data Analyst for business validation, 2xData Developers with knowledge of new systems, and capacity to resolve issues with other teams for current systems."

Question:
Can CQUniversity confirm the list of all 12 MVP source systems currently in scope for this engagement?

Can CQUniversity clarify which components of the solution have already been designed or partially implemented and which components are expected to be implemented by the successful supplier?

Will the previous SOW artefacts, including source-to-target mappings, transformation design documentation, business rules and related design documents, be made available to the successful supplier at project commencement?

Has the MCDS aligned dimensional/student data model already been finalized or is the successful supplier expected to undertake additional dimensional modelling activities as part of the implementation phase?

Can CQUniversity clarify the proposed MVP scope for SOAP and EER, including the expected number of dashboard pages, KPI measures and prioritised functionality required for the MVP release?

Can CQUniversity provide further details regarding the expected data refresh requirements, Row-Level Security (RLS) model and Microsoft Fabric environment requirements (Development, UAT and Production) for MVP delivery?

Given the October/November 2026 MVP delivery target, can CQUniversity confirm whether all in-scope requirements are expected to be delivered as part of the MVP release or whether specific functionality has already been prioritised for subsequent phases?

Answered on 22/Jul/2026 03:29 PM:


1.

14 Sources

2x SQL, Vendor Tenant (Postgres, SQL Server)

6x API, Vendor Tenant

2xSQL, On Premise (MySQL, SQL Server)

1xFlat File, Vendor Tenant

1xFlat File, Provided

2xestablished SQL Server Data Marts, on premise (SQL Server)

2. Ingestion of source data is 1/4 complete and is continuing. Transformations, Dimensional Modelling and Reports are not yet formally started. Some components are available for reuse from other purposes.

3. Yes.

4. The model is not finalised. The supplier is expected to understake dimensional modelling activities.

5. See answer to Q8/8. A set of functionality is provided. It is likely some agile prioritisation will be required during implementation and CQU is prepared to support this process.

6. Most data will be required daily. Particular data sets (e.g. student enrolment) will be required at a greater rate (15-30mins). Our ingestion architecture supports this. Further support will be required for incremental update via our transformation pipelines.

Low Level Security - See Q9/7.

7. Source controlled code, semantic models and reports will be required across DEV/UAT and Prodution environments.

8. The requirements set being discussed is our MVP requirements set. Further significant requirements exist and are out of scope. There has been a prioritisation process, and we expect this to continue as part of a normal agile delivery process.

Question:
1. Could CQU confirm whether this engagement is replacing or extending an existing data warehouse, semantic model, reporting platform or SOAP/EER solution? Where applicable, it would be helpful to understand which components are expected to be retained, migrated, redesigned or decommissioned.

2. To support capacity planning and estimation, could CQU provide indicative information on data volumes, including the number of in-scope objects, historical data requirements, largest datasets and expected ongoing growth?

3. Could CQU confirm whether any of the sources require additional connectivity components, such as on-premises gateways, private networking, API integration, SFTP, firewall changes or vendor coordination?

4. Could CQU clarify which SOAP and EER business rules and metric definitions have already been agreed, and which areas the supplier is expected to help define through discovery and stakeholder consultation?

5. Are there existing SOAP or EER reports, prototypes, wireframes or requirements that can be shared to help suppliers better understand the expected MVP scope and user experience?

6. For SOAP caseload management, should suppliers assume a read-only analytical experience, or are capabilities such as assigning students, recording notes, updating statuses or other forms of write-back expected?

Answered on 20/Jul/2026 11:34 AM:


1. This is a new 'green fields' application on our Fabric Infrastructure, specifically focussed on making a significant step in our capability to meet business requirements of speed to market and access to data to support data informed decision making. The system is being prepared to enable access to next generation technology in the data space. Migration of our existing Datawarehouse, our existing operational reporting servers, and relationship to on-board application reporting are out of scope for this engagement.

2. See Answer 9/6. There is a requirement for historical data, and our ingestion methodology supports this. It will be required on only a subset of tables. Largest datasets are Student Demographics/Enrolment/Admission, our CRM data and our Learning and Teaching Data. We are targeting data since 2024. Based on other systems with comparable data sets, this is in the range of 500MB - 1GB. This is core institutional data is expected to grow over time, but we also practice archiving as required.

3. Yes they do. Our Digital Infrastructure Team handles this work.

4. There has been no formal agreement of business rules to apply. However, for existing system, a majority of rules are applied on other technologies or applications and can be available for reuse. Documentation of likely new business rules is available for a system where there will be new business rules in place. Metric definitions are available in documentation - and the team who have defined them will be available to review and adjust during implementation. There are a range of new systems being brought into CQU. Information from these will require simpler business rules development and can rely on some internal resources for assistance. Support to confirm and implement these business rules and adjustments during implementation is likely to be needed.

5. There are specifications and AI generates samples. These reports are new to CQUniversity.

6. The initial implementation does not include any application functionality. However, it is envisioned that later versions will, and so the products should be developed to support this type of future development.

Question:
Question 1 — MVP delivery date

Reference: Schedule 1, Scope of Requirements and Specifications v1.1 — Purpose, Objectives (item 4), Guiding Principles, Key Deliverables (item 4), RFQ Timelines; Invitation header milestone table.

The Purpose, Objectives, Guiding Principles and Key Deliverables sections each state an MVP delivery target of October 2026 for the SOAP and EER dashboards. The RFQ Timelines table in the same document, and the milestone table in the Invitation header, both state November 2026.

Could CQU please confirm the intended MVP delivery date, and if November 2026, whether a specific date within that month applies?

Question 2 — Stream A baseline

Reference: Schedule 1, Section 3A — "Source systems", "Source documentation"; Key Deliverables (item 2).

Section 3A states that the supplier will build ingestion pipelines for all REP in-scope source systems, and notes that "several of these are built and the total number for the MVP sources is 12."

a) Will the prior SOW source-to-target mapping documentation be released to suppliers during the RFQ period to inform the firm quotation, or made available only to the successful supplier post-award? If released, could CQU confirm the date and scope?

b) Could CQU confirm the full list of the 12 in-scope MVP source systems?

c) Could CQU confirm how many of the 12 currently have ingestion pipelines deployed to the bronze layer, and which of the 12 CQU considers within the scope of this RFQ for new pipeline build?

Question 3 — CQU student data model

Reference: Schedule 1 — Objectives (item 2); Definitions (MCDS); Section 3B "Silver layer structure".

The Objectives require transformations "aligned to CQU's student data model," while the Definitions describe MCDS as a framework CQU "intends to adopt" as its standard for student data models.

Does a documented CQU student data model currently exist and will it be provided to suppliers, and is alignment to MCDS a requirement of this engagement or an intended future direction?

Answered on 22/Jul/2026 03:31 PM:


1. At least one Dashboard needs to be delivered in October. The second in November. Delivery date is negotiable within that range.

2.

a) Only successful supplier.

b)

14 Sources

2x SQL, Vendor Tenant (Postgres, SQL Server)

6x API, Vendor Tenant

2xSQL, On Premise (MySQL, SQL Server)

1xFlat File, Vendor Tenant

1xFlat File, Provided

2xestablished SQL Server Data Marts, on premise (SQL Server)

c) All are within scope. Currently 4-5 are advanced in the process - refinements being made. Others are largely reliant on an API approach to ingesting which is currently being reviewed/confirmed.

3. No. A documented CQU student model does not exist. There is an element catalogue which contains all the items to be included in the model, and an AI generated draft for the model. Alignment to MCDS is an intended direction, to be taken into consideration during this process.

Question:
Hi CQU team,

Can you please clarify:

• Is the timeline for MVP delivery start or end of October 2026, or November 2026?

• Is the transformation design documentation from the prior SOW (as referenced) available for review?

• Is the CQU student data model, or a similar model, already available for use across both operational and analytical systems?

• What is the current Fabric Capacity? If the Fabric capacity is under F64, what is the current PowerBI License?

• There was a mention of some completed items, and 12 data sources total for the MVP. Does this mean we need to handle all 12? What has been built, and what hasn't? Can CQU supply an inventory of relevant source systems? Can a data dictionary be provided?

• Does CQU prefer onshore resources, or can offshore resources be used for delivery?

• Have the KPIs been defined for the MVP, and if so, how many are in scope? How many pages are anticipated to be in scope for the MVP dashboards?

• What are the estimated volumes for each data source?

• What are the refresh requirements (batch, near-real-time, event-driven) for each source? Schema on read vs Schema on write?

• Does CQU have a current state solution (i.e. existing dashboards, data models) for analysing this data or delivering the requested KPIs to end users?

• Are the Data Quality and Transformation rules defined? Can a list be provided?

• Does CQU own the cloud infrastructure and the related deployments?

Answered on 22/Jul/2026 03:33 PM:


1.At least one Dashboard needs to be delivered in October. The second in November. Delivery date is negotiable within that range.

2. No.

3. No.

4. F64 for production. We intend to have F64 for our development environment also, but we are currently working on F16.

5.

14 Sources

2x SQL, Vendor Tenant (Postgres, SQL Server)

6x API, Vendor Tenant

2xSQL, On Premise (MySQL, SQL Server)

1xFlat File, Vendor Tenant

1xFlat File, Provided

2xestablished SQL Server Data Marts, on premise (SQL Server)

No data dictionary exists for source system data. A data element catalogue exists as part of the high level design of the solution.

Currently 4-5 are advanced in the process - refinements being made. Others are largely reliant on an API approach to ingesting which is currently being reviewed/confirmed.

6. CQU prefers the vendor to have onshore resources for most interaction with an established local user base. Offshore resources may be acceptable for implementation work.

7. A number of metrics are defined for the Dashboards. Specific KPIs are not defined for the project. We expect 5-10 pages per Dashboard.

8. We don't have those figures. Entire set is estimated roughly at 500MB - 1GB.

9. There is a mix of requirements across the data. The data element catalogue gives an initial indication of what is required. Largely overnight batches will be adequate. Some systems/tables/data will have a near real time requirement - likely hourly will suffice for initial implementation.

10. Not in Fabric. There is an established data warehouse. However, it uses Data Vault Methodology, and has long and cautious development timeframes, as is appropriate for the business value required from it. This project is using Fabric as a platform to support faster 'data insights' and more rapid development. The Datawarehousing team has a limited capability to assist, but they will provide limited consultation if there are particular questions of interest.

11. No. Some areas have implemented transformations for other purposes, others are new to CQU and work has been done in a sandbox environment to develop initial transformation rules for validation. No list is available.

12. Development will occur in CQUs Fabric tenancy in our Azure environment. All Deliverables will be owned by CQU - if unclear, please discuss further during contract negotiation.

Question:
Hi Team, to prepare a firm, well-scoped, and realistic quotation, we request clarification on the questions below. Questions are grouped by topic for ease of distribution to the relevant CQU teams.

A. Delivery Timeframe

1) The Objectives, Guiding Principles, and Key Deliverables sections state an MVP target of October 2026 for both SOAP and EER, while the RFQ Timelines table and the Procurement Quotation Form milestone table state November 2026. Could CQU please confirm the binding MVP exact delivery date for both dashboards?

2) What user acceptance testing window does CQU anticipate ahead of the MVP date, and who will lead UAT execution on the CQU side?

3) Does CQU have a preferred duration and scope for the post-delivery support period (for example 4 weeks post go-live), to ensure quotations are comparable across respondents?

B. Source Systems and Ingestion

1) Could CQU please provide the list of the 12 MVP in-scope source systems (system name and platform)?

2) For each source, could CQU indicate: the expected integration method (database extract, API, file, other), connectivity path, authentication mechanism, indicative data volumes, and required load frequency or latency?

3) Do any of the sources deliver nested or semi-structured payloads (for example JSON or XML) that require unpacking and flattening during ingestion?

4) The RFQ notes several of the 12 sources are already built. Could CQU confirm which sources are net-new builds, which are fully built, and which are built but require additional objects to be added? For the built sources, are they complete to the bronze layer only, or through to silver?

5) What historical data depth is required per source for the MVP (for example current year, three years, full history)?

C. Prior Design Artefacts and Transformation Scope

1) Will the transformation design documentation and source-to-target mappings from the prior SOW be made available to respondents before the closing date, or only to the successful supplier at commencement?

2) How complete are the prior assessment and transformation design: do they cover all 12 sources through to the gold layer, or the bronze and silver layers only, and are the business rules fully specified or partially defined?

3) Is there an existing solution (for example a legacy data warehouse, existing reports, or current operational extracts) that can serve as the reference implementation for validating business rules and reconciling outputs?

4) How much of the transformation (silver) layer already exists in Fabric today, if any, beyond the bronze ingestion pipelines noted in the RFQ?

5) Are Type 2 slowly changing dimensions and historicisation (point-in-time reporting) required in the silver and gold layers for the MVP?

D. Gold Layer and Semantic Model

1) Approximately how many fact tables, dimensions, and KPIs or measures are anticipated in scope for the gold layer and the Direct Lake semantic model? If the prior design phase produced a dimensional model or measure inventory, could this be shared?

2) What level of calculation complexity is expected in the semantic model: primarily standard aggregations and time intelligence, or advanced cohort comparison logic, composite scoring, and dynamic security-aware measures?

3) Which sources or dashboard elements, if any, genuinely require near-real-time refresh for the MVP, and what latency does CQU define as near-real-time? Are daily refreshes acceptable for the majority of the solution?

4) Is the CQU student data model available as a documented artefact at commencement, and is MCDS conformance a hard requirement for the MVP gold layer or a directional standard?

E. Dashboards (SOAP and EER)

1) How many report pages are anticipated per dashboard for the MVP (SOAP and EER respectively)? Did the prior design phase produce wireframes, prototypes, or a page inventory that will be made available?

2) For the SOAP composite signal scores, does CQU have an existing scoring methodology or defined business rules, or is the supplier expected to design the scoring approach in collaboration with CQU stakeholders?

F. Environment and Platform Readiness

1) Will the Fabric capacity (including SKU and size), workspaces, Azure DevOps repositories, deployment pipelines, service principals, and source system connectivity and credentials be provisioned and available from project commencement on 20 August 2026? If not, which items remain to be provisioned and by whom?

G. Delivery Model and Resourcing

1) Which CQU project resources (business analysts, subject matter experts, data stewards, product owners) will be allocated to the project and at what availability, and who holds decision authority for business rule sign-off where source data or documentation is ambiguous?

2) The Purpose section states that expert project management support and a power report developer are required. Could CQU clarify whether a dedicated Power BI report developer role is expected in addition to the delivery team for the three streams, and if so at what time commitment?

3) Is any on-site presence (Rockhampton or other campuses) expected during discovery, delivery, or handover, or is remote delivery with time zone alignment acceptable?

4) We appreciate CQU’s consideration of these questions and look forward to the responses. Please direct any clarifications regarding this document to the contact listed on the cover page

Answered on 22/Jul/2026 03:48 PM:


"A

1. At least one Dashboard needs to be delivered in October. The second in November. Delivery date is negotiable within that range.

2. We expect delivery will be agile, with significant data testing through the full development period. We expect you will lead the UAT process, but senior CQU resources are available as appropriate to provide contact with the appropriate people to review dashboards and data provided and to support the sign off of UAT.

3. This can be negotiated as part of contract negotiations.

B

1. and 2.

2x SQL, Vendor Tenant (Postgres, SQL Server)

6x API, Vendor Tenant

2xSQL, On Premise (MySQL, SQL Server)

1xFlat File, Vendor Tenant

1xFlat File, Provided

2xestablished SQL Server Data Marts, on premise (SQL Server)

3.Yes.

4. All are new builds. Currently 4-5 are advanced in the process - refinements being made. Others are largely reliant on an API approach to ingesting which is currently being reviewed/confirmed. All are bronze layer only.

5. Likely 2-3 years for major sources.

C

1. Only to successful supplier.

2. Bronze and silver layer only. Business Rules - not defined. Some areas have implemented transformations for other purposes, others are new to CQU and work has been done in a sandbox environment to develop initial transformation rules for validation. No list is available.

3. Some exist for established resources. Some of the newer sources would have to rely on what is available on the interface.

4. None. Some exploratory work has been undertaken.

5. Yes, for some transformations and dimensions, this will be required.

D

1. No dimensional model was produced. We estimate about 30-50 transformed objects, based on domain-system-grain modelling.

2. Advanced cohort comparison logic. We expect to need to do the 'heavy lifting' of processing the information within the silver layer and in Fabric processing of gold layer information.

3. Yes, daily will be acceptable for majority. Ideally, this would be 15 mins. Hourly will be acceptable initially.

4 No. MCDS confirmance is a directional standard.

E

1. 5-10 per Dashboard. There are AI generated prototypes of the Dashboards. A Business Requirements spec provides some detail also.

2. Draft composite signals exist. The supplier will be asked to assist with their refinement once data is avialable.

F

1. Fabric Capacity is available now. Bronze layer components are available. Silver and Gold layers have no structure, and so these will be required from the vendor.

G

1. 2xdata developers, 1xdata analyst will be available. 1 senior tech resource, and 1 PM will be available. PM will coordinate relevant people, with tech advice provided. A business sponsor and owner are identified, and the business owner will be the relevant decision making person.

2. Yes. A dedicated Power BI report developer role is needed. We take your advice on time commitment but expect it will be significant.

3. Presence on the Rockhampton Campus is not required. Business hours contact with major project resources is necessary (AEST etc ok). Development may vary, but impact of more than a couple of hours will be undesirable. Negotiation at contract time is acceptable.

4. Thanks. Our pleasure.

Question:
Dear CQU - Apologies for the number of questions here - but many may be answered with providing the Prior Transformation design SOW.

1. The RFQ references a 'prior transformation design SOW.' What deliverables were produced from that engagement — specifically, were source-to-target mappings, data dictionaries, or business rules documented? Can these be shared with responding vendors prior to proposal submission?

2. The objectives table states an October 2026 MVP target, but the milestone table states November 2026. Which is the binding MVP deadline for SOAP and EER?

3. What CQU-side resources will be dedicated to this project, and at what availability (hours/week)? Specifically: business analysts, subject matter experts per data domain, a CQU project sponsor/decision-maker, and IT/platform support.

4. The RFQ states 12 MVP source systems, with 'several already built.' Which specific pipelines are already deployed and considered production-ready? What is the state of the remaining pipelines (designed but not built, not started)?

5. Please list all 12 MVP source systems by name (e.g. Student Administration System, LMS, CRM, finance system). For each, confirm: system name, connection method available (REST API, database connector, file extract, SFTP), and whether a current data dictionary or schema exists.

6. The RFQ states transformations must be 'rule-driven and documented' and references alignment to 'CQU's student data model.' Does a documented student data model exist? If so, can it be shared? If not, is defining it in scope for this engagement?

7. Are there entity resolution or deduplication requirements — for example, matching students across multiple source systems via student ID or other keys? If so, which source systems share a common student identifier and which require probabilistic matching?

8. The RFQ references MCDS (Maturity Classification of Data Standards) alignment. At what maturity stage is CQU's MCDS implementation? Are MCDS equity group definitions (Low SES, Indigenous, Regional/Remote, Disability, NESB, WINTA) already documented in CQU's systems with agreed data mappings, or will the vendor need to interpret and apply them from HEIMS/TEQSA definitions?

9. The silver layer testing requirement references 'reconciliation against source counts and known data.' Are pre-existing source system record counts, control totals, or reconciliation reports available to validate the bronze-to-silver transformation against?

10. Does a dimensional model design already exist (fact/dimension tables, grain definitions, key relationships), or is designing the dimensional model a vendor deliverable within this engagement? If a design exists, can it be shared?

11. The SOAP dashboard spans six domains (progression, engagement, sentiment, financial, support services, equity indicators). How many pages or views are anticipated in the MVP version? Is there a wireframe or functional specification document available?

12. What does 'caseload management and prioritisation capability' mean functionally? Specifically: does the dashboard need to allow advisers to action or flag students (write-back to a system), or is it a read-only analytical view? Are any workflow or task management features in scope?

13. Are automated notifications or alerts in scope for the MVP — for example, a Power Automate flow or email when a student's engagement score drops below a threshold? Or are alerts limited to visual indicators within the dashboard?

14. Do wireframes, mockups, or a functional specification exist for the Effectiveness Evaluation Report? If so, can they be shared prior to proposal submission to allow accurate scope and effort estimation?

15. How many student support services are in scope for the EER — and is the list of services fixed for the MVP, or still being defined? This affects the complexity of the service_key dimension and the number of EER views required.

16. What does 'cohort comparison' mean operationally in the EER context — for example, comparing students who received a service versus a matched control group who did not? Is the cohort definition methodology (e.g. propensity score matching, simple demographic matching) already defined, or is this in scope for the vendor to propose?

17. What outcome metrics will be used to evaluate service effectiveness in the EER — for example, unit pass rate, retention rate, GPA change, engagement score improvement? Are these metrics already defined with agreed numerator/denominator rules, or does the vendor need to work with stakeholders to define them?

18. Are there existing Power BI report templates, theme (.json) files, or CQU brand style guides that vendors can leverage during Stream C development? If so, can these be shared prior to proposal submission?

19. What accessibility standard must the dashboards comply with — for example, WCAG 2.1 AA? Is there an existing CQU accessibility policy or checklist that applies to Power BI reports?

20. The RFQ states 'CQU does not intend to shortlist vendors for a second round.' However, given the limited specification detail in areas such as source system connectivity, transformation rules, and dashboard wireframes, will CQU provide a structured discovery period or additional specification information before requiring vendors to submit a firm fixed-price quote? Without this, vendors must include a material risk contingency that inflates pricing.

Answered on 22/Jul/2026 03:53 PM:


"1. These cannot be shared. The mapping provided Silver Layer information only. An excel spreadsheet listing desirable data elements was mapped to sources, tables and fields. Existing business rules were identified. The data element catalogue is a partial data dictionary, high level business rules or their sources were identified. There were a number of elements needing further specification in both respects.

2. One Dashboard (effectiveness) is due in October, while the second is due in November. Deadlines within those months are negotiable.

3. 2x data developer, 1xdata analyst, 1 senior tech manager, 1PM (P/T). There is a CQU Project Sponsor, and business owner. We have an infrastructure team who will support the project.

4. All are new builds. Currently 4-5 are advanced in the process - refinements being made. Others are largely reliant on an API approach to ingesting which is currently being reviewed/confirmed. All are bronze layer only.

14 Sources

2x SQL, Vendor Tenant (Postgres, SQL Server)

6x API, Vendor Tenant

2xSQL, On Premise (MySQL, SQL Server)

1xFlat File, Vendor Tenant

1xFlat File, Provided

2xestablished SQL Server Data Marts, on premise (SQL Server)

5. As above - they are the normal range of systems of a university provider. No data dictionary exists - schema can be generated using SQL/AI tools?

6. There is a data element catalogue which lists each field required. This is our student model. No documented student model exists. We expect a gold layer model will be needed for implementation. We expect we will make progress with an initial set of silver layer objects with this implementation.

7. Yes. We have a single student id, and a mapping table to another older id with is used by some systems. A mapping to email address (cqu only) also exists. No probabilistic matching is required in the first instance.

8. Maturity is at initial investigation. There are well established definitions for these item - not sure they are aligned with MCDS or TEQSA.

9. Various user facing versions of the data being produced are available which can be used as sources of truth (or at least unwith understood limitations)

10. No. An AI generated prototype exists. We expect the vendor to provide a working design."

"11. Functional specification is available. AI generated prototype exists. 5-10 pages per Dashboard.

12. MVP is dashboard view only. We expect later versions will need to support user actions and interventions. No workflow or task management features are in scope.

13. Limited to visual indicators for MVP.

14. No. Functional spec only.

15. Unknown. We estimate 5-15 which will fundamentally be generated as teams from the CRM, but supplemented by other services supported using other systems or approaches.

16. Cohort is generally referring to groups at CQU, e.g. indigenous students, all students studying a particular course, or all students with a scholarship. There will then be a number of factors to compare - were students who received a service better off than others in this cohort who didn't. Assessment of 'better off' may be things like passrate, assessment submission, reenrolment etc. There is a strong business understanding of what is required, but this is likely to need your support to refine.

17. Yes! All of the above. The stakeholders have a strong understanding of what they want to measure - refinement will be needed.

18. No. There are, but these reports need to look different. They are the first offering from our new ""Data and Insights Platform"" i.e. Fabric and can't look like others.

19. These are staff facing reports - meeting accessibility guidelines is important, but no internal acceptable standard is defined.

20. No. Please provide a material risk contingency if that is part of your normal process. We will discuss what is available which may reduce this during contract negotiations."

Question:
1. The RFQ narrative and guiding principles reference an October 2026 MVP target, but the milestone table shows November 2026 for SOAP/EER delivery. Which date governs?

2. Is there an indicative budget range or cost ceiling for this engagement?

3. Will CQU provide a data classification/sensitivity policy or Purview taxonomy ahead of the engagement, or is this to be defined collaboratively during delivery?

4. Can CQU share (or confirm availability of) the source-to-target mapping and transformation design documentation from the prior SOW ahead of proposal submission, even in summary form?

5. Is an existing Fabric workspace, capacity, and Azure DevOps environment already provisioned from the prior SOW, and is it intended to be reused for this engagement?

6. Which of the 12 MVP sources, if any, already have bronze-layer ingestion built (the RFQ notes "several of these are built")?

7. Is there an existing data dictionary, glossary, or business-rule register from prior work (e.g. composite scoring, equity indicator definitions) we should assume as a starting point?

8. Has any part of the gold layer, semantic model, or measure library already been started under a prior engagement?

9. Can CQU provide the definitive list of the 12 confirmed MVP source systems (product/vendor names, not just categories)?

10. For each source system, how do we connect, REST/SOAP API, JDBC/ODBC database connection, flat-file export, SFTP/FTP drop, or a Fabric-native connector?

11. Are any source systems on-premises or behind a firewall requiring a Fabric on-premises data gateway, or are all sources cloud-hosted/SaaS?

12. What is the approximate data volume and record count per source (e.g. rows in the student administration system, LMS activity log volume), and expected growth rate?

13. What is the required refresh cadence per source; real-time/event-driven, hourly, daily, or weekly, and does this vary by source?

14. Do any sources support native change-data-capture or delta/watermark extraction, or will all sources require full-extract-with-comparison?

15. Are there existing API rate limits, throttling, or usage agreements with any source system vendor (e.g. LMS or CRM vendor API limits) we need to design around?

16. Is there a preferred or mandated approach for handling PII/sensitive fields at ingestion (e.g. masking, tokenisation before landing in bronze)?

17. Does CQU have an existing Azure DevOps organisation/project we would work in, or does this need to be provisioned?

18. What data quality thresholds or tolerances does CQU consider acceptable (e.g. % of records allowed to fail reconciliation) before it blocks progression to gold?

19. Is there a target or preferred DQ/observability tool already in use at CQU (e.g. Fabric-native, Great Expectations, Purview), or is tooling open to supplier proposal?

20. Has CQU formally committed to adopting MCDS (Maturity Classification of Data Standards), or is this still an intention?

21. What is the current size of the Fabric capacity SKU (e.g. F64, F128) that CQU has provisioned, or intends to provision, for this engagement, and if not yet provisioned, what is the expected timeline relative to project commencement (20/08/2026)?

22. Is the Fabric capacity dedicated to REP/this workload, or shared with other CQU Fabric workloads (other lakehouses, pipelines, reports) running on the same tenant capacity?

23. Would CQU consider provisioning two separate Fabric capacities, one for ingestion/transformation/orchestration (Data Factory pipelines, Spark notebooks) and a separate one for reporting (Direct Lake queries against SOAP and EER) or is a single shared capacity across both workloads preferred?

24. What is the expected number of concurrent users querying SOAP and EER during peak periods (e.g. Monday morning adviser check-ins, end-of-term reporting)?

25. How many Power BI workspaces does CQU expect, e.g. separate Dev/Test/Prod workspaces per dashboard, one shared workspace for both SOAP and EER, or a single workspace per environment covering both dashboards and the semantic model? Or this will be determined in this engagement?

26. Does CQU expect the semantic model refresh to be purely Direct Lake (no traditional import refresh), or is a fallback/hybrid model (Direct Lake with an import-mode framework for tables/aggregations not eligible for Direct Lake) required, and if so what refresh schedule applies to that fallback layer?

27. Are there already existing Entra ID groups defined for RLS implementation across the Power BI workspace, semantic model, and reports, specifically for the adviser, service lead, and executive access tiers, or do these groups still need to be defined and provisioned as part of this engagement

28. Are there other existing Power BI datasets/reports at CQU that this semantic model needs to coexist with or eventually replace?

29. Does CQU have an existing entity-relationship diagram (ERD), conceptual/logical data model, or defined dimensional modelling standard (e.g. CQU's student data model referenced in the RFQ) from the prior SOW or elsewhere that our gold layer star schema should align to, and can this be shared ahead of proposal submission?

30. Approximately how many advisers and service leads will be active users of SOAP at go-live?

31. Is there an existing or prior version of SOAP (e.g. a prototype, Excel-based tool, or earlier Power BI attempt) that should inform or be migrated from?

32. What weighting methodology, if any, has CQU already discussed internally for the composite prioritisation score, or is this fully open for the supplier to propose?

33. How many distinct support services must EER cover at MVP (e.g. peer support, scholarships, wellbeing, academic support), and is this list finalised?

34. Are "engaged" vs "non-engaged" cohort definitions already agreed anywhere, or fully open for this engagement to define with CQU?

35. Does CQU's institutional research or ethics team have existing guidance on presenting association-based (non-causal) outcome comparisons that we should align to?

36. Does CQU have a formal change control process we need to align our approach to, or is this to be proposed by the supplier?

37. Who are the data stewards responsible for the definitional accuracy of the shared measure library (progression, engagement, sentiment, financial, equity indicators), is this a single central BI/Analytics function, or distributed by domain (e.g. a steward per support service)?

38. Is there an existing (or planned) data governance framework, RACI, or committee structure at CQU that formally assigns these owner/steward/custodian roles, or would this engagement need to help establish it?

Answered on 23/Jul/2026 11:48 AM:


"1. EER needs to be delivered in October, SOAP in November. Negotiation is possible within those timeframes.

2. Probably. I am not aware of it. And those who are aware of it probably know not to tell you.

3. There is an existing documentation classification approach using purview which we will reuse where possible in this engagement. It has not been defined for data as yet, and purview is not yet implemented in our data environment.

4. This will not be shared prior to engagement. Summary is ...

Approximately 160 individual data elements are required for the dashboards. About half have local teams with sound knowledge of the data, while the other have ""new to cqu"" data - with a local knowledgeable sandbox team to support understanding and resolution of issues. Some information (~10-20 fields) likely require some business review and development of rules. More complex sets of data have possible alternate sets available to use if necessary.

5. An F64 is provisioned for the production envrionment. An F16 environment is currently in use for development. There is intention to move this also to F64. There is an available Azure DevOps environment available, but the processes to use it and its interaction with workspaces are not established.

6. All are new builds. Currently 4-5 are advanced in the process - refinements being made. Others are largely reliant on an API approach to ingesting which is currently being reviewed/confirmed. All are bronze layer only.

7. There is a spreadsheet serving this purpose.

8. No. Some preliminary investigative work has been undertaken.

9. They are the usual set of university systems.

10.

2x SQL, Vendor Tenant (Postgres, SQL Server)

6x API, Vendor Tenant

2xSQL, On Premise (MySQL, SQL Server)

1xFlat File, Vendor Tenant

1xFlat File, Provided

2xestablished SQL Server Data Marts, on premise (SQL Server)"

"11. Yes. Our infrastructure team will sort that out.

12. Estimated at 500MB - 1GB total. Amounts in more detail than that are not available.

13. All of these. Varies by source.

14. All will require full extract with comparison.

15. Probably. We are at the beginning of assessing this.

16. This will need to be determined during this work. There is a small, limited amount of information with high security needs which will require this type of work.

17. This needs to be provisioned.

18. Differs per data. Student Enrolment information is likely high (e.g. 95%) while some of the survey or other data which is newer and more variable may be lower (say 80%).

19.Nothing is available. Tooling is open to supplier proposal, but we not that any required procurement will likely occur outside the budget and timelines of this project.

20. Not formally - but it is likely to."

"21. F64 for production. We intend to have F64 for development also, but are currently using an F16.

22. The capacity is largely available to this project.

23. We have made the choice to provision single capacities. Please advise of the benefits of your approach if you reach product negotiation.

24. 50-100.

25. We are open to discussing your recommended architecture.

26. Direct lake is preferred. We will take your advice on architecture.

27. No. To be defined and provisioned.

28. Yes. The work will overlap with sets already active in our Datawarehousing infrastructure, and as reports provisioned by other application teams. We expect these will all move towards a common model.

29. No.

30. I assume the 50-100 above. This number is variable and depends on who is selected to trial/pilot etc and for what purpose. The number could be significantly lower - but is unlikely to be significantly higher."

"31. Not really. Similar data is used in an academic dashboard, but is presented more simply with much less sophistication.

32. Internal business resources have a strong understanding of what they want and the issues. We expect we will work with them to refine as the solution is implemented.

33. Unknown. We estimate 5-15 which will fundamentally be generated as teams from the CRM, but supplemented by other services supported using other systems or approaches. We will present as many we can.

34. No. Business have strong understanding and intent, but this is open for refinement during the project.

35. Not that I have ever been asked for. This is not a research based project.

36. We have a formal change control process which currently DOESN'T cover this type of data work or change. We welcome your advice.

37. No. We are at the early stages of developing our data stewards approach, and you should consider it immature. Where data stewards are needed, PM and senior tech resource will assist to identify the relevant approval.

38. We have a Data Governance Group who technically oversee this group. Given the lack of maturity in the process, they can assist with approving anything that cannot be resolved at the steward level."

Question:
1) The RFQ references 12 MVP source systems but doesn't list them. Could CQU provide the full list of source systems in scope and give an indicative table or object count per system?

2) Could CQU clarify what MVP means for each dashboard in practical terms — roughly how many pages or views are expected

Answered on 23/Jul/2026 11:39 AM:


"1. 2x SQL, Vendor Tenant (Postgres, SQL Server)

6x API, Vendor Tenant

2xSQL, On Premise (MySQL, SQL Server)

1xFlat File, Vendor Tenant

1xFlat File, Provided

2xestablished SQL Server Data Marts, on premise (SQL Server)

We don't have table or object counts per system. Object counts overall are 30-50 objects at domain-system-grain level.

2. 5-10 pages per dashboard."

Question:
Clarification Questions

Hi thank you very much for the opportunity to respond to this tender. Please find our queries below:

1. Given commencement on 20/08/2026, is the MVP date firm, or will CQU accept a phased MVP (e.g. one dashboard first) if the end-to-end build cannot be safely compressed into the available weeks?

2. Stream A states 12 MVP sources with 'several already built'. How many are already ingested and functioning, and how many remain in scope?

3. Will the prior transformation design SOW documentation (source-to-target mappings, business rules) be made available to vendors during the RFQ period, or only post-award?

4. For outstanding sources, will CQU provide API access / scheduled extracts, or is the vendor expected to build source connectivity? Are there existing landing extracts in Fabric today?

5. What are the approximate data volumes and required historical load depth per source, to size the incremental-load strategy?

6. Is the Azure DevOps environment (repos, CI/CD pipelines to Fabric) already provisioned, or does the vendor stand it up as part of scope?

7. Is there an existing gold-layer / dimensional model design, or is this greenfield?

8. Are DEV or non-production equivalents of the 12 source datasets available for ingestion development, or will the vendor be required to work against production data? If DEV data is unavailable, is data anonymisation or masking included within the supplier’s scope?

9. What security, privacy and data-classification requirements apply to student-level data, including internal data-classification policies, row-level security, data masking and audit requirements?

10. What are the specific performance targets (query/interaction response times) the semantic model must meet, and against what data volume?

11. "For SOAP's ""composite signal scores"" for student prioritisation, is the scoring logic/business rules defined by CQU, or are we expected to define the algorithm?"

12. Roughly how many report pages/views and how many distinct personas per dashboard are expected at MVP?

13. Do wireframes/prototypes exist, or is discovery/wireframing fully greenfield?

14. How many support services must EER's evaluation framework cover at MVP (peer support, scholarships, wellbeing, academic support, etc.)?

Answered on 23/Jul/2026 11:32 AM:


"1. We expect the effectiveness dashboard to be built by October, and SOAP by November.

2. All are new builds. Currently 4-5 are advanced in the process - refinements being made. Others are largely reliant on an API approach to ingesting which is currently being reviewed/confirmed. All are bronze layer only.

3. Only post award.

4. Likely our infrastructure team will sort out the connectivity. Abstracts exist in Fabric for all sources.

5. Total size is likely 500mb - 1gb. We haven't performed further analysis.

6. No. That needs to be built. Azure DevOps is accessible.

7.Greenfield

8. Prod only is available. Anonymisation is not in scope.

9. Security processes are high level. There are smaller sets of data within the overall which will require strong security. Access to the Dashboard at all will be the major security mechanism.

10. Unable to answer. Discernable is likely an issue.

11. There will be strong leadership by CQU Business on this topic. We will refine with your help during the project.

12. 5-10 pages per dashboard. Not sure what the persona reference means?

13. A functional spec exists and Ai generated prototype.

14. Unknown. We estimate 5-15 which will fundamentally be generated as teams from the CRM, but supplemented by other services supported using other systems or approaches. "

Question:
Hi CQU, we have 5 questions we would like to ask:

1. Does CQU have a Confluence subscription that we can use for Requirements Specification?


2. In Section 3E. Stream C in the Scope of Requirements document under “EER MVP Scope” it states “identify any features proposed for post-MVP delivery. Does this imply CQU would want further work done during the Support period, or that Support doesn't start until MVP extensions are done? Is Support the same as "Warranty" in the RFQ? Could CQU please clarify what they mean exactly by “support”?

3.What does the November 2026 delivery target date mean exactly? It's October in the rest of the document, but is November in the timelines - does this mean to cover the warranty period?

4. Could you please clarify the definition of a 'small/medium enterprise' as the link to the webpage in the document does not work?

5. With regards to payment terms, will it be acceptable to invoice monthly for work completed or only once the whole project is completed 'upon acceptance of the goods and/or services by CQU'?

Answered on 23/Jul/2026 11:10 AM:


"1. Yes.

2. Post MVP delivery would be an additional engagement. Please clarify support period and warranty during negotiations.

3. We expect the effectiveness dashboard in October, and SOAP in November.

4. This is listed under desirable criteria. We prefer to work with suppliers who respond well to smaller universities.

5. Please discuss during contract negotiation."

Question:
1. Can CQU provide the complete list of the 12 MVP source systems, including technology platform, data owner, refresh frequency, expected data volumes, and current implementation status?

2. Can CQU provide estimated data volumes for each source system, including:

- Current record counts

- Historical retention requirements

- Annual growth estimates

- Daily transaction volumes?

3. What are the expected data refresh frequencies by source system (near real-time, hourly, daily, weekly, etc.)?

4. Are there defined performance requirements for:

- Pipeline execution times

- Data refresh windows

- Dashboard response times

- Concurrency/user volumes?

5. Approximately how many:

- Dashboard pages

- Visualisations

- Measures/KPIs

- User personas are expected within the MVP scope?

- Has a detailed Row Level Security (RLS) design already been defined?

6. Approximately how many security roles and user groups will be required for MVP deployment? Will all source system access, service accounts, APIs and connectivity requirements be provisioned by CQU before project commencement?

7. The RFQ references both October 2026 and November 2026 as the MVP delivery target. Can CQU confirm the required MVP delivery date suppliers should price against?

Answered on 23/Jul/2026 11:06 AM:


"1. 1. and 2.

2x SQL, Vendor Tenant (Postgres, SQL Server)

6x API, Vendor Tenant

2xSQL, On Premise (MySQL, SQL Server)

1xFlat File, Vendor Tenant

1xFlat File, Provided

2xestablished SQL Server Data Marts, on premise (SQL Server)

All are new builds. Currently 4-5 are advanced in the process - refinements being made. Others are largely reliant on an API approach to ingesting which is currently being reviewed/confirmed. All are bronze layer only.

2.No.

3.Most data will be required daily. Particular data sets (e.g. student enrolment) will be required at a greater rate (15-30mins).

4. No.

5. 5-10 dashboard per report. Other figures are not known. RLS has not been defined.

6. 5-10. Once the contract is signed, this process will be led by our infrastructure team.

7.We expect the effectiveness dashboard to be built by October, and SOAP by November."