Attachment B - Functional and Technical Requirements.xlsx
XLSX spreadsheet 30 KB Posted
- Solicitation number
- BD-27-1107-1107T-TRC01-133640
- Issued by
- Suffolk County, Massachusetts
About this file
This document is a functional and technical requirements attachment for a Project and Portfolio Management (PPM) SaaS solution being procured by the Massachusetts Trial Court. The requirements workbook establishes the mandatory and optional capabilities that bidders must address in their technical proposals, covering comprehensive functionality across portfolio and program management, waterfall and agile project methodologies, resource and capacity management, financial management, intake and demand management, collaboration, integrations, reporting and analytics, and non-functional requirements including SaaS delivery, accessibility, cybersecurity, performance, and configuration capabilities. The solution must support hierarchical portfolios, programs, and projects; enable multiple project methodologies (waterfall, agile, and hybrid) while maintaining portfolio-level visibility; provide centralized resource management with skills and availability tracking; and deliver real-time dashboards and customizable reporting with drill-down capabilities.
Bidders are required to complete the requirements worksheet in its entirety and submit it as part of their technical proposal, clearly identifying whether each capability is a core feature, optional offering, roadmap feature, or not applicable. Mandatory capabilities must be available for production use as of the RFQ response deadline, though the initial implementation scope may be narrower and additional configuration or professional services will be separately scoped using established hourly rates. The solution must be delivered as a multi-tenant or single-tenant SaaS offering hosted on FedRAMP-certified public clouds with documented service level agreements, elastic scaling capabilities, disaster recovery architecture, WCAG 2.1 accessibility compliance, and adherence to Commonwealth of Massachusetts cybersecurity requirements. Bidders must clearly identify any additional modules, licenses, third-party products, or recurring costs necessary to satisfy mandatory requirements and must be prepared to demonstrate functionality during product demonstrations upon request.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| IT PPM RFQ QandA Final Responses.xlsx | XLSX spreadsheet | |
| Sample Mandatory Contract Forms~1.pdf | ||
| Attachment C - Pricing Response Form.xlsx | XLSX spreadsheet | |
| ITS86 PPM SaaS RFQ - Bid Summary and Standard Provisions.docx | DOCX document | |
| Mandatory RFQ Documents~1.pdf | ||
| Attachment A - Scope of Services.docx | DOCX document | |
| RFx Cybersecurity Requirements.pdf | ||
| ITS86_18092026.pdf |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Instructions
| ATTACHMENT B – PPM FUNCTIONAL AND TECHNICAL REQUIREMENTS |
| Instructions |
| This workbook identifies the functional and technical requirements for the Project and Portfolio Management (PPM) SaaS solution sought by the Massachusetts Trial Court. Bidders must complete the Requirements sheet in its entirety and submit the completed workbook as part of the Technical Proposal. |
| Product Capability vs. Initial Implementation Scope |
| The requirements in this Attachment describe capabilities that the proposed solution must or should support and do not necessarily define the initial implementation scope. Mandatory capabilities must be available as of the RFQ response deadline, even if the Trial Court does not initially configure or use them. Any future configuration, integration, or related professional services will be separately scoped and authorized, as needed, using the applicable hourly rates established under the Contract. Bidders should describe how the capability is provided and should identify any additional modules, licenses, third-party products, or recurring costs necessary to make the capability available. |
| Requirement Level | |
| Mandatory (M) | The proposed solution must make the identified capability available as of the RFQ response deadline. Mandatory capabilities must be generally available for production use and may not rely solely on planned or roadmap functionality. Any additional module, license, product, or other separately priced offering required to provide the capability must be clearly identified, along with its associated pricing. |
| Optional (O) | The capability is desirable but is not required for responsiveness. Optional requirements will be considered as part of the evaluation. Bidders should identify whether the capability is currently available, available through an optional offering, planned for future development, or unavailable. |
| Feature Type – select one from the dropdown | |
| Core Feature | The functionality is a generally available feature of the specific product, edition, and licensing configuration included in the Bidder's base proposal and does not require an additional product, module, license, or custom development. |
| Optional Offering | The functionality is currently available but requires an additional module, license, product, third-party component, professional service, or other separately identifiable offering. If an Optional Offering is necessary to make a Mandatory capability available, the Bidder must clearly identify the additional offering and its associated pricing. The Trial Court is not necessarily required to purchase or implement that offering as part of the initial implementation unless expressly required by Attachment A. |
| Roadmap Feature | The functionality is not currently generally available for production use but is planned for a future release. The Bidder must identify the anticipated availability date and current development status in the Bidder Comments column. Roadmap Features will not satisfy Mandatory requirements. |
| N/A | The functionality is not available or the Feature Type classification is otherwise not applicable. The Bidder must provide an explanation in the Bidder Comments column. |
| Bidder Response – select one from the dropdown | |
| Fully Supports | The proposed solution satisfies the requirement in its entirety. |
| Partially Supports | The proposed solution satisfies only a portion of the requirement or requires a workaround, limitation, additional configuration, third-party functionality, or other qualification. The Bidder must clearly explain the limitation in the Bidder Comments column. |
| Does Not Support | The proposed solution does not currently satisfy the requirement. |
| Bidder Comments |
| Use the Bidder Comments column to explain how the proposed solution satisfies each requirement, especially where Feature Type is Optional Offering or Roadmap Feature, or Bidder Response is Partially Supports. Identify required modules or licenses, configuration requirements, third-party dependencies, material limitations, additional costs, anticipated roadmap dates, or other information necessary for evaluation. |
| Important |
| Responses must be based on the specific product, edition, modules, licenses, and services included in the proposal. Functionality available only in a different edition, separately licensed module, third-party product, future release, or additional professional service must be clearly identified. The Trial Court may request clarification of any response and may require the Bidder to demonstrate functionality identified as Fully Supports during a product demonstration. |
Requirements
| Category | Req-Num | Requirement | Mandatory/Optional | Feature Type | Bidder Response | Bidder Comment |
| Functional Requirements | ||||||
| Portfolio and Program Management | ||||||
| Portfolio/Program Management | 1 | The solution must support the creation and management of portfolios, programs, and projects with configurable hierarchies and relationships. | M | |||
| Portfolio/Program Management | 2 | The solution should enable strategic alignment: scoring models, prioritization criteria, and linkage of initiatives to business objectives, OKRs, or strategic themes. | O | |||
| Portfolio/Program Management | 3 | The solution should provide what-if scenario modeling (e.g., funding, capacity, schedule) to compare alternative portfolio mixes and understand impacts before approval. | O | |||
| Project Management (Waterfall, Agile, Hybrid) | ||||||
| Project Management | 4 | Waterfall: The solution must enable the waterfall methodology, including support for: | M | |||
| Project Management | 4.a | Gantt charts | M | |||
| Project Management | 4.b | Critical path determination | M | |||
| Project Management | 4.c | Dependencies | M | |||
| Project Management | 4.d | Milestones | M | |||
| Project Management | 4.e | Creation and management of baselines | M | |||
| Project Management | 4.f | Phase-gate/lifecycle templates (e.g., conceptual, design, build, test, deploy) | M | |||
| Project Management | 5 | Agile: The solution must include built-in support for backlogs, epics, user stories, sprints/iterations, Kanban boards, burndown/burnup charts, WIP limits, and agile metrics (velocity, cycle time). | M | |||
| Project Management | 6 | Hybrid: The solution must be able to combine phase-based planning with agile execution (e.g., waterfall milestones with agile team boards and sprints under each phase). | M | |||
| Project Management | 7 | The solution must allow different methodologies per project while maintaining portfolio-level visibility, comparable KPIs, and roll-up reporting. | M | |||
| Resource and Capacity Management | ||||||
| Resource Management | 8 | The solution must support having a centralized human resource pool with roles, skills, calendars, and availability across the organization | M | |||
| Resource Management | 9 | The solution must support automatic provisioning of resources as they are added to the organization’s IAM systems, including their roles and skills. | M | |||
| Resource Management | 10 | The solution must support capacity planning and scenario analysis to test staffing plans, identify overloads, and optimize allocation across concurrent projects. | M | |||
| Resource Management | 11 | The solution must support both named and generic resources, and track utilization, allocation vs. actuals, and forecasted demand. | M | |||
| Resource Management | 12 | The solution must support non-human resources such as materials or external vendors, equipment, tools, and facilities, among others. | M | |||
| Financial Management | ||||||
| Financial Management | 13 | The solution must support budgeting, forecasting, and tracking of project and portfolio financials (CAPEX/OPEX, labor and non-labor costs, benefits/ROI). | M | |||
| Financial Management | 14 | The solution must support Budgeting and forecasting for annual or strategic planning purposes | M | |||
| Financial Management | 15 | The solution must support alignment by fiscal years and allow these to start at a date other than the start of the calendar year. | M | |||
| Financial Management | 16 | The solution should support Integration with ERP/financial systems to synchronize cost centers, GL codes, actuals, and invoices | O | |||
| Financial Management | 17 | The solution must support basic cost rates and financial approvals, including configurable workflows. | M | |||
| Demand, Idea, and Intake Management | ||||||
| Intake Management | 18 | The solution must allow the capture of Ideas and demand with configurable intake forms, workflows, and scoring criteria for different types of initiatives (capital, non-capital, departmental requests, etc.) | M | |||
| Intake Management | 19 | The solution must support stage-gate approvals with auditable decisions and traceability from idea to project execution | M | |||
| Intake Management | 20 | The solution must provide the ability to triage and route requests to appropriate portfolios or governance boards | M | |||
| Collaboration and Work Management | ||||||
| Collaboration | 21 | The solution should provide built-in collaboration features: comments, notifications, document attachments, and activity feeds at project, task, and portfolio levels | O | |||
| Collaboration | 22 | The solution must support task management for project team members, including personal work queues, and due dates. | M | |||
| Collaboration | 23 | The solution must support integrations with collaboration platforms (e.g., email, chat tools) via APIs or connectors | M | |||
| Integrations and Interoperability | ||||||
| Integrations | 24 | The solution should support open REST/SOAP APIs and webhooks for integration with ALM/dev tools, ITSM, HR, and identity systems | O | |||
| Integrations | 25 | The solution must support SFTP or similar secure data exchange mechanisms for batch integrations where needed. | M | |||
| Reporting, Analytics, and Dashboards | ||||||
| Reporting and Dashboards | 26 | The solution must support real-time dashboards for portfolio health, schedule, budget, risk, and resource utilization with drill-down capability. | M | |||
| Reporting and Dashboards | 27 | The solution must provide standardized reports for executive views, PMO operations, financials, and resource utilization, plus support for custom reports or self-service BI integration. | M | |||
| Reporting and Dashboards | 28 | The solution must allow the publishing of said dashboards for internal organization consumption without the need to acquire additional user licenses (i.e., view-only access). | M | |||
| Reporting and Dashboards | 29 | The solution must allow export and API access for reporting tools, including support for common formats (e.g., CSV, Excel, PDF) and data refresh schedules. | M | |||
| Non-Functional Requirements | ||||||
| General and SaaS Delivery | ||||||
| SaaS Delivery | 30 | The solution must be delivered as a multi-tenant or single-tenant SaaS, hosted in FedRAMP-certified public clouds with documented SLAs for uptime. | M | |||
| SaaS Delivery | 31 | The solution must support elastic scaling to handle growth in users, projects, and data volumes without performance degradation. | M | |||
| SaaS Delivery | 32 | The solution must provide clearly documented service boundaries, RPO/RTO objectives, and disaster recovery architecture (geo-redundant backups, failover procedures). | M | |||
| Accessibility Requirements | ||||||
| Accessibility | 33 | The solution must conform with Web Content Accessibility Guidelines (WCAG), Version 2.1, Levels A and AA), including keyboard navigation, screen reader compatibility, color contrast, and scalable fonts. | M | |||
| Accessibility | 34 | The solution must provide accessibility statements and test documentation, plus a defined process for addressing accessibility issues and regressions in updates. | M | |||
| Accessibility | 35 | The vendor must answer the attached Accessibility Requirements for the Commonwealth of Massachusetts government in its entirety. | M | |||
| Enterprise-Level Security | ||||||
| Cybersecurity | 36 | The solution must comply with the RFx Cybersecurity Requirements listed in the attachment in their entirety. | M | |||
| Performance, Availability, and Reliability | ||||||
| Performance | 37 | The solution provider must have documented performance targets (e.g., typical page load times under normal loads) and capacity testing practices. | M | |||
| Performance | 38 | The solution must have a high availability architecture with redundancy at application and database layers and defined maintenance windows. | M | |||
| Performance | 39 | The solution provider must conduct regular backups, test restoration procedures, and have business continuity plans for major outages. | M | |||
| Configuration, Extensibility, and Usability | ||||||
| Configuration and Extensibility | 40 | The solution must support admin-configurable workflows, fields, forms, and templates for different project types and methodologies | M | |||
| Configuration and Extensibility | 41 | The solution must support configuration of governance processes (e.g., approval workflows, stage-gates) without custom code. | M | |||
| Configuration and Extensibility | 42 | The solution should have an intuitive UX suitable for both occasional executives and daily project team users, with contextual help and in-app guidance. | O |
Ref
| Response Validations |
| Response: |
| Bidder Fully Supports |
| Bidder Partially Supports |
| Bidder Does Not Support |
| Feature Type: |
| Core Feature |
| Roadmap Feature |
| Optional Offering |
| N/A |
File details come from the government source that posted it. Updated .