| Agency: | Mississippi State University |
|---|---|
| State: | Mississippi |
| Type of Government: | State & Local |
| NAICS Category: |
|
| Posted Date: | Mar 23, 2026 |
| Due Date: | Apr 7, 2026 |
| Solicitation No: | Bid MSU2026051 RFP |
| Original Source: | Please Login to View Page |
| Contact information: | Please Login to View Page |
| Bid Documents: | Please Login to View Page |
Submission Deadline Tue April 7th, 2026 at 2:00 pm
| Bid MSU2026051 RFP |
Planning, Design & Construction Project Management Software System.
Cost Form Technical Questions & Answers. |
Mississippi State University
Request for Proposals (RFP) 2026051
Planning, Design & Construction Project Management Software
System
ISSUE DATE: March 2, 2026
ISSUING AGENCY: Office of Procurement Services
Mississippi State University
405 Garrard Road East
Starkville, MS 39759
Sealed Proposals, subject to the conditions made a part hereof, will be received March 31,
2026 at 2:00 PM in the MSU Office of Procurement Services, same address above, for
furnishing services and potentially, optional services as described herein.
IMPORTANT NOTE: Indicate firm name, and RFP number on the front of each sealed
proposal envelope or package.
All inquiries concerning this RFP must be in writing and should be directed to:
Jennifer Mayfield
Office of Procurement Services, (Same address above)
jmayfield@procurement.msstate.edu
Any addendum associated with this RFP will be posted at
http://www.procurement.msstate.edu/procurement/bids/index.php located under RFP 2026051.
It is the respondent's responsibility to assure that all addenda have been reviewed and if
applicable, signed and returned.
1
1. UNIVERSITY OVERVIEW
Mississippi State University (MSU) is a comprehensive land-grant university. The main
campus is located adjacent to the community of Starkville in northeast Mississippi, with a
remote campus located in Meridian. Additionally, the university operates several remote
agricultural experiment stations and has an Extension office located in each of Mississippi's
eighty-two counties.
MSU's Office of Planning, Design & Construction Administration (PDCA) manages a diverse
portfolio of academic, research, residential, agricultural, and auxiliary facilities across its
campuses and statewide locations. Capital projects vary in size, complexity, and delivery
method and may span early programming, design, construction, and closeout phases
concurrently.
To support this portfolio, Mississippi State University is seeking to implement an enterprise
Project Management Information System (PMIS) that will function as the authoritative system
of record for owner-managed project information. The PMIS is intended to support consistent
governance, financial management, approvals, and lifecycle continuity from project initiation
through closeout, including the structured capture of asset-related data to support facilities
operations and long-term asset management.
The University seeks a scalable, configurable solution that enables owner-governed workflows,
integrates with existing enterprise systems, and reduces reliance on manual processes,
spreadsheets, and fragmented document repositories, while supporting the University's long-
term capital planning and facilities management objectives.
Additional information about MSU can be found at our website www.msstate.edu.
2. INVITATION TO SUBMIT PROPOSAL ON RFP
Mississippi State University, through PDCA, invites qualified vendors to submit proposals for a
web-based Project Management Information System (PMIS).
PDCA is responsible for managing capital projects across the University's main campus in
Starkville, the Meridian campus, and associated facilities statewide. The University's current
capital project backlog exceeds $450 million, with annual construction work-in-place exceeding
$50 million. PDCA manages more than 45 capital projects and over 50 minor or impact
projects annually. These projects range from small renovations, utility work, and site
improvements to new construction, major additions, and complex multi-phase projects.
The University seeks a PMIS that supports owner-centric project delivery and enables PDCA to
manage project information, workflows, and financial oversight throughout the full project
lifecycle. The system must support, at a minimum, financial management, document control,
2
approvals and workflows, schedules, meetings, action items, issue tracking, field and quality
reporting, and structured closeout. While contractor-led systems may continue to be used for
trade coordination activities, the PMIS must support PDCA's owner-level oversight,
governance, and reporting needs.
In addition to capital projects, PDCA manages MSU's space inventory and administers smaller
impact projects for which the University may act as its own construction manager. For these
projects, the PMIS must support estimating, bid solicitation, bid receipt, and contract-related
workflows in addition to standard project management functionality.
The proposed system must be flexible and configurable to align with PDCA's existing business
processes and governance requirements. The PMIS must support integration with MSU's
enterprise systems, including AssetWorks AiM for asset and facilities data and Ellucian Banner
for financial transactions. Integration with design and space-related tools, including AutoCAD,
is required to support consistency and accuracy of space and asset information.
The PMIS must support day-to-day project management activities for PDCA staff and
authorized internal and external stakeholders, while maintaining appropriate security,
auditability, and role-based access controls.
PDCA anticipates that this award will cover a five-year term from July 2026 through June
2031. Vendors shall provide detailed information regarding licensing models, implementation
services, ongoing maintenance and support costs, and pricing for optional modules or future
system enhancements. Annual support and maintenance services shall be identified separately
and are expected to include system updates, patches, and product hotfixes.
This RFP provides a high-level description of Mississippi State University's objectives,
evaluation approach, and overall system expectations. Detailed functional requirements,
including requirement classification and vendor response justification, are provided in the RFP
Requirements Workbook.
Additional Technical Information:
- Potential PMIS Integration Points (High-Level)
Ellucian Banner: Financial System
Jaggaer / "Bully Buy": Procurement & Contract Management
AIM Assetworks: Asset & Facilities Management Integration Requirements
Power BI: Business Intelligence & Reporting Integration Requirements
Bluebeam: Design Review Integration Requirements
3
3. SCOPE OF SERVICES REQUIRED
A. Functional and Technical Requirements
The PMIS must meet the 57 functional and technical requirements defined in the RFP
Requirements Workbook (Supplemental Workbook). These requirements capture the full
breadth of MSU's operational needs across departments, ensuring the platform supports both
day-to-day workflows and long-term enterprise scalability. Compliance with these requirements
will be the foundation of vendor evaluation and system configuration, establishing the baseline
for functionality, usability, and integration capabilities. The excel spreadsheet is included as a
Supplemental document must be filled out in full and returned to MSU with the proposal; It is a
requirement.
Written Response Requirements
All vendors must submit a written response for every requirement identified in this RFP.
The response to each requirement shall be written in the excel workbook. Written
responses must be specific to MSU's requirements and clearly explain how the proposed
solution meets or exceeds each requirement. Written responses must:
Be clearly labeled by requirement name or number
Explain how the solution satisfies the requirement
Describe relevant system functionality, technical considerations, and business
value to MSU
Avoid generic product descriptions not tied directly to the requirement
Capability Classification and Solution Enablement Effort
To support an objective evaluation of proposed solutions and to better understand the
effort required to enable each capability within the proposed software and the long-term
support implications. Vendors shall classify each requirement using one (and only one)
of the categories defined below.
These classifications are intended to distinguish between configuration, customization,
and development effort, and to identify potential capability enablement and lifecycle
risk. Classifications will be used for comparative evaluation and solution planning.
4
| Label | Name | Definition | ||||||
|---|---|---|---|---|---|---|---|---|
| A | No-Code Configuration | Functionality supported through point-and-click configuration using native administrative tools. Does not require scripting, expressions, rule engines, or technical development resources. Configuration is fully upgrade- safe and may be performed by trained system administrators. | ||||||
| B | Low-Code Configuration | Functionality supported through vendor-provided low- code tools, including conditional logic, business rules, expressions, workflow routing, integration mappings, or advanced reporting configuration. Does not require custom source code but may require specialized platform configuration or solution enablement expertise. Configuration is expected to be upgrade-safe when implemented in accordance with vendor best practices. | ||||||
| C | Limited Customization | Functionality requiring minor custom scripting or extensions that do not modify the core data model, platform architecture, or upgrade path. Customization is isolated, documented, and supportable, with no anticipated impact on future upgrades when maintained per vendor guidance. | ||||||
| D | Custom Development | Functionality requiring bespoke development, custom code, or significant modification of system behavior, data structures, or workflows. Custom Development may introduce upgrade, support, or lifecycle risk and typically requires specialized technical resources. | ||||||
| F | Not Available | The requirement cannot be met by the proposed solution through configuration, customization, or development. |
Label Name Definition
A No-Code Functionality supported through point-and-click
Configuration configuration using native administrative tools. Does not
require scripting, expressions, rule engines, or technical
development resources. Configuration is fully upgrade-
safe and may be performed by trained system
administrators.
B Low-Code Functionality supported through vendor-provided low-
Configuration code tools, including conditional logic, business rules,
expressions, workflow routing, integration mappings, or
advanced reporting configuration. Does not require
custom source code but may require specialized platform
configuration or solution enablement expertise.
Configuration is expected to be upgrade-safe when
implemented in accordance with vendor best practices.
C Limited Functionality requiring minor custom scripting or
Customization extensions that do not modify the core data model,
platform architecture, or upgrade path. Customization is
isolated, documented, and supportable, with no
anticipated impact on future upgrades when maintained
per vendor guidance.
D Custom Functionality requiring bespoke development, custom
Development code, or significant modification of system behavior, data
structures, or workflows. Custom Development may
introduce upgrade, support, or lifecycle risk and typically
requires specialized technical resources.
F Not Available The requirement cannot be met by the proposed solution
through configuration, customization, or development.
Justification
For each requirement, Vendors shall provide a concise justification supporting the
selected capability classification (A-D or F). The justification must explain how the
proposed solution satisfies the requirement and include the Vendor's estimated effort to
5
enable the requirement, expressed as anticipated hours for comparative evaluation and
planning purposes only. The same level of detail is expected for all classifications.
B. Validation Scenarios
Mississippi State University requires vendors to prepare short video demonstrations
("Requirement Validation Scenarios") to validate the vendor's ability to meet select MSU
requirements. These videos must demonstrate how the proposed system performs in practice
against MSU's defined requirements and workflows using live system functionality. Each
Requirement Validation Scenario represents a bundled, end-to-end demonstration of multiple
related MSU requirements. Scenarios are intended to validate system behavior and workflow
execution. Videos will need to be available by the proposal due date, and MSU will contact
vendors for videos once the proposals have been opened.
Video Response Requirements
Video demonstrations are required for the identified validation scenarios and will be
evaluated based on the relevance and clarity of the functionality shown, not on production
quality or visual polish. Do not merge Validation Scenarios together. We are looking for
each video to stand on its own. Failure to have required video responses ready for
submission upon request may result in rejection of a vendor's response, or a deduction of
technical points in scoring.
Video responses must:
Be 10-15 minutes in length (one video per validation scenario)
Be clearly labeled by scenario title and applicable requirement numbers
Demonstrate live interaction within the proposed system
Focus on functionality directly related to MSU's requirements
Include a brief walkthrough explaining how the functionality supports MSU's use
General product overviews, marketing materials, generic demonstrations, or links to
external websites will not be evaluated in lieu of requirement-specific validation videos.
Promotional or reusable marketing content is not acceptable.
Scenario Names and Information:
Foundation & Control (How MSU sets the system up)
1. Workflow Configuration
This scenario evaluates the PMIS's ability to support owner-governed, configurable
workflows that MSU can design, manage, and evolve independently across the full
capital project lifecycle. The intent is to understand how workflows, approvals, and data
6
capture are configured and maintained to support consistent governance across business
units without vendor-led customization.
Demonstration Focus:
Vendors should demonstrate representative workflows that illustrate:
Creation and modification of workflows using configuration tools
Assignment of forms, data fields, approvals, and requirements to workflow steps
Conditional logic, role-based routing, and visibility controls
Use of workflows across different business processes (e.g., planning, design,
construction, closeout)
Automated notifications, reminders, and status tracking ("auto-nagging")
Workflow mechanics and configuration capability
Functional Capabilities Required:
Unlimited workflow creation and modification via configuration (not
customization).
Ability to assign specific data entry screens and forms to each step in the workflow.
No restrictions on:
Number of workflow steps.
Number of user-defined data fields.
Types of business processes supported (e.g., real estate, legal, design, construction,
closeout).
Configurable conditional logic and field requirements per workflow stage.
Ability to attach forms, checklists, approval gates, and document requirements at
specific workflow milestones.
Support for role-based access and visibility by workflow step.
Automated notifications, reminders, and status tracking
Integration-ready with internal and external systems (e.g., legal review, property
management, facilities).
Business Drivers:
Minimize reliance on vendor-led customization.
Enable agility in adjusting processes across various departments (Real Estate,
Construction, Legal, Maintenance, Property Management).
Improve data consistency, reporting accuracy, and cross-functional coordination.
Enhance accountability, especially around schedule, approvals, and document
completion.
Support continuous improvement and future scalability across MSU's real estate and
capital delivery programs.
2. Project, Program, and Portfolio Governance
This scenario evaluates the PMIS's ability to support MSU's owner-managed
governance and oversight of its capital program across projects, programs, and
portfolios. The intent is to understand how real-world project relationships are
represented and how those structures enable authoritative reporting, oversight, and
7
decision-making by MSU independent of contractor-controlled systems or field
execution platforms.
This scenario focuses on organization, governance, and portfolio-level visibility, not
task-level execution or workflow configuration mechanics.
Demonstration Focus:
Vendors should demonstrate the PMIS's ability to support owner-centric project,
program, and portfolio governance, including:
Ability to define and manage projects, sub-projects, programs, and portfolios with
clear parent-child relationships.
Roll-up reporting across projects and sub-projects, individually or in aggregate,
without manual reconciliation or duplicate data entry.
Portfolio-level reporting by project, department, funding source, or program type.
Visualization and navigation of hierarchical project structures to support program-
level and executive oversight.
Management of sub-projects with distinct budgets, schedules, and funding sources
while maintaining consolidated portfolio visibility.
Ability for users to locate relevant project, financial, and asset information across
active and completed projects directly within the PMIS, without reliance on
predefined reports or contractor platforms.
Functional Capabilities Required
The PMIS must demonstrate the ability to:
Serve as an owner-managed system of record for MSU's capital program,
independent of contractor-controlled PMIS platforms.
Support portfolio-level reporting and analysis without dependency on contractor
participation or field execution tools.
Maintain consistent project, program, and portfolio structures across the full project
lifecycle.
Preserve historical project and portfolio data in a manner that remains searchable,
reportable, and usable for long-term planning and governance.
Scale governance and reporting structures as MSU's capital program evolves
without requiring reconfiguration of individual projects.
Business Drivers
Enable MSU to maintain full ownership and control of capital program data.
Provide leadership and stakeholders with portfolio-level visibility independent of
contractor systems.
Reduce reliance on spreadsheets and manual aggregation for program oversight.
Support long-term capital planning, governance, and institutional reporting needs.
Align the PMIS with MSU's owner-centric operating model.
8
Core Execution (How MSU runs projects)
3. Budget Management and Financial Forecasting
This scenario evaluates the PMIS's ability to support owner-managed budgeting,
forecasting, cashflow, and financial visibility throughout the project lifecycle. The intent
is to understand how financial information is structured, maintained, and used to support
informed decision-making related to spend timing, commitments, and project funding
needs.
Demonstration Focus:
Vendors should demonstrate representative financial workflows, including:
Support budget versioning, multi-contract reconciliation, early procurement
tracking, cash flow forecasting, and cost forecasting at both project and program
levels.
Support for multiple budget versions with clear version history and approval
workflow.
Budget creation using templates and contract-derived values.
Placeholder line items and pre-contract estimates.
Forecasting tools tied to project phase, funding approval status, planned spend
curves, and spend schedule.
Comparative analysis between original estimates, updated budgets, cash flow
projections, and actual contract amounts.
4. Schedule Management and Portfolio Visibility
This scenario evaluates how the PMIS supports owner-managed schedule visibility and
oversight across individual projects and the broader capital portfolio. The intent is to
understand how schedules are managed, tracked, and viewed at both project and
program levels.
Demonstration Focus:
Vendors should demonstrate schedule management using representative examples that
illustrate:
Ability to manage different schedule templates, with the ability for PMs and others
to add/edit subtasks as needed, but still provide centralized roll-up for reporting;
ability to baseline, change baseline, and take snapshots.
Ability to provide high-level graphical gantt view of multiple project schedules
(filtered in various ways) on a single screen with scrolling and drill-down
capabilities.
Ability to track GC schedules, baselines, milestones, and provide version control
and visibility across parent-child project structures.
Multiple schedule templates for different project types.
Ability for PMs to edit subtasks while retaining centralized roll-up reporting.
9
Graphical Gantt chart views with filtering, drill-downs, and milestone tracking.
Schedule baselining, change tracking, version control, and AOP planning snapshots.
Integration or import from Microsoft Project and Primavera.
5. Reporting and Analytics
This scenario evaluates the PMIS's ability to provide meaningful insight through
dashboards and reports that span multiple modules and levels of detail. The intent is to
understand how MSU users access timely, accurate information without manual data
consolidation.
Demonstration Focus:
Vendors should demonstrate:
Ability to create dashboards and reports pulling from all available data in the system
and formatting as needed across modules, ability to start at the highest level in a
report and drill down to the lowest level easily (without navigating outside of the
dashboard) - For example Connecting RFI, PCO to Contracts together in one report
Cross-module dashboards linking budgets, contracts, RFIs, PCOs, and schedules.
Drill-down functionality from high-level portfolio reports to granular details without
leaving the report interface.
Flexible, real-time dashboard views for capital project status, spending, and
forecasting.
Export and integration with Power BI for custom analytics.
How a completed project is formally closed out or archived within the PMIS while
preserving asset, document, and data structure.
How project and asset data can be transitioned or exported to MSU-managed storage
environments in a usable, organized format without manual rework or vendor
intervention.
How MSU can access and use completed project and asset information after
closeout without reliance on contractor platforms.
Lifecycle & Change (How the system holds up over time)
6. Asset Management and Lifecycle Data Integration
This scenario evaluates the PMIS's ability to support asset-centric project delivery and
ensure continuity of data from capital planning through design, construction, closeout,
and ongoing operations. The intent is to understand how project data is structured to
support long-term asset management, reduce re-entry of information, and enable
integration with enterprise facilities and asset systems.
This scenario evaluates whether the PMIS functions as a single, authoritative system of
record across the full project lifecycle. The intent is to understand how data,
configuration, and governance established early in a project continue to be used as the
project progresses through subsequent phases.
10
With Free Trial, you can:
You will have a full access to bids, website, and receive daily bid report via email and web.
Description Opening Date Closing Date AD for RFQ HCLETA driving track expansion June
Harrison County
Bid Due: 7/30/2026
Procurement Details Smart Number 2-20260720085214 MSU Advertised Date 07/21/2026 12:00 PM RFx #
State Government of Mississippi
Bid Due: 8/10/2026
Jul 30 Bids in 34 days 26-0910 RFQ Engineering, Design & Project Management
Harrison County
Bid Due: 7/30/2026
Procurement Details Smart Number 35-20260714133949 JCUA Advertised Date 07/16/2026 2:00 PM RFx #
State Government of Mississippi
Bid Due: 7/28/2026